ioBroker.js-controller

repository·master·Indexed 43 days ago

https://github.com/iobroker/iobroker.js-controller

The central core of an ioBroker installation, managing configuration and controlling adapter processes. It provides the Controller class for system orchestration, the Adapter class for building new adapters via @iobroker/js-controller-adapter, and built-in Redis simulators for file-based objects and states databases.

Tokens
193.6K
Snippets
645
Records
958
Agent score
50%

What's inside ioBroker

  1. Manage adapter dependencies with globalDependencies and ifInstalledDependencies

    master

    When developing an adapter, you can specify dependencies to ensure the system is correctly configured:

    1. globalDependencies: A record of required ioBroker adapters and version ranges that must be present in the entire system for your adapter to function.
    2. ifInstalledDependencies: A conditional dependency check. The version check for a specified adapter will only be performed if that adapter is already installed. If the target adapter is missing, the check passes.
  2. Understand the SupportedMessages interface

    master

    The SupportedMessages interface is an object used to define whether an adapter supports receiving specific types of messages via sendTo.

    If any property within this interface is enabled (set to true), the system will automatically create a messagebox object at system.adapter.<adapterName>.<adapterInstance>.messagebox. This messagebox is used to route messages (such as email or Pushover notifications) directly to the adapter.

    This interface is primarily used by adapter developers to signal capabilities to the ioBroker controller.

  3. How object protection via NonEditable works

    master

    ioBroker provides built-in protection for specific object attributes using the nonEdit attribute. When an object contains a nonEdit attribute, certain properties become protected and cannot be modified by a user without providing a valid password.

    Protection Workflow

    1. Initial Protection: To protect properties, the nonEdit attribute is added to the object.
    2. Hashing: If the object is initially unprotected, the system saves a hashed version of the password into nonEdit.passHash.
    3. Editing: To change a protected property, the user must provide the correct password via the nonEdit.password field.
    4. Validation: If the password matches the hash, the object attributes are updated. If the password is incorrect, the changes are rejected.

    Important Distinctions

    • Scope: Only properties explicitly listed within the nonEdit object are protected. All other properties on the main object (e.g., obj.common) can be updated without a password.
    • Isolation: The protected properties are not linked to the standard object properties. For example, nonEdit.common is a separate property from obj.common and does not control the standard common object.
  4. Handle transactions with multi/exec in the simulator

    master

    The multi/exec command is integrated but specifically designed to work with pipelines. It provides a piped response and will not return results until exec is called.

    When exec is invoked, the simulator responds with:

    • OK for the multi command.
    • QUEUED for every command in the pipeline.
    • An array containing the real results for the exec command.
  5. Understand Adapter modes and types

    master

    Adapters in ioBroker can operate in different modes depending on their lifecycle requirements:

    • deamon: Runs continuously. If the process is killed, it is automatically restarted. Ideal for continuous communication/actions. Supports restart schedules.
    • schedule: Starts based on a defined schedule (e.g., CRON), performs work, and stops itself. Uses resources only when active.
    • once: Starts only once after its associated object is modified. Does not restart after stopping.
    • none: No active process (e.g., a webExtension running client-side).

    Note on CRON schedules: For schedule type adapters using CRON, if seconds are not specified, the execution may be delayed randomly by up to 60 seconds to prevent DDoS-like patterns. To ensure exact timing, specify the seconds in your CRON expression.

  6. Understand the PendingReply interface

    master

    The PendingReply interface is an internal structure used by the MessagingManager within the @iobroker/js-controller-adapter. It represents an entry in the pending-reply registry created when a sendTo call is made with the expectReply=true option.

    This interface manages the lifecycle of an asynchronous request that expects a response, providing the mechanisms to either resolve the request with data or reject it with an error, along with timing information to handle timeouts.