Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. English
  3. Scripting / Logic
  4. Blockly
  5. Enhancements to Script Messaging System (Blockly)

NEWS

  • Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
    BluefoxB
    Bluefox
    15
    1
    562

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    13
    1
    622

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    25
    1
    1.9k

Enhancements to Script Messaging System (Blockly)

Geplant Angeheftet Gesperrt Verschoben Blockly
5 Beiträge 2 Kommentatoren 60 Aufrufe 2 Watching
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • d34df4c3D Offline
    d34df4c3D Offline
    d34df4c3
    schrieb am zuletzt editiert von d34df4c3
    #1

    Hi everyone,

    I’ve been using ioBroker’s script messaging system (Blockly) and find it super helpful for inter-script communication. However, I’ve identified a few missing features that could make it even more powerful. Here’s my wishlist:


    1. Missing result Variable in "Event: Received Message" Trigger

    The "Event: Received message" block in the Trigger menu provides the data variable but lacks the result variable. This forces users to either:

    • Convert the script to JavaScript (losing Blockly’s simplicity), or
    • Use a hack like embedding the logic in a "JavaScript function" block (my current workaround).

    The result variable would be very interesting feature for returning values between scripts cleanly. Adding it to Blockly would maintain consistency with JavaScript while keeping the visual scripting experience intact.


    2. Missing result Variable in "Send Message" Block

    In the SendTo menu, the "messages to other script" block doesn’t allow passing the result variable. This limits bidirectional communication, as scripts can’t easily return processed data or acknowledgments.

    Without result, scripts must rely on separate messages or global variables, complicating logic and reducing efficiency.


    3. Broadcast Messages to All Scripts

    Currently, messages must target specific script IDs, creating tight coupling. A broadcast mechanism would excellent:

    • Decoupled architecture: Scripts listen for events without knowing the sender’s ID.
    • Dynamic systems: New scripts can be added without modifying existing ones (e.g., plugins).
    • Event-driven workflows: Example: A "system shutdown" event notifies all relevant scripts without hardcoding dependencies.

    Let me know what you think ;)

    OliverIOO 1 Antwort Letzte Antwort
    0
    • d34df4c3D d34df4c3

      Hi everyone,

      I’ve been using ioBroker’s script messaging system (Blockly) and find it super helpful for inter-script communication. However, I’ve identified a few missing features that could make it even more powerful. Here’s my wishlist:


      1. Missing result Variable in "Event: Received Message" Trigger

      The "Event: Received message" block in the Trigger menu provides the data variable but lacks the result variable. This forces users to either:

      • Convert the script to JavaScript (losing Blockly’s simplicity), or
      • Use a hack like embedding the logic in a "JavaScript function" block (my current workaround).

      The result variable would be very interesting feature for returning values between scripts cleanly. Adding it to Blockly would maintain consistency with JavaScript while keeping the visual scripting experience intact.


      2. Missing result Variable in "Send Message" Block

      In the SendTo menu, the "messages to other script" block doesn’t allow passing the result variable. This limits bidirectional communication, as scripts can’t easily return processed data or acknowledgments.

      Without result, scripts must rely on separate messages or global variables, complicating logic and reducing efficiency.


      3. Broadcast Messages to All Scripts

      Currently, messages must target specific script IDs, creating tight coupling. A broadcast mechanism would excellent:

      • Decoupled architecture: Scripts listen for events without knowing the sender’s ID.
      • Dynamic systems: New scripts can be added without modifying existing ones (e.g., plugins).
      • Event-driven workflows: Example: A "system shutdown" event notifies all relevant scripts without hardcoding dependencies.

      Let me know what you think ;)

      OliverIOO Offline
      OliverIOO Offline
      OliverIO
      schrieb am zuletzt editiert von
      #2

      @d34df4c3

      for interscript communication you can use sendTo/onMessage Funtions/Events.

      https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#onmessage

      To Broadcast you can use a datapoint and the various scripts that should listening, can trigger on this datapoint

      Meine Adapter und Widgets
      TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
      Links im Profil

      d34df4c3D 1 Antwort Letzte Antwort
      0
      • OliverIOO OliverIO

        @d34df4c3

        for interscript communication you can use sendTo/onMessage Funtions/Events.

        https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#onmessage

        To Broadcast you can use a datapoint and the various scripts that should listening, can trigger on this datapoint

        d34df4c3D Offline
        d34df4c3D Offline
        d34df4c3
        schrieb am zuletzt editiert von
        #3

        @OliverIO Thanks for the quick reply.

        The intent of the post is to enrich Blockly's feature, not to migrate to Javascript.

        The datapoint approach works for simple cases, but it breaks down when you need to pass data, return value and deal with thread isolation (concurrent script reading/writing at same time).
        For basic case, why not but it is not elegant and manager datapoint could quickly become a nightmare to manage for little bit more complex scenario.

        While native broadcast support would be ideal, another way to reduce coupling between scripts is to implement a centralized message-delivery script that acts as a message router.

        How It Works:

        1. All messages are sent to a single script (e.g., javascript.0.message-delivery).
        2. This script maintains a mapping of message types to target scripts (e.g., "temperature_update" → ["script1", "script2"]).
        3. When a message arrives, the message-delivery forwards it to the correct listeners based on the mapping.

        Pros:

        • Decouples publishers from subscribers: Scripts only need to know the message-delivery's ID, not each other.
        • Controlled message flow: You can log, filter, or modify messages in transit.
        • Easier maintenance: Changes to routing logic happen in one place (the postman).

        Cons:

        • Manual mapping updates: Adding a new listener requires updating the message-delivery's configuration ... which could be considered as a pro if you prefer to keep control of the mapping.
        OliverIOO 1 Antwort Letzte Antwort
        1
        • d34df4c3D d34df4c3

          @OliverIO Thanks for the quick reply.

          The intent of the post is to enrich Blockly's feature, not to migrate to Javascript.

          The datapoint approach works for simple cases, but it breaks down when you need to pass data, return value and deal with thread isolation (concurrent script reading/writing at same time).
          For basic case, why not but it is not elegant and manager datapoint could quickly become a nightmare to manage for little bit more complex scenario.

          While native broadcast support would be ideal, another way to reduce coupling between scripts is to implement a centralized message-delivery script that acts as a message router.

          How It Works:

          1. All messages are sent to a single script (e.g., javascript.0.message-delivery).
          2. This script maintains a mapping of message types to target scripts (e.g., "temperature_update" → ["script1", "script2"]).
          3. When a message arrives, the message-delivery forwards it to the correct listeners based on the mapping.

          Pros:

          • Decouples publishers from subscribers: Scripts only need to know the message-delivery's ID, not each other.
          • Controlled message flow: You can log, filter, or modify messages in transit.
          • Easier maintenance: Changes to routing logic happen in one place (the postman).

          Cons:

          • Manual mapping updates: Adding a new listener requires updating the message-delivery's configuration ... which could be considered as a pro if you prefer to keep control of the mapping.
          OliverIOO Offline
          OliverIOO Offline
          OliverIO
          schrieb am zuletzt editiert von
          #4

          @d34df4c3

          Yes, I understand that. Additional blocks would certainly be useful.

          However, Blockly doesn't support some other features of JavaScript and ioBroker, or only supports them partially.

          If desired, one could of course build custom JavaScript function blocks in Blockly to support such features.

          This thread could certainly be used to conduct a survey on this. But definitely also create a feature request on GitHub.

          Meine Adapter und Widgets
          TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
          Links im Profil

          1 Antwort Letzte Antwort
          1
          • d34df4c3D Offline
            d34df4c3D Offline
            d34df4c3
            schrieb am zuletzt editiert von
            #5

            I have identified two interesting pieces of code.

            For the missing result variable in "Event: Received Message":
            https://github.com/ioBroker/ioBroker.javascript/blob/dba68e9eb91f79035f62a2df584fd1f7474462fe/admin/google-blockly/own/blocks_trigger.js#L1241-L1368

            And for the missing result variable in "Send Message" block:
            https://github.com/ioBroker/ioBroker.javascript/blob/dba68e9eb91f79035f62a2df584fd1f7474462fe/admin/google-blockly/own/blocks_sendto.js#L365-L549

            Now, I have to better understand Blockly framework and see how the code can be adapted.

            1 Antwort Letzte Antwort
            0
            Antworten
            • In einem neuen Thema antworten
            Anmelden zum Antworten
            • Älteste zuerst
            • Neuste zuerst
            • Meiste Stimmen


            Support us

            ioBroker
            Community Adapters
            Donate

            697

            Online

            32.6k

            Benutzer

            81.9k

            Themen

            1.3m

            Beiträge
            Community
            Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
            ioBroker Community 2014-2025
            logo
            • Anmelden

            • Du hast noch kein Konto? Registrieren

            • Anmelden oder registrieren, um zu suchen
            • Erster Beitrag
              Letzter Beitrag
            0
            • Home
            • Aktuell
            • Tags
            • Ungelesen 0
            • Kategorien
            • Unreplied
            • Beliebt
            • GitHub
            • Docu
            • Hilfe