If your physical or virtual hardware is not already supported by an existing module, you can create a new module to add support for it.
You can keep the module private or share it with your organization or the public.
You can use built-in tools to manage versioning and deployment to machines as you iterate on your module.
If you want to create a "custom module", this page provides instructions for creating one in Python and Go.
This page provides instructions for creating and uploading a module in Python or Go.
For C++ module examples, see the C++ examples directory on GitHub.
If you want to create a module for use with a microcontroller, see Modules for ESP32.
How to design your module
If you want to plan your module before you write it, you can use the following steps to design your module:
Write a test script (optional)
You can think of a module as a packaged wrapper around some script, that takes the functionality of the script and maps it to a standardized API for use within the Viam ecosystem.
Start by finding or writing a test script to check that you can connect to and control your hardware from your computer, perhaps using the manufacturer’s API or other low-level code.
Choose an API
Decide exactly what functionality you want your module to provide in terms of inputs and outputs.
With this in mind, look through the component APIs and choose one that fits your use case.
Each model implements one API.
For example, if you just need to get readings or other data and don’t need any other endpoints, you could use the sensor API, which contains only the GetReadings method (as well as the methods that all Viam resources implement: Reconfigure, DoCommand, GetResourceName, and Close).
You do not need to fully implement all the methods of an API.
For example, if you want to use the camera API because you want to return images, but your camera does not get point cloud data, you can implement the GetImage method but for the GetPointCloud method you can return nil and an “unimplemented” error or similar, depending on the method and the language you use to write your module.
If you need a method that is not in your chosen API, you can use the flexible DoCommand (which is built into all component APIs) to create custom commands.
Decide on configuration attributes and dependencies
Make a list of required and optional attributes for users to configure when adding your module to a machine.
For example, you can require users to configure a path from which to access data, or a pin to which a device is wired, and you could allow them to optionally change a frequency from some default.
You’ll need to add these attributes to the Validate and Reconfigure functions when you write the module.
Write your module
Generate stub files
The easiest way to generate the files for your module is to use the Viam CLI:
Install the Viam CLI and authenticate to Viam, from the same machine that you intend to upload your module from.
You can also install the Viam CLI using brew on Linux amd64 (Intel x86_64):
brew tap viamrobotics/brews
brew install viam
Download the binary and run it directly to use the Viam CLI on a Windows computer.
If you have Go installed, you can build the Viam CLI directly from source using the go install command:
go install go.viam.com/rdk/cli/viam@latest
To confirm viam is installed and ready to use, issue the viam command from your terminal.
If you see help instructions, everything is correctly installed.
If you do not see help instructions, add your local go/bin/* directory to your PATH variable.
If you use bash as your shell, you can use the following command:
This will open a new browser window with a prompt to start the authentication process. If a browser window does not open, the CLI will present a URL for you to manually open in your browser. Follow the instructions to complete the authentication process.
Use your organization, location, or machine part API key and corresponding API key ID in the following command:
viam login api-key --key-id <api-key-id> --key <organization-api-key-secret>
Run the module generate command in your terminal.
If you are writing your module using Python, you must have Python version 3.11 or newer installed on your computer for this command to work:
viam module generate
Follow the prompts.
Click for more details about each prompt
Prompt
Description
Module name
The module name describes the module or the family of devices it supports. It is generally the same as the name of the GitHub repo where you will put your module code.
Language
The language for the module.
Visibility
Choose Private to share only with your organization, or Public to share publicly with all organizations. If you are testing, choose Private.
Namespace/Organization ID
In the Viam app, navigate to your organization settings through the menu in upper right corner of the page. Find the Public namespace (or create one if you haven’t already) and copy that string. If you use the organization ID, you must still create a public namespace first.
Name your component model based on what it supports, for example, if it supports a model of ultrasonic sensor called “XYZ Sensor 1234” you could call your model xyz_1234 or similar. Must be all-lowercase and use only alphanumeric characters (a-z and 0-9), hyphens (-), and underscores (_).
Enable cloud build
If you select Yes (recommended) and push the generated files (including the .github folder) and create a release of the format vX.X.X, the module will build and upload to the Viam registry and be available for all Viam-supported architectures without you needing to build for each architecture. Yes also makes it easier to upload using PyInstaller by creating a build entrypoint script. You can select No if you will always build the module yourself before uploading it.
Register module
Select Yes unless you are creating a local-only module for testing purposes and do not intend to upload it. Registering a module makes its name and metadata appear in the Viam app registry page; uploading the actual code that powers the module is a separate step. If you decline to register the module at this point, you can run viam module create to register it later.
The generator will create a folder containing stub files for your modular sensor component.
In the next section, you’ll customize some of the generated files to support your sensor.
Creating multiple models within one module
If you have multiple modular components that are related to or even dependent upon each other, you can opt to put them all into one module.
Note that each model can implement only one API.
For an example of how this is done, see Create a Hello World module.
Edit the reconfigure function, which gets called when the user changes the configuration.
This function should do the following:
If you assigned any configuration attributes to global variables, get the values from the latest config object and update the values of the global variables.
Assign default values as necessary to any optional attributes if the user hasn’t configured them.
If your module has dependencies, get the dependencies from the dependencies map and cast each resource according to which API it implements, as in this ackermann.py example.
4
Edit the methods you want to implement:
For each method you want to implement, replace the body of the method with your relevant logic.
Make sure you return the correct type in accordance with the function’s return signature.
You can find details about the return types at python.viam.dev.
Example code for a sensor module
The following code implements the sensor API by getting weather data from Open-Meteo and returning it using the get_readings function.
The validate and reconfigure functions have been edited so that the user can configure coordinates from which to get weather data, but if the user does not configure these optional attributes, defaults are assigned.
import asyncio
from typing import Any, ClassVar, Final, Mapping, Optional, Sequence
from typing_extensions import Self
from viam.components.sensor import Sensor
from viam.module.module import Module
from viam.proto.app.robot import ComponentConfig
from viam.proto.common import ResourceName
from viam.resource.base import ResourceBase
from viam.resource.easy_resource import EasyResource
from viam.resource.types import Model, ModelFamily
from viam.utils import SensorReading, struct_to_dict
import openmeteo_requests
import requests_cache
from retry_requests import retry
class meteo_PM(Sensor, EasyResource):
MODEL: ClassVar[Model] = Model(
ModelFamily("jessamy", "weather"), "meteo_PM")
@classmethod
def new(
cls, config: ComponentConfig, dependencies: Mapping[
ResourceName, ResourceBase]
) -> Self:
"""This method creates a new instance of this Sensor component.
The default implementation sets the name from the `config` parameter
and then calls `reconfigure`.
"""
return super().new(config, dependencies)
@classmethod
def validate_config(cls, config: ComponentConfig) -> Sequence[str]:
"""This method allows you to validate the configuration object
received from the machine, as well as to return any
dependencies based on that `config`.
"""
fields = config.attributes.fields
# Check that configured fields are floats
if "latitude" in fields:
if not fields["latitude"].HasField("number_value"):
raise Exception("Latitude must be a float.")
if "longitude" in fields:
if not fields["longitude"].HasField("number_value"):
raise Exception("Longitude must be a float.")
return []
def reconfigure(
self, config: ComponentConfig, dependencies: Mapping[
ResourceName, ResourceBase]
):
"""This method allows you to dynamically update your service
when it receives a new `config` object.
"""
attrs = struct_to_dict(config.attributes)
self.latitude = float(attrs.get("latitude", 45))
self.logger.debug("Using latitude: " + str(self.latitude))
self.longitude = float(attrs.get("longitude", -121))
self.logger.debug("Using longitude: " + str(self.longitude))
return super().reconfigure(config, dependencies)
async def get_readings(
self,
*,
extra: Optional[Mapping[str, Any]] = None,
timeout: Optional[float] = None,
**kwargs
) -> Mapping[str, SensorReading]:
# Set up the Open-Meteo API client with cache and retry on error
cache_session = requests_cache.CachedSession(
'.cache', expire_after=3600)
retry_session = retry(cache_session, retries=5, backoff_factor=0.2)
openmeteo = openmeteo_requests.Client(session=retry_session)
# The order of variables in hourly or daily is
# important to assign them correctly below
url = "https://air-quality-api.open-meteo.com/v1/air-quality"
params = {
"latitude": self.latitude,
"longitude": self.longitude,
"current": ["pm10", "pm2_5"],
"timezone": "America/Los_Angeles"
}
responses = openmeteo.weather_api(url, params=params)
# Process location
response = responses[0]
# Current values. The order of variables needs
# to be the same as requested.
current = response.Current()
current_pm10 = current.Variables(0).Value()
current_pm2_5 = current.Variables(1).Value()
self.logger.info(current_pm2_5)
# Return a dictionary of the readings
return {
"pm2_5": current_pm2_5,
"pm10": current_pm10
}
if __name__ == "__main__":
asyncio.run(Module.run_from_registry())
You can find more examples by looking at the source code GitHub repos linked from each module in the Viam Registry.
5
Add logging messages as desired.
The following log severity levels are available for resource logs:
# Within some method, log information:
self.logger.debug("debug info")
self.logger.info("info")
self.logger.warn("warning info")
self.logger.error("error info")
self.logger.exception("error info", exc_info=True)
self.logger.critical("critical info")
Resource-level logs are recommended instead of global logs for modular resources, because they make it easier to determine which component or service an error is coming from.
Resource-level error logs appear in the ERROR LOGS section of each resource’s configuration card in the app.
If you need to publish to the global machine-level logs instead of using the recommended resource-level logging, you can follow this example:
# In your import block, import the logging package:
from viam.logging import getLogger
# Before your first class or function, define the LOGGER variable:
LOGGER = getLogger(__name__)
# in some method, log information
LOGGER.debug("debug info")
LOGGER.info("info info")
LOGGER.warn("warn info")
LOGGER.error("error info")
LOGGER.exception("error info", exc_info=True)
LOGGER.critical("critical info")
6
Edit the generated requirements.txt file to include any packages that must be installed for the module to run.
Depending on your use case, you may not need to add anything here beyond viam-sdk which is auto-populated.
resource.AlwaysRebuild provides an implementation of Reconfigure that returns a NewMustRebuild error.
This error doesn’t exist in the other SDKs, so AlwaysRebuild is not supported in those SDKs.
1
Open module.go and add necessary imports.
2
Add any configurable attributes to the Config struct.
3
Edit the Validate function to do the following:
Check that the user has configured required attributes and return errors if they are missing.
(Optional) Create and edit a Reconfigure function:
In most cases, you can omit this function and leave resource.AlwaysRebuild in the Config struct.
This will cause viam-server to fully rebuild the resource each time the user changes the configuration.
If you need to maintain the state of the resource, for example if you are implementing a board and need to keep the software PWM loops running, you should implement this function so that viam-server updates the configuration without rebuilding the resource from scratch.
In this case, your Reconfigure function should do the following:
If you assigned any configuration attributes to global variables, get the values from the latest config object and update the values of the global variables.
Assign default values as necessary to any optional attributes if the user hasn’t configured them.
For an example that implements the Reconfigure method, see mybase.go on GitHub.
5
Edit the constructor to do the following:
If you didn’t create a Reconfigure function, use the constructor to assign default values as necessary to any optional attributes if the user hasn’t configured them.
If you created a Reconfigure function, make your constructor call Reconfigure.
6
Edit the methods you want to implement:
For each method you want to implement, replace the body of the method with your relevant logic.
Make sure you return the correct type in accordance with the function’s return signature.
You can find details about the return types at go.viam.com/rdk/components.
Example code for a camera module
This example from Hello World module implements only one method of the camera API by returning a static image.
It demonstrates a required configuration attribute (image_path) and an optional configuration attribute (example_value).
You can find more examples by looking at the source code GitHub repos linked from each module in the Viam Registry.
7
Add logging messages as desired.
You can add log messages with various levels of severity:
fn (c *component) someFunction(ctx context.Context, a int) {
// Log with severity info:
c.logger.CInfof(ctx, "performing some function with a=%v", a)
// Log with severity debug (using value wrapping):
c.logger.CDebugw(ctx, "performing some function", "a" ,a)
// Log with severity warn:
c.logger.CWarnw(ctx, "encountered warning for component", "name", c.Name())
// Log with severity error without a parameter:
c.logger.CError(ctx, "encountered an error")
}
Note
In order to see debug logs when using your modular resource, you’ll need to run viam-server with the -debug option.
Test your module locally
It’s a good idea to test your module locally before uploading it to the Viam Registry.
You’ll configure it through the Viam app, but the configured module will consist of local files.
Prerequisite: A running machine connected to the Viam app.
You can write a module without a machine, but to test your module you’ll need a machine.
Make sure to physically connect your sensor to your machine’s computer to prepare your machine for testing.
Add a new machine in the Viam app.
On the machine’s page, follow the setup instructions to install viam-server on the computer you’re using for your project.
Wait until your machine has successfully connected to the Viam app.
Create a reload.sh script in your module directory.
You’ll use this for local testing and can delete it before you upload your module.
Paste the following contents into it and save the file:
#!/usr/bin/env bash
# bash safe mode. look at `set --help` to see what these are doing
set -euxo pipefail
cd $(dirname $0)
MODULE_DIR=$(dirname $0)
VIRTUAL_ENV=$MODULE_DIR/venv
PYTHON=$VIRTUAL_ENV/bin/python
./setup.sh
# Be sure to use `exec` so that termination signals reach the python process,
# or handle forwarding termination signals manually
exec $PYTHON src/main.py $@
Make your reload script executable by running the following command in your module directory:
chmod 755 reload.sh
Create a virtual Python environment with the necessary packages by running the setup file from within the module directory:
sh setup.sh
Edit your meta.json, replacing the "entrypoint", "build", and "path" fields as follows:
Run the following command to build and start your module and push it to your machine:
viam module reload <insert relevant named args>
Reload example commands
For example, to run on your development machine:
viam module reload --local
Or to run on a different machine (such as a single-board computer), specify the part ID of the remote machine:
viam module reload --part-id 123abc45-1234-432c-aabc-z1y111x23a00
For more information, run the command with the -h flag or see the CLI documentation.
Reload troubleshooting
Error: Could not connect to machine part: context deadline exceeded; context deadline exceeded; mDNS query failed to find a candidate
Try specifying the --part-id, which you can find by clicking the Live indicator on your machine’s page in the Viam app and clicking Part ID.
Error: Rpc error: code = Unknown desc = stat /root/.viam/packages-local: no such file or directory
Try specifying the --home directory, for example /Users/jessamy/ on macOS.
Error: Error while refreshing token, logging out. Please log in again
Run viam login to reauthenticate the CLI.
Try using a different command
If you are still having problems with the reload command, you can use a different, slower method of rebuilding and then restarting the module.
Run the following command to rebuild your module:
viam module build local
Then restart it in your machine’s CONFIGURE tab in the Viam app.
In upper right corner of the module’s card, click the … menu, then click Restart.
When you run viam module reload, the module will be added to your device automatically.
On your machine’s CONFIGURE tab in the Viam app, click the + (create) icon in the left-hand menu.
Select Local module, then Local module.
Enter the absolute path to the run.sh script, for example /home/jessamy/my-module/run.sh on Linux, or /Users/jessamy/my-python-sensor-module/run.sh on macOS.
For modules configured this way, viam-server uses this path instead of the entrypoint field in your meta.json file.
Click Create.
On your machine’s CONFIGURE tab in the Viam app, click the + (create) icon in the left-hand menu.
Select Local module, then Local module.
Enter the absolute path to the /bin/<module-name> executable, for example /home/jessamy/my-go-module/bin/mymodule on Linux, or /Users/jessamy/my-go-module/bin/mymodule on macOS.
For modules configured this way, viam-server uses this path instead of the entrypoint field in your meta.json file.
Click Create.
3
Configure the model provided by your module
Click the + button again, this time selecting Local module and then Local component.
Select or enter the model namespace triplet, for example jessamy:weather:meteo-PM.
You can find the triplet in the model field of your meta.json file.
Select the Type corresponding to the API you implemented.
Enter a Name such as my-cool-component.
Click Create.
Configure any required attributes using proper JSON syntax.
4
Test the component
Click the TEST bar at the bottom of your modular component configuration, and check whether it works as expected.
For example, if you created a sensor component, check whether readings are displayed.
5
Iterate
If your component works, you’re almost ready to share your module by uploading it to the registry.
If not, you have some debugging to do.
Each time you make changes to your local module code, you need to update its instance on your machine:
Since you are using run.sh instead of a built executable, you do not need to rebuild anything as you iterate.
Just save your code changes, then restart the module in your machine’s CONFIGURE tab in the Viam app:
In upper right corner of the module’s card, click … menu, then click Restart.
Run the following command to rebuild your module:
viam module build local
Then restart it in your machine’s CONFIGURE tab in the Viam app.
In upper right corner of the module’s card, click … menu, then click Restart.
Once you are done testing locally, you can upload your module to the Viam Registry and make it available either to all machines in your organization, or to the general public.
1
Create a README (optional)
It’s quite helpful to create a README to document what your module does and how to use it, especially if you plan to share your module with others.
Example sensor module README
# `meteo_PM` modular component
This module implements the [Viam sensor API](https://docs.viam.com/dev/reference/apis/components/sensor/) in a `jessamy:weather:meteo_PM` model.
With this model, you can gather [Open-Meteo](https://open-meteo.com/en/docs/air-quality-api) PM2.5 and PM10 air quality data from anywhere in the world, at the coordinates you specify.
Navigate to the **CONFIGURE** tab of your machine's page in the [Viam app](https://app.viam.com/).
Click the **+** button, select **Component or service**, then select the `sensor / weather:meteo_PM` model provided by the [`weather` module](https://app.viam.com/module/jessamy/weather).
Click **Add module**, enter a name for your sensor, and click **Create**.
## Configure your `meteo_PM` sensor
On the new component panel, copy and paste the following attribute template into your sensor's **Attributes** box:
```json
{
"latitude": <float>,
"longitude": <float>
}
```
### Attributes
The following attributes are available for `rdk:sensor:jessamy:weather:meteo_PM` sensors:
| Name | Type | Inclusion | Description |
| ----------- | ----- | --------- | -------------------------------------- |
| `latitude` | float | Optional | Latitude at which to get the readings |
| `longitude` | float | Optional | Longitude at which to get the readings |
### Example Configuration
```json
{
"latitude": -40.6,
"longitude": 93.125
}
```
2
Create a GitHub repo and link to it from your meta.json
Create a GitHub repository with all the source code and the README for your module.
This is required for cloud build to work.
Add the link to that repo as the url in the meta.json file.
3
Edit the meta.json file
Make any necessary edits to the meta.json file.
For example, if you’ve changed the module’s functionality, update the description in the meta.json file.
Click below for information about the available fields.
meta.json reference
Name
Type
Inclusion
Description
module_id
string
Required
The module ID, which includes either the module namespace or organization ID, followed by its name.
Caution
The module_id uniquely identifies your module.
Do not change the module_id.
visibility
string
Required
Whether the module is accessible only to members of your organization (private), or visible to all Viam users (public). You can later make a private module public using the viam module update command. Once you make a module public, you can change it back to private if it is not configured on any machines outside of your organization.
url
string
Required for cloud build
The URL of the GitHub repository containing the source code of the module. Cloud build will fail if you do not provide this. Optional for local modules.
description
string
Required
A description of your module and what it provides.
models
object
Required
A list of one or more models provided by your custom module. You must provide at least one model, which consists of an api and model key pair. If you are publishing a public module ("visibility": "public"), the namespace of your model must match the namespace of your organization.
You are strongly encouraged to include a markdown_link to the section of the README containing configuration information about each model, so that the section will be displayed alongside the configuration panel when configuring the model. For example, "README.md#configure-your-meteo_pm-sensor". Please also include a short_description describing what hardware the model supports.
entrypoint
string
Required
The name of the file that starts your module program. This can be a compiled executable, a script, or an invocation of another program. If you are providing your module as a single file to the upload command, provide the path to that single file. If you are providing a directory containing your module to the upload command, provide the path to the entry point file contained within that directory.
build
object
Optional
An object containing the command to run to build your module, as well as optional fields for the path to your dependency setup script, the target architectures to build for, and the path to your built module. Use this with the Viam CLI's build subcommand.
markdown_link
string
Optional
Link to the documentation (README) for this module. The Viam app uses this to render your README on your module's page in the registry. Similar to the markdown_link within the models object (described above), which allows the app to render info for a specific model in the configuration panel.
$schema
string
Optional
Enables VS Code hover and autocomplete as you edit your module code. Gets auto-generated when you run viam module generate or viam module create. Has no impact on the module's function.
4
Package and upload
To package (for Python) and upload your module and make it available to configure on machines in your organization (or in any organization, depending on how you set visibility in the meta.json file):
The recommended approach for Python is to use PyInstaller to compile your module into a packaged executable: a standalone file containing your program, the Python interpreter, and all of its dependencies.
When packaged in this fashion, you can run the resulting executable on your desired target platform or platforms without needing to install additional software or manage dependencies manually.
Note
To follow these PyInstaller packaging steps, you must have enabled cloud build when moving through the module generator prompts.
If you did not, you will need to manually create a build.sh entrypoint script.
Edit your meta.json file back to its original state, reverting the edits you made for local testing purposes.
It should resemble the following:
Delete the reload.sh script since it was only meant for testing purposes.
Now you are ready to build and upload your module, either using Viam’s cloud build tooling which is recommended for continuous integration, or a more manual process:
We recommend you use PyInstaller with the build-action GitHub action which provides a simple cross-platform build setup for multiple platforms: x86 and Arm Linux distributions, and MacOS.
The viam module generate command already generated the build-action file in your .github/workflows folder, so you just need to set up authentication in GitHub, and then create a new release to trigger the action:
In your terminal, run viam organizations list to view your organization ID.
Create an organization API key by running the following command:
viam organization api-key create --org-id YOUR_ORG_UUID --name descriptive-key-name
In the GitHub repo for your project, go to Settings → Secrets and variables → Actions.
Create two new secrets using the New repository secret button:
VIAM_KEY_ID with the UUID from Key ID: in your terminal
VIAM_KEY_VALUE with the string from Key Value: in your terminal
From the main code page of your GitHub repo, find Releases in the right side menu and click Create a new release.
In the Choose a tag dropdown, create a new tag such as 1.0.0.
Do not prepend the tag with v or the GH action will not trigger.
For details about versioning, see Module versioning.
Click Publish release.
The cloud build action will begin building the new module version for each architecture listed in your meta.json, and any machines configured to use the latest release of the module will receive the update once it has finished building.
From within the module directory, create a virtual Python environment with the necessary packages and then build an executable by running the setup and build scripts:
sh setup.sh
sh build.sh
Run the viam module upload CLI command to upload the module to the registry, replacing any with one or more of linux/any or darwin/any if your module requires Linux OS-level support or macOS OS-level support, respectively.
If your module does not require OS-level support (such as platform-specific dependencies), you can run the following command exactly:
viam module upload --version 1.0.0 --platform any dist/archive.tar.gz
The viam module upload command only supports one platform argument at a time.
If you would like to upload your module with support for multiple platforms, you must run a separate viam module upload command for each platform.
Use the same version number when running multiple upload commands of the same module code if only the platform support differs.
The Viam Registry page for your module displays the platforms your module supports for each version you have uploaded.
Note
PyInstaller does not support relative imports in entrypoints (imports starting with .).
If you get "ImportError: attempted relative import with no known parent package", set up a stub entrypoint as described on GitHub.
In addition, PyInstaller does not support cross-compiling: you must compile your module on the target architecture you wish to support.
For example, you cannot run a module on a Linux arm64 system if you compiled it using PyInstaller on a Linux amd64 system.
Viam makes this easy to manage by providing a build system for modules.
Follow these instructions to automatically build for each system your module can support using Viam’s CLI.
You can use the following package and upload method if you opted not to enable cloud build when you ran viam module generate.
To package the module as an archive, run the following command from inside the module directory:
tar -czf module.tar.gz run.sh setup.sh requirements.txt src meta.json
where run.sh is your entrypoint file, requirements.txt is your pip dependency list file, and src is the directory that contains the source code of your module.
This creates a tarball called module.tar.gz.
Run the viam module upload CLI command to upload the module to the registry, replacing any with one or more of linux/any or darwin/any if your module requires Linux OS-level support or macOS OS-level support, respectively.
If your module does not require OS-level support (such as platform-specific dependencies), you can run the following command exactly:
viam module upload --version 1.0.0 --platform any module.tar.gz
The viam module upload command only supports one platform argument at a time.
If you would like to upload your module with support for multiple platforms, you must run a separate viam module upload command for each platform.
Use the same version number when running multiple upload commands of the same module code if only the platform support differs.
The Viam Registry page for your module displays the platforms your module supports for each version you have uploaded.
From within your module’s directory, run the viam module upload CLI command to upload the module to the registry, replacing <platform> with linux/amd64, linux/arm64, or one or more other platforms depending on what your module requires.
viam module upload --version 1.0.0 --platform <platform> .
The viam module upload command only supports one platform argument at a time.
If you would like to upload your module with support for multiple platforms, you must run a separate viam module upload command for each platform.
Use the same version number when running multiple upload commands of the same module code if only the platform support differs.
The Viam Registry page for your module displays the platforms your module supports for each version you have uploaded.
Now, if you look at the Viam Registry page while logged into your account, you’ll be able to find your module listed.
Use your uploaded module
Now that your module is in the registry, you can test the registry version of your module on one machine, and then add it to more machines.
Configure it just as you would configure any other component or service in the registry:
Go to your machine’s CONFIGURE tab in the Viam app.
Click the + button, select Component or service, and search for and select your model.
Click Add module, enter a name for your resource, and click Create.
Configure any required attributes.
Save your configuration.
You can delete the local module; it is no longer needed.
Add commentMore actions
A previous version of the CLI module generator created `__init__.py` files, but now uses a different module structure.
We recommend using what the current generator creates rather than old examples that use `__init__.py` files.
The same applies for edits to main.py: Some older example modules define async def main() inside main.py, but you should generally use the generated main.py file as it is.