Monatsrückblick Oktober 2026 ist online!

[fu_zhou]

Zuerst einmal: Vielen Dank für die Implementierung von "Funktionspläne (FBD)" - wirklich genial! Vielleicht wäre es sinnvoll, neben JavaScript, Blockly und Node-Red eine Rubrik hier im Forum unter Skripten/Logik zu eröffnen?

Mir ist es bisher nicht gelungen herauszufinden, wo die schon verfügbaren Bausteine herkommen. Es gibt ein paar weitere Bausteine, die es in der SPS-Welt gibt, hier aber fehlen, z.B. der Selector oder Multiplexer (bei 0 am Bool-Eingang wir der Real 0 durchgestellt und bei 1 am Bool-Eingang der Real 1), s. https://oscat.readthedocs.io/projects/oscat-basic/de/latest/Engineering/signal processing/mux_r2/

Dann fehlen dem PID ein paar Funktionen, die der PID-Adapter mitbringt, z.B. Invertieren des Ausgangs (= z.B. von kp 1 auf kp -1 umschalten), eine Totzone, in der der Regler den Reglerausgang nicht verändert und ein Anhalten des Reglers für den Fall, dass eine Umschaltung stattfindet, auf die der Regler nicht reagieren soll bzw. erst wieder nach Freigabe, s. https://oscat.readthedocs.io/projects/oscat-basic/de/latest/Engineering/Control/ctrl_pid/

Überhaupt wäre es der Wahnsinn, wenn die OSCAT Basic- und Building-Bausteine (bzw. eine sinnvolle Auswahl) nach und nach in die Bausteinbibliothek von Funktionspläne (FBD) übertragen werden kann. Kann ich da etwas dazu beitragen?

Der Quellcode der Bausteine in SCL liegt hier:
https://github.com/eclipse-oscat/oscat-libs-archive/blob/main/OSCAT_BASIC_LIB/ARCHIVE/rel335/OSCAT_BASIC_335.TXT
https://github.com/eclipse-oscat/oscat-libs-archive/blob/main/OSCAT_BUILDING_LIB/Archive/rel100/OSCAT_BUILDING_100.TXT

[Bluefox]

@fu_zhou Danke!

Die Bausteine der Bibliothek stecken im javascript-Adapter, im Modul @iobroker/fb-runtime. Den Code findest du unter src/lib/fb/blocks.ts, die Beschreibung aller Bausteine in der Doku.

Einen MUX kannst du dir schon jetzt bauen, bis es ihn fertig gibt:

• mit dem Baustein JS (Eingänge IN1 = BOOL, IN2, IN3):

return IN1 ? IN3 : IN2;

• oder als eigener Baustein: einen Plan anlegen, "Dieser Plan ist ein Baustein" einschalten, dann über FB_IN/FB_OUT die Anschlüsse festlegen und im Plan selbst z.B. einen JS einsetzen. Den Baustein kannst du danach in jedem Plan verwenden.

Zu MUX/SEL und zum PID (Ausgang invertieren, Totzone, Halt/Freigabe) mach bitte je ein Issue auf: https://github.com/ioBroker/ioBroker.javascript/issues
Am besten jeweils mit Anschlüssen und erwartetem Verhalten, so wie du es hier beschrieben hast.

Mithelfen kannst du gern, PRs sind willkommen. Bei OSCAT schau bitte vorher auf die Lizenz, bevor Code direkt übernommen wird. Verhalten und Schnittstellen nachzubauen ist kein Problem.

[fu_zhou]

Super, danke, ich mache mal in Github weiter. Den SEL/MUX habe ich schon mit dem JS-Block gebaut, allerdings mit deutlich umfangreicherem Code als der kurze Einzeiler oben 😉

[Eistee]

Hi

Da ich beruflich mit SPS Programmierung zu tun habe frage ich einfach mal.
Was ist der Plan? Wollt ihr in ioBroker so programmieren wie auch eine SPS programmiert wird? wenn ja warum? Wir haben inzwischen typescript codegenerierung per KI im ioBroker und ihr wollt wieder wie vor 40 Jahren SPS in KOP FUP AWL SCL GRAPH programmieren? Kann ich mir kaum vorstellen.
In der Industrie versuchen wir gerade den KI Modellen beizubringen die SPS-Steuerungen vernünftig mit KI zu programmieren da die ja nur mit diesen Uhralten Sprachen umgehen können und speichertechnisch noch in den 90er Jahren angeordnet werden müssen. Das kommt der Programmierung von µControlern gleich. Wieso wollen wir im ioBroker uns solche Einschränkungen geben?

Gruß Alina

[Bluefox]

@Eistee Nein, niemand muss jetzt wie auf einer SPS programmieren. FBD ist eine weitere Möglichkeit neben JavaScript/TypeScript, Blockly und Rules. Es ersetzt keine davon.

Die Einschränkungen einer SPS gibt es dabei nicht. Kein Speicherlayout, keine Zykluszeit und keine festen Datentypen wie in den 90ern. Der Plan wird beim Speichern in JavaScript übersetzt und läuft wie jedes andere Skript im javascript-Adapter. Mit "FBD → JS" kannst du dir den erzeugten Code ansehen. Wenn etwas fehlt, gibt es den Baustein JS oder eigene Bausteine.

Warum überhaupt:

• Viele Nutzer kommen aus der SPS- oder Gebäudetechnik-Welt (siehe @fu_zhou oben). Sie denken in Timern, Flipflops, Reglern und Schwellwerten und sind damit sofort produktiv.
• Für Logik, die dauerhaft läuft (Verzögerungen, Selbsthaltungen, Regelkreise), ist ein Plan oft übersichtlicher als Code mit Callbacks und Timern.
• Die Online-Ansicht zeigt live, welcher Wert gerade wo anliegt. Für die Fehlersuche ist das bei solcher Logik sehr praktisch, auch wenn der Code von einer KI stammt.

Wer lieber TypeScript schreibt oder sich den Code von der KI erzeugen lässt, macht einfach so weiter wie bisher. Beschrieben ist das hier: Funktionspläne (FBD)

[fu_zhou]

@eistee Die von dir völlig zurecht adressierten Einschränkungen und den Sprung zurück in die 90er gibt es zum Glück nicht. Ich habe einige Regler bei mir in Betrieb - bisher über den PID-Adapter und den einzubinden ist schon umständlich. Ich habe jetzt die ersten Blockly-Skripte, mit denen ich den PID-Adapter eingebunden habe, auf Funktionsplan umgestellt und das Ergebnis ist wirklich genial: Einfach zu lesende Logik, einfaches Debuggen über die Online-Ansicht, ein fertiger Plan kann als Baustein gespeichert und instanziiert werden (ohne Instanz-DBs ;-) etc. Natürlich kann man argumentieren, dass man für eine einfache oder sogar komplexe Funktion nur 1 Zeile Javascript braucht und hier mehrere Blöcke zu verschalten sind - aber die Möglichkeit bleibt ja, wie @bluefox schreibt.