Reference · built on requestConnectorBuilding management platforms

Switch Automation

Sites, devices, sensors, and time-series readings from the Switch Automation Platform through the switch-api Python package.

Request accessPricing ↗

About

Switch Automation is a building data platform that holds portfolios of sites, devices, sensors, tags, and readings, with data feeds and tasks that ingest and act on them. Its published developer interface is the switch-api package on PyPI, for Python 3.8 or later. After sw.initialize with a Portfolio ID opens a browser login, the integration module retrieves and upserts sites, device sensors, tags, work orders, and reservations; the dataset module queries data sets; the controls module submits control requests to sensors; and the automation module registers tasks and deploys them on timers or on email, FTP, upload, webhook, or CDS data feeds.

Through Fibric, an operator reads sensor readings and work orders from a portfolio and proposes a control request or a work order upsert for your approval. You get a receipt for each: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Switch Automation and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Sites through get_sites(), including YearBuilt and Floors, with optional tag groups
  • Devices and sensors through get_device_sensors(), with tag groups and metadata keys
  • Readings through get_data() against Azure Data Explorer with SQL or KQL, and dataset.get_data() for data sets
  • Templates and units of measure through get_templates() and get_units_of_measure()
  • Work orders and reservations kept in the platform, written by upsert_workorders() and upsert_reservations()

Proposed actions

  • Target capability: propose a control request to sensors through submit_control(), with a priority and a timeout
  • Target capability: propose upsert_workorders() to create or update work order records
  • Target capability: propose upsert_timeseries() of readings with InstallationId, ObjectPropertyId, Timestamp, and Value
  • Target capability: propose upsert_tags() at Site, Device, or Sensor level

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Send a set point with a timeout

    Read the sensor's current value through get_device_sensors(), then propose submit_control() with a priority and a timeout so the write reverts on its own.

    With Setpoint Drift, Comfort Complaint

  • Raise the work order where the data says

    Query readings with get_data(), detect a failing device, and propose upsert_workorders() with the reading window attached.

    With Predictive Maintenance, Work Order Aging

  • Fill gaps before the report

    Compare last-record timestamps per sensor, flag stale feeds, and propose a datafeed run through run_data_feed() for your approval.

    With Data Freshness, Sensor Health

Requirements

  • A Switch Automation user account and the Portfolio ID copied from Configure > Portfolios > Edit
  • Python 3.8 or later with the switch-api package installed
  • The correct data center, AU or US; omitting it defaults to US with a logged warning
  • For controls, a gateway connected to the site's MQTT broker, which submit_control checks before sending
Authentication
Interactive Switch Platform login: sw.initialize(api_project_id=<Portfolio ID>, data_center='AU' or 'US') opens a browser to the platform login and returns the api_inputs object used by every call.

Limits

  • Authentication is an interactive browser login; no client-credential or API-key path is documented, so a session strategy is agreed per deployment
  • Timeseries CSV uploads are partitioned at 3 MB per file, and reading summaries need complete calendar days of data
  • Control requests go in batches of 50; sensors without a priority array revert to DefaultControlValue or the prior value on timeout
  • The package changes often (0.6.30 at writing); function signatures move with it

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Switch Automation ↗

Questions and answers

How does the switch-api package authenticate?
sw.initialize(api_project_id=...) opens a web browser to the Switch Platform login. Version 0.6.29 added a data_center argument, AU or US, which selects the login endpoint and the B2C authority (AustraliaEast or CentralUs). The returned api_inputs object is passed to every other call.
Can the package write to equipment?
Yes, through the controls module. submit_control() sends control requests and returns status and writeStatus per row; submit_control_continue() batches 50 per request over the IoT endpoint or MQTT. Sensors without a priority array revert to DefaultControlValue when a timeout elapses.
What task types can be deployed?
IntegrationTask, DiscoverableIntegrationTask, AnalyticsTask, LogicModuleTask, QueueTask, EventWorkOrderTask, IQTask, and Guide. register_task() checks for an existing TaskID or TaskName, then deploy_on_timer() with a cron expression or an email, FTP, upload, webhook, or CDS data-feed deployment schedules it.
Ask about Switch Automation

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Switch Automation through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy