Listen

Hier mal ein halbwegs sinnvolles "real life" Beispiel, was man z.B. mit Listen anstellen kann:

Hier wird eine Liste dazu verwendet, die Tagesmitteltemperatur zu ermitteln.

Zunächst wird beim Start des Scriptes eine leere Liste erzeugt.

Der Zeitplan sorgt nun dafür, dass jede Minute die Temperatur aus einem Datenpunkt gelesen und am Anfang der Liste eingefügt wird.
Das "vorne anfügen" hat den Vorteil, dass Änderungen auch im Objektbaum ersichtlich sind.
Der ermittelte Mittelwert wird hier nur ausgegeben. Wie man das in einen DP schreibt, ist hier beschrieben.

Am Ende wird per Zeitplan um 23:59:30 Uhr die Liste wieder geleert, damit am nächsten Tag wieder mit komplett neuen Werten gerechnet werden kann.

Das Ganze stellt hier nur ganz rudimentär das grundsätzliche Verhalten dar.
Man kann das je nach den Anforderungen noch abwandeln/ergänzen:

• Man arbeitet nicht zyklisch per Zeitplan, sondern triggert auf das Temperatur-Objekt
  
• Man arbeitet mit einer festen Anzahl an Werten. Wurde die erreicht, wird die Liste geleert
  

Hier ins Detail zu gehen, würde eindeutig zu weit gehen.
Bei besonderen Anforderungen wird Dir sicher im Forum weitergeholfen.

Bitte hier nicht antworten
Dieser Thread soll den blutigen Anfängern in Sachen Blockly ein wenig Starthilfe bieten und helfen, die ersten Hürden zu meistern und die häufigsten Fallstricke zu vermeiden.
Fragen/Anmerkungen/Änderungen/Ergänzugen bitte ausschließlich hier!

Dokumentation
Du bist neu bei Blockly?
Dann mach Dir die Mühe und schau Dir die Doku an, bevor Du im Forum einen neuen Beitrag eröffnest.
Die Erfahrung zeigt, dass immer wieder die gleichen "Probleme" behandelt werden.
https://www.iobroker.net/#de/documentation/logic/blockly.md

Script starten/stoppen/pausieren
Ein Blockly-Script wird in ioBroker (genau wie ein reines JavaScript) grundsätzlich zunächst erstellt und dann auch gestartet. Danach läuft es dauerhaft und wird (außer in sehr seltenen Ausnahmefällen) nicht gestoppt oder neu gestartet.

ACHTUNG: Scripte - egal welcher Art - gehören nur in sehr seltenen Ausnahmefällen in den Ordner "global". Du solltest Dir eine sinnvolle Ordnerstruktur - im Normalfall unterhalb von "common" - ausdenken.

Namensgebung:
Die Namen von Scripten sollten keine Leer- oder gar Sonderzeichen enthalten. Das gilt insbesondere für Umlaute.
Statt einem Leerzeichen solltest Du einen Binde- oder Unterstrich verwenden.
Diese Regel gilt grundsätzlich auch für Datenpunkte und Variablen!
Wobei man bei Variablen auch auf den Bindestrich verzichten sollte. Der wird zwar intern in einen Unterstrich gewandelt, aber wenn man später mal in JS programmiert, erzeugt man sich schnell eine Subtraktion.

Trigger und Zeitpläne
Alles was auf Ereignisse reagieren bzw. zu bestimmten Zeiten oder zyklisch ablaufen soll, benötigt einen "Trigger" oder "Zeitplan".

ACHTUNG: Was außerhalb dieser Blöcke platziert wird, wird genau 1x - beim Start des Script - ausgeführt.
Mehr dazu hier

Werte auslesen
Werte aus Datenpunkten werden (in den meisten Fällen) mit diesem Baustein gelesen:

ACHTUNG:
Wenn der Wert desjenigen DP benötigt wird, der mit dem Trigger überwacht wird, muss der Wert nicht mit dem "Wert von" Baustein gelesen werden.
Stattdessen verwendest Du diesen Baustein:

und änderst ihn anschließend von "Objekt ID" auf "Wert".
(Ab Version 7.5 des JS-Adapters ist "Wert" hier bereits die Vorgabe).
Wenn der Trigger ausgelöst wurde, sind (so ziemlich) alle Eigenschaften des betroffenen DP bereits bekannt.
Hier nochmal zu lesen ist unnötig und kann zu Fehlern führen.

ACHTUNG:
Das hier ist etwas völlig anderes und liefert das komplette Objekt - also den ganzen DP und nicht nur seinen Wert:

Mehr dazu hier

Werte schreiben (Datenpunkte ändern)
Grundsätzlich gibt es zwei unterschiedliche Wege, einen Wert in einen DP zu schreiben.

Steuere
Dieser Baustein wird für alle DP verwendet, die einem Adapter "gehören". Das gilt auch für Alias-Datenpunkte, die auf einen Adapter-DP zeigen.
Aktualisiere
Verwende diesen Baustein nur für eigene DP, die Du unterhalb von 0_userdata.0 selbst angelegt hast.

Mehr dazu hier

Variablen
Variablen dienen dazu, ermittelte oder berechnete Werte für die weitere Verarbeitung vorzuhalten.
Variablen werden manuell erstellt und sind im gesamten Script gültig.

Variablen sollten überall dort eingesetzt werden, wo ansonsten der Wert aus einem DP mehrfach ausgelesen werden müsste.
Auch die Les- und Wartbarkeit eines Scriptes lässt sich durch die Verwendung von Variablen deutlich verbessern.
Insbesondere komplexe Prüfungen werden durch Variablen deutlich besser lesbar und damit verständlicher.

Mehr dazu hier

... to be continued

@David-G

Dem möchte ich mich gerne anschließen.
Es war schön, den einen oder anderen Protagonisten auch mal persönlich kennenzulernen.

Auch dass viele Teilnehmer z.T. sehr lange Anfahrtswege auf sich genommen haben, spricht glaube ich für das Produkt an sich und für diese Community.
Ich glaube, spätestens bei der abschließenden Fragerunde wurde klar: ioBroker wird für und durch die Community entwickelt. Jeder hat seinen kleinen Anteil daran ... und sei er noch so winzig.
Also lasst uns das Ganze weiter vorantreiben ... Aufgaben gibt es genug. Nicht nur für das Core-Team und die Adapter-Entwickler, sondern auch für die vielen Tester und hoffentlich viele neue Beitragende zu Doku und anderen Themen.

Auch von mir vielen Dank an das Team rund um ioBroker und Solingen-Digital für eine rundum gelungene Veranstaltung.

@sissiwup sagte in Host-Adapter Anzeige für Betriebssystemupdates:

diese Funktion hat hier aber nix zu suchen

Eine reichlich subjektive Einschätzung

sollte zumindest abschaltbar sein

Geht doch.
Entweder "Bestätigen und schließen", Updates installieren oder über den Notification-Adapter ausschalten.

Meldungen zu Sachen, die ioBroker nix angehen

Auch wieder recht subjektiv.
Eine ganze Reihe anderer sind - so wie ich - durchaus der Meinung, dass ein ioBroker sich um seinen Unterbau kümmern darf. Und wenn man hier ständig die von @Thomas-Braun benannten Hilferufe aufgrund völlig versumpfter Basissysteme sieht, ist das bei vielen Anwendern auch bitter nötig.

@kisshome sagte in 50€: Mach mit bei einer Smarthome Studie mit ioBroker!:

Mindestens 3 Smart Home-Geräte, die die Cloud nutzen

Tja - genau darum verwende ich ioBroker. Nix Cloud, alles lokal

Grundsätzliches
Insbesondere wer von der prozeduralen Programmierung oder einer SPS zu Blockly kommt, muss sich hier neu orientieren und umdenken.
Im ioBroker werden Programme nicht bei Zeile 1 gestartet und laufen dann bis Zeile xyz nacheinander ab.
In der Regel "reagieren" Programme (Scripte) nur auf äußere Einflüsse und werden aktiv, wenn ein bestimmtes Ereignis eintritt. Das kann die Änderung eines Datenpunktes oder auch das Erreichen eines bestimmten Zeitpunktes sein.
Die meiste Zeit "schlafen" die Programme ... solange, bis eines der genannten Ereignisse eintritt.

Trigger
Ein Trigger ist eine Ereignisbehandlung. Das kann man sich als eine Art Abonnement vorstellen.
Tritt das Ereignis ein, wird der Code im Trigger ausgeführt.

• Will man bei bool'schen Datenpunkten (true/false) nur reagieren, wenn der DP auf true wechselt, verwendet man am besten "ist größer als Letztes".
  Analog dazu lässt sich der Wechsel auf false mit "ist kleiner als Letztes" verarbeiten.
  Hintergrund: Ein true wird intern als 1 und ein false intern als 0 verarbeitet.

• Echte "Änderungen" am DP prüft man mit "wurde geändert". Datenpunkte werden von den Adaptern gerne mal zyklisch "aufgefrischt". Eine Prüfung auf "wurde aktualisiert" würde dann viel zu häufig den Trigger auslösen.

Hier ein ganz einfaches Beispiel: Ändert sich der Zustand eines Schalters "SwitchState", wird die Lampe "Licht" mit dem Wert des Schalters (an oder aus) geschaltet.
Was es mit dem Baustein "Wert" auf sich hat, wird hier erläutert.

ACHTUNG:
Niemals mehrere Trigger (oder Zeitpläne oder eine Kombination daraus) ineinander verschachteln. Sowas hier funktioniert nicht:

Zeitpläne
Mit einem Zeitplan kann man Dinge zu bestimmten Zeiten oder auch zyklisch alle x-Minuten ausführen lassen.

• Vermeide den "Wizard", sondern verwende nach Möglichkeit CRON.
  Mit dem Wizard produzierte Zeitpläne funktionieren häufig nicht - zumindest nicht wie gewünscht

• Vermeide zyklisch Ausführungen alle x-Minuten, wenn die gleiche Aufgabe auch mit einem Trigger ausgeführt werden kann.
  Man muss nicht alle paar Minuten prüfen, ob ein Datenpunkt einen bestimmten Wert angenommen hat. Das belastet das System. Besser ist es, einen Trigger auf den DP zu setzen.

In diesem einfachen Beispiel wird eine Lampe täglich um 20:00 Uhr eingeschaltet.

Alles was außerhalb von Triggern oder Zeitplänen hinzugefügt wird, wird nur 1x - beim Start des Scriptes - ausgeführt.
Damit lassen sich z.B, verwendete Variablen beim Start des Scriptes auf einen definierten Wert setzen.
Dabei ist es unerheblich, ob der Baustein losgelöst von allen anderen "in der Luft schwebt" oder ob er z.B. oben (oder unten) an einen anderen Baustein angepinnt wird.

ACHTUNG: Ein in Blockly erzeugter Zeitplan wird nur 1x beim Start des Scriptes aktiviert.
Wenn man "variable" Zeitpläne benötigt, die sich z.B. bei Änderungen an einem Datenpunkt ändern sollen, muss man etwas mehr Aufwand treiben.
Die Details führen allerdings an dieser Stelle zu weit. Wenn Du so etwas benötigst, schau in die Doku.

Hinweis an alle nachfolgenden Leser:
Dieser Beitrag ist über 7 Jahre alt!
Nicht das jemand auf die Idee kommt, die hier gezeigten Befehle auszuführen.

Die sind zum größten Teil völlig veraltet!

Falls / mache / sonst
In den allermeisten Scripten muss zur Laufzeit mindestens eine Bedingung geprüft werden.
Dabei wird oft nicht nur eine, sondern ggf. mehrere Bedingungen geprüft.

Tipp 1
Wenn mehrere Bedingungen geprüft werden müssen, wird das Ganze oft übersichtlicher wenn man die Ansicht auf "externe Eingänge" umstellt:

Tipp 2
Kleiner Ausflug in bool'sche Algebra:
Wenn eine Bedingung mit "falls" geprüft wird, muss der zu prüfende Ausdruck entweder "wahr" oder "falsch" werden. Heißt auf Deutsch: " Ist der Wert von "power" jetzt gößer als 500? Ja oder Nein?

Das gleiche gilt hier aber auch für den zweiten Ausdruck: Ist "istEingeschaltet" jetzt "wahr" oder "falsch"?
Der Punkt ist: "istEingeschaltet" ist ja bereits ein Wert, der entweder nur "wahr" oder "falsch" sein kann (Boolean). Das lässt sich jetzt also folgendermaßen vereinfachen:

Falls auf falsch geprüft werden soll, ist dieser Ansatz hier der bessere:

Zum Einen benötigt man hier nur 2 statt 3 Bausteine und zum Anderen wird mit einem "nicht" der Code minimal schneller ausgeführt.

Tipp 3
Verschachtelte Ausdrücke werden schnell unübersichtlich.

Hier hilft es oft, wenn man einzelne Teilausdrücke vorher einer Variablen zuweist.

Wie bereits erwähnt: Code wird häufiger gelesen als geschrieben.
Es erleichtert die Fehlersuche und die spätere Wartung, wenn Code gut lesbar ist.

Tipp 4
Es ist in den allermeisten Fällen nicht nötig, mehrere Prüfungen mit einzelnen "Falls"-Bausteinen auszuführen.
Viel einfacher ist eine Logik nach dem Motto " Falls x" => "mache etwas" => "sonst" => ... mache etwas anderes.
Dazu klickst Du auf das kleine blaue Zahnrad und ziehst den gewünschten Block nach rechts unter das "falls".

Tipp 5
Noch komplexere Prüfungen? Dann ist vielleicht der folgende Baustein der richtige:

Das ist schneller und erspart einiges an "Puzzelei".

Aber Achtung: Der Wert eines DP muss zunächst einer Variablen zugewiesen werden. Die Prüfung funktioniert nicht direkt mit dem "Wert vom Objekt"-Baustein!

Und unbedingt darauf achten, dass hinter jedem "Im Falle von" ein Wert steht. Hier stehen keine logischen Ausdrücke!

@bananajoe
Du kennst das doch: Im Sommer sitzen die Damen bei 22°C im kurzen Shirt und genießen gekühlte Getränke.
Im Winter tragen sie bei 23°C dicke Socken und holen sich 'ne Decke.

@dave69 sagte in Welche Vis für Anfänger kann das?:

Richtig komplexe Sachen werde ich definitiv nicht machen

OK - Dein Wort in Gottes Ohr. Wir fragen in ein paar Monaten nochmal nach

@legro sagte in Raspberry Pi 4 startet nicht mehr:

In der neusten Grafana-Version funktioniert das vollständige Ausblenden der Menüs in eingebetteten Diagrammen mittels des Parameters kiosk nicht mehr. ..

Nö - dafür gibt's dann neue Parameter
https://forum.iobroker.net/topic/78085/hinweise-zu-grafana-11-3-0-01/4

@touranie
Das funktioniert so nicht (Asynchronität).
Könnte man z.B. mit Timeout lösen.

@dgr
schon mal

exec('influx delete --org xyz --bucket abcd ....');

probiert?

@norbert999 sagte in Listenpunkt "Aufzählungen" im iobroker sichtbar machen:

Wie man sieht, gibts bei mir in der linken Auswahlliste keinen Punkt "Aufzählungen". Wie mache ich den sichtbar?

Gar nicht. Das heißt jetzt "Kategorien".
Das ist einer der Nachteile von teils uralten YT-Filmchen.

@metaxa sagte in Cronjob am Ende vom Quartal:

Jetzt täte ich es noch gerne verstehen:

Wenn man um 23:30 triggert und dann 30 Minuten draufrechnet, landet man zwangsläufig beim nächsten Tag.
Jetzt prüft man, ob dieser "nächste Tag" zufälligerweise der 1. ist.
Ist das so, befindet man sich aktuell (23:30 Uhr) am letzten des Monats.

@bahnuhr sagte in Wemos W1 mini flashen:

Benutze doch das Programm tasmotizer.

Oder den Web-Installer: https://tasmota.github.io/install/

@brokeling
Ich würde zunächst mal herausfinden, welche IP der Client hat, wenn er mit dem Wemos verbunden ist.

@BuryJones

Ich meine mit den zwei Triggern auch eher diese Aussage:

Ein Blockly hat einen Astro-Trigger auf "Sonnenuntergang" mit Verzögerung 0. Dieser Trigger wird zuverlässig ausgeführt. Innerhalb dieses Triggers prüfe ich, ob die aktuelle Zeit zwischen Sonnenuntergang und Mitternacht ist.

Ein anderes Blockly triggert auch bei Sonnenuntergang

Das würde ich in einen eizigen Trigger packen.

Und innerhalb eines Triggers auf "Sonnenuntergang" macht es wenig Sinn zu prüfen, ob auch wirklich Sonnenuntergang ist.

@buryjones sagte in Astro-/Zeitvergleich, Sonnenuntergang != Sonnenuntergang:

Das liegt daran, dass es sich als äußerst schlecht erwiesen hat, nur auf dieses Ereignis zu setzen. Wenn der iobroker zu der Zeit nicht an ist (defekt o.ä.) oder aus einem anderen Grund der Sonnenuntergang verpasst wird

Kann ich nicht nachvollziehen.
Bei mir läuft der Kram seit Jahren superstabil. Für irgendwelche Sonderlocken sehe ich daher keine Notwendigkeit.

@buryjones sagte in Astro-/Zeitvergleich, Sonnenuntergang != Sonnenuntergang:

Innerhalb dieses Triggers prüfe ich, ob die aktuelle Zeit zwischen Sonnenuntergang und Mitternacht ist

Wozu das?
Wenn der Trigger feuert, ist Sonnenuntergang. Da muss ich doch nicht noch prüfen, ob das auch stimmt.

Ich persönlich würde dafür auch nicht zwei Trigger verwenden, sondern alles in einen packen.