Ecosystems

Overview

An ecosystem in droplit.io is the highest level in organizational structure.

You should create a single ecosystem for a single application or product. It contains all items that are reusable for your application.

Nothing can be shared across ecosystems.

Ecosystem Items

An ecosystem contains:

• Environments
• Service Classes
• Clients
• Webhooks
• Users

Ownership and Access

If you create an ecosystem, you become its owner. As the owner you can grant other developers access to your ecosystem. An ecosystem cannot access conduits or users from another ecosystem; ecosystems are entirely independent from one another. Since assets are stored outside the scope of ecosystems, however, they may be used by more than one ecosystem.

Both conduits and users are restricted to their respective ecosystem; they may not be migrated to another. Only one conduit may be installed per ecosystem; the conduits are intended to be shared across all an ecosystem's environments.

Commands

Device control commands cannot be issued directly to an ecosystem. The highest scope to which commands can be issued is Environments.

Domains

Lengthy IDs may be aliased to human readable domains. A domain is created by editing the domain key.

Domains must meet the following requirements:

• globally unique: domains must be unique with respect to all other existing domains
• permitted characters: a-z, 0-9, -, no spaces
• character limit: 24

Indicating Device Availability

Some system-defined metadata keys are available to control a device's availability and accessibility. If a device is set to not be active, it cannot receive notifications, nor can it be interacted with in any way. It can, however, still be included in device configurations so that it can be seamlessly reactivated.

$activeDeviceMode

Specify the ecosystem's treatment of the isActive flag.

• disabled: The ecosystem will ignore its devices' isActive flag.
• enabled: The ecosystem will acknowledge its devices' isActive flag.
• inactiveWhenSpecified: When enabled, if a device does not have the isActive flag, it is automatically set to inactive. The default behavior is to set the device to active.

$allowInactiveDeviceCommands

Specify how the isActive flag directs the routing of device commands.

• none: No commands will be sent to inactive devices.
• all: Commands will be sent normally to inactive devices.
• unicastOnly: Only devices equipped with unicast will be sent commands.

$inactiveDeviceLogging

Specify how the isActive flag determines the storage policy for a device's logs.

• none: The logs of inactive devices will not be stored.
• all: The logs of inactive devices will continue to be stored.

$inactiveDeviceServiceNotifications

Specify how the isActive flag determines the handling of the devices' service notifications.

• none: Inactive devices will not produce service notifications.
• all: Inactive devices will continue to produce service notifications.

$newDeviceIsActiveState

Specify how the ecosystem sets the isActive flag upon the discovery of a new device.

• unspecified: The ecosystem will not set the isActive flag of new devices.
• inactive: The ecosystem will automatically set the isActive flag of new devices to inactive.
• active: The ecosystem will automatically set the isActive flag of new devices to active.