Author: Chris

If you use Hubitat and depend on your calendar, you have probably wanted a clean way to turn “I’m busy” into automations. Hubitat Calendar Switch (OAuth) does exactly that, using direct OAuth connections to Google Calendar and Microsoft 365 (Outlook).

This project installs as a Hubitat app plus a child switch driver. The app handles authentication and event fetching. Each switch holds its own rules (must include words, ignore words, timing buffers, and filters) and controls its own On/Off state. From there, you can use the switch in Rule Machine, Mode Manager, notifications, dashboards, and more.

What it does

• Connects to Google Calendar and/or Microsoft 365 using OAuth (no ICS feed required)
• Fetches calendar events on a schedule and normalizes them into a consistent event list
• Creates one virtual switch per rule set (example: Work Busy, Kids Sports, Do Not Disturb)
• Turns the switch On when a matching event is active (with optional before/after buffers), and Off when no matching event is active
• Lets each switch define its own match logic:
  • Must include words (optional)
  • Ignore words (optional)
  • Timing (minutes before start, minutes after end)
  • Filters (busy-only, all-day allowed, private allowed)
• Includes device-level “Fetch now and apply” / “Test now” tools for quick validation

Why this is useful

• Quiet hours when a “Meeting” event is active
• Auto-silence announcements, chimes, or TTS during appointments
• Pause robot vacuums during calls
• Trigger “work mode” only when your calendar shows you are busy
• Drive dashboard indicators (Busy / Free, In a meeting, Do Not Disturb)
• Run different switches for different rule sets (Work vs Personal, specific keywords, etc.)

How it works (high level)

1. Authenticate the app to Google and/or Microsoft (OAuth)
2. The app fetches events every X minutes (configurable)
3. Each switch re-evaluates every minute using the most recently fetched events
4. The switch applies its own rules and decides whether it should be On or Off
5. You use the switch state in automations anywhere in Hubitat

One important design choice: the app does not implement keyword matching. All match rules live on the child switch. This keeps the system simple to reason about (one switch = one set of rules) and makes switch behavior easy to test and tune.

Getting started

Prerequisites

• A Hubitat Elevation hub
• A Google account (for Google Calendar) and/or Microsoft account (for Microsoft 365 / Outlook)
• OAuth credentials:
  • Google Cloud Console (Client ID + Client Secret), and/or
  • Microsoft Entra ID (Azure) App Registration (Client ID + Client Secret)

Install and configure

1. Install the child driver in Hubitat (Drivers Code)
2. Install the app in Hubitat (Apps Code) and enable OAuth for the app
3. Add the app (Apps – Add User App)
4. Enter your Google and/or Microsoft credentials and click Authorize
5. Add a switch:
   • Choose provider
   • Name the switch
   • Optionally specify a calendar ID (Google supports targeting a specific calendar; Microsoft defaults to primary)
6. Open the switch device and set:
   • Must include words and/or Ignore words
   • Timing buffers (minutes before/after)
   • Filters (busy-only, all-day, private)
7. Use Test now (or Fetch now and apply) to validate behavior immediately

Support

If you need help, use the Support page on this site and include:

• Project name and version
• Hubitat model/firmware
• Provider (Google or Microsoft)
• What you expected vs what happened
• Steps to reproduce
• Relevant logs or screenshots (redact any tokens, secrets, or sensitive event details)

Hubitat Alexa Routine Trigger – Driver-Only (same results, fewer moving parts)

Overview

Driver-only edition is the lightweight version of Hubitat Alexa Routine Trigger. Instead of installing a Hubitat app plus multiple drivers, you install a single virtual device driver and create your trigger devices directly in Hubitat’s Devices page.

It still uses the same proven approach: Hubitat opens a virtual contact sensor, Alexa sees the Open event, and your Alexa routine runs. The device then auto-closes after a configurable delay so it is ready for the next trigger.

Why a driver-only edition

This version is for users who want the simplest possible install and the fewest moving parts:

• No Hubitat app to install or maintain
• Create triggers using Hubitat’s built-in “Add Virtual Device” flow
• Ideal for one-off triggers and smaller setups
• If you need bulk trigger creation, trigger groups, or an in-app management UI, use the full Hubitat Alexa Routine Trigger app package instead. README

Common use cases

• Trigger Alexa routines from Rule Machine automations
• Drive Alexa announcements, music, scenes, and smart home actions from Hubitat logic
• Create dedicated triggers for key automations (doorbell, washer done, bedtime, movie mode, etc.)

How it works

You create a virtual contact sensor in Hubitat and assign it this custom driver.

• Your Hubitat automation calls the driver’s trigger command (or opens the contact sensor).
• Alexa detects the sensor “Open” event and runs a routine.
• The driver auto-resets the sensor back to Closed after a set number of seconds.

Prerequisites

Hubitat Elevation hub

• Amazon Alexa account plus Alexa app
• Hubitat built-in integration: Amazon Echo Skill (required so Alexa can discover the trigger device)
• Important: this project relies on Hubitat’s Amazon Echo Skill. It does not replace it.

Install (Hubitat)

You will install:

One custom driver (driver-only edition)

Step 1 – install the driver

In Hubitat:

1. Go to Drivers Code.
2. Click New Driver.
3. Paste the driver code.
4. Save.

Step 2 – create a trigger device

In Hubitat:

1. Go to Devices.
2. Click Add Device.
3. Choose Virtual.
4. Create a Virtual Device.
5. Name it something Alexa-friendly (example: “Alexa Trigger – Movie Mode”).
6. For Type, select the driver you just installed (the driver-only trigger driver).
7. Save.

Step 3 – configure the device

On the device page, set:

Reset after (seconds)

Ignore repeated triggers from Hubitat within (ms)

Then click Save Preferences.

Alexa setup (required)

Step 1 – enable Hubitat’s Amazon Echo Skill

In Hubitat, add the built-in Amazon Echo Skill app and link it to Alexa.

Step 2 – expose your trigger device to Alexa

In the Amazon Echo Skill app, select the virtual contact sensor you created.

Step 3 – discover devices in Alexa

In the Alexa app, run device discovery. The trigger should appear as a contact sensor.

Create Alexa routines

Create one routine per trigger device:

When this happens – Smart Home – select the contact sensor – choose Open

Add the actions you want Alexa to run

Save

Using it from Hubitat automations

Rule Machine (typical)

In Rule Machine, add an action that runs the device command provided by the driver (commonly a Trigger command). This keeps routines reliable and avoids leaving the sensor open.

Recommended test order

Confirm Alexa can see the trigger device after discovery

Create an Alexa routine that triggers on Open

In Hubitat, press the driver’s Test button (if provided) or run the Trigger command

Confirm the Alexa routine runs, then confirm the contact sensor auto-closes

Understanding the key settings

Reset after (seconds)

How long the trigger stays Open before it automatically closes again. Typical values are 3–10 seconds. Setting this to 0 disables auto-close (not recommended for most users).

Ignore repeated triggers from Hubitat within (ms)

Prevents accidental double-fires caused by rapid repeated events. Set to 0 to disable. Typical values are 250–750 ms if you see duplicates.

Troubleshooting

Alexa routine does not trigger

Confirm the trigger device is selected in Hubitat’s Amazon Echo Skill app

Re-run Alexa device discovery

Confirm the routine triggers on Open (not Close)

Increase Reset after (seconds) slightly (example: 7–10)

Double-fires

Increase Ignore repeated triggers from Hubitat within (ms) (example: 250–750)

Security and privacy notes

This project creates local virtual devices and uses Hubitat’s Amazon Echo Skill to share them with Alexa.

Alexa routine execution occurs in Amazon’s ecosystem (as expected for Alexa routines).

No additional cloud services are required by this project beyond the built-in Hubitat-to-Alexa integration. README

Which version should you use?

Choose driver-only if you want:

• The simplest install (one driver)
• Just a few triggers
• No app UI or bulk management needs

Choose the full app package if you want:

• A guided setup UI in Hubitat
• Bulk trigger creation and management
• Trigger groups and sequencing (advanced) README

Support

If you need help, use the Support page on this site and include:

• Project name and version
• Hubitat model/firmware
• What you expected vs what happened
• Steps to reproduce
• Relevant logs or screenshots (redact any sensitive details)

Hubitat Alexa Routine Trigger – trigger Alexa routines from Hubitat (no custom skills)

Overview

Hubitat Alexa Routine Trigger is a Hubitat app + virtual device drivers that let you trigger Alexa routines from Hubitat using virtual contact sensors. Hubitat “opens” the contact sensor, Alexa sees the Open event, and your routine runs. The contact sensor then auto-closes after a configurable delay so it is ready for the next trigger.

Common use cases

• Trigger Alexa routines from Hubitat automations
• Use Hubitat rules to drive Alexa announcements, music, smart plugs, scenes, and more
• Fire multiple Alexa routines in a controlled sequence using trigger groups (advanced)

How it works

• The app creates one or more virtual contact sensors that act as Alexa triggers.
• Hubitat automations (Rule Machine, Button Controller, schedules, etc.) activate the trigger.
• Alexa runs a routine when the contact sensor reports Open.
• The device auto-resets (closes) after a defined number of seconds.

Setup and configuration

Two setup options
Option A – Single trigger (recommended)
Create one virtual contact sensor, expose it to Alexa, and build one Alexa routine that triggers on Open.

Option B – Trigger group (advanced)
Create multiple virtual contact sensors plus a group controller switch. When you activate the group, it fires the triggers in order, with an optional delay between each one. This is useful when you want Hubitat to trigger multiple Alexa routines sequentially and reliably.

Prerequisites

• Hubitat Elevation hub
• Amazon Alexa account + Alexa app
• Hubitat built-in integration: Amazon Echo Skill (required so Alexa can discover the trigger devices)

Important: this project relies on Hubitat’s Amazon Echo Skill. It does not replace it.

Install (Hubitat)
You will install:

1. the Hubitat app
2. the virtual device drivers used by the app

Install the drivers

• Add each driver under Drivers Code in Hubitat and save.

Install the app

• Add the app under Apps Code in Hubitat, save, then add it as a User App.

Create your triggers
Single trigger

• Pick a device name
• Set Reset after (seconds)
• Set Ignore repeated triggers from Hubitat within (ms)
• Create the trigger device

Trigger group (advanced)

• Pick a group name
• Choose the number of trigger devices
• Set Reset after (seconds)
• Set Ignore repeated triggers from Hubitat within (ms)
• Set Delay between trigger devices (ms)
• Create the trigger group

Alexa setup (required)
Step 1 – enable Hubitat’s Amazon Echo Skill

• In Hubitat, add the built-in Amazon Echo Skill app and link it to Alexa.

Step 2 – expose your trigger device(s) to Alexa

• In the Amazon Echo Skill app, select the trigger device(s) created by this project.
  • Single trigger: select the virtual contact sensor
  • Trigger group: select each trigger device (contact sensors). Optionally also expose the group controller switch.

Step 3 – discover devices in Alexa

• In the Alexa app, run device discovery. The triggers should appear as contact sensors.

Create Alexa routines
Create one Alexa routine per trigger device:

• When this happens – Smart Home – select the contact sensor – choose Open
• Add the actions you want Alexa to run
• Save

Tip for trigger groups
Each trigger device maps to its own Alexa routine. When you run the group from Hubitat, it fires trigger 1, then trigger 2, then trigger 3, etc., using the delay you configured.

Understanding the key settings
Reset after (seconds)
How long the trigger stays Open before it automatically closes again. Default is typically 5 seconds. Setting this to 0 disables auto-close (not recommended for most users).

Ignore repeated triggers from Hubitat within (ms)
Prevents accidental double-fires caused by rapid repeated events. Set to 0 to disable. Applies to both single triggers and trigger groups.

Delay between trigger devices (ms) (groups only)
Spacing between each trigger firing when you run the group. Set to 0 to fire all triggers at the same time. If Alexa misses triggers, try 300–800 ms.

Testing
Recommended test order:

1. Confirm Alexa can see the trigger device after discovery
2. Create an Alexa routine that triggers on Open
3. In Hubitat, use the app’s test function to fire the trigger
4. Watch the Alexa routine run, then confirm the contact sensor auto-closes

Troubleshooting
Alexa routine does not trigger

• Confirm the trigger device is selected in Hubitat’s Amazon Echo Skill app
• Re-run Alexa device discovery
• Confirm the routine triggers on Open (not Close)
• Increase Reset after (seconds) slightly (example: 7–10)
• For groups, increase Delay between trigger devices (ms) to 300–800

Triggers fire inconsistently in a group

• Increase Delay between trigger devices (ms)
• Avoid extremely low delays unless your environment is proven stable

Double-fires

• Increase Ignore repeated triggers from Hubitat within (ms) (example: 250–750)

Security and privacy notes

• This project creates local virtual devices and uses Hubitat’s Amazon Echo Skill to share them with Alexa.
• Alexa routine execution occurs in Amazon’s ecosystem (as expected for Alexa routines).
• No additional cloud services are required by this project.

Support

If you need help, use the Support page on this site and include:

Relevant logs or screenshots (redact any sensitive details)teps to reproduce, and any relevant logs (redacting keys/tokens).

• Project name and version
• Hubitat model/firmware
• What you expected vs what happened
• Steps to reproduce

Control your Meross device locally

This Hubitat custom driver provides local LAN control for compatible Meross “mini plug” devices that support the classic Meross local API. The goal is simple: reliable on/off control without depending on cloud availability or introducing unnecessary latency.

Why this exists

Many Meross devices can be controlled locally on your network, but compatibility varies by model and firmware. This driver is designed to support common local control patterns (including both Toggle and ToggleX variants) and to behave like a standard Hubitat Switch so you can use it anywhere in Hubitat automations.

Devices

This has been tested on the following devices:
Model: MSS110
Firmware: 1.1.28 through 6.2.5
Hardware: 1.0.1 through 6.0.0

Key features

• Local on/off control and refresh (no cloud dependency)
• Supports common Meross local control variants (Toggle and ToggleX)
• Toggle-only option for older plugs like MSS110
• Channel support for devices that require it
• More resilient response parsing across typical Meross payload formats
• Automatically sets Hubitat LAN addressing (deviceNetworkId) based on the IP you provide for more reliable LAN routing
• Logging options for troubleshooting (Off, Basic, Debug)
• Built-in diagnostics fields: connectionStatus, lastRefresh, lastRefreshResult, lastError
• Quick validation via Run Test (records last test time and result)

Requirements

• Hubitat Elevation hub on the same LAN as the plug
• A stable IP address for the plug (DHCP reservation strongly recommended)
• Your Meross local key (treat this like a password)
• A Meross device and firmware that still supports local LAN control

Meross local key note

The Meross app does not display the local key. You must retrieve it using a third-party method. The project documentation includes a step-by-step guide for the Chrome DevTools login.js method.

Important note on compatibility

Not every Meross plug exposes local endpoints, and some firmware updates may reduce or remove local functionality. If your device does not respond to local control, the driver cannot force it. This project is best suited for users who want local-first automations and are comfortable reserving device IPs and providing the Meross local key.

Installation and configuration

Installation (Hubitat)

1. In Hubitat, go to Drivers Code and create a new driver.
2. Paste the driver code and save.
3. Create a new device and assign this driver as the device type.
4. Open the device page and set preferences (IP address, key, and channel if needed).
5. Save preferences, then click Refresh to pull the current state, then test On/Off.
6. Optional: run Run Test to validate connectivity and key configuration.

Configuration tips
Device IP Address
Reserve the plug’s IP in your router so it never changes. If the IP changes, local control will break until updated.

Key
Paste your Meross local key. Do not share it in screenshots or logs.

Device channel
Most single-outlet mini plugs use channel 0. If your device has multiple controllable outlets, a different channel may be required.

Toggle vs ToggleX
Some older devices respond better to the original Toggle method. If commands fail, switch between Toggle-only and ToggleX (and confirm the channel).

Using the driver in automations
Once configured, the device behaves like a normal Hubitat switch. Use it in Rule Machine, WebCoRE, dashboards, and integrations exposed through Hubitat (including voice assistants).

Troubleshooting
If On/Off does not work

• Confirm the IP is correct and reachable from the hub
• Confirm the plug has a DHCP reservation
• Verify the key is correct
• Try switching between Toggle-only and ToggleX
• Confirm channel is set correctly (often 0)
• Check the device’s diagnostics fields: connectionStatus, lastRefreshResult, lastError
• Set Logging to Debug, reproduce the issue, review Hubitat Logs, then return Logging to Off or Basic

If state does not update reliably

• Click Refresh and confirm lastRefreshResult shows Success
• Check connectionStatus and lastError for actionable details
• If needed, set Logging to Debug, reproduce the issue, then review Hubitat Logs (redact sensitive details)

Support

If you need help, use the Support page on this site and include: project name, version, Hubitat firmware, plug model (if known), steps to reproduce, and relevant logs (redacting keys/tokens).

Turn calendar activity into a Hubitat virtual switch

If you use Hubitat and keep your life in a calendar, you’ve probably wanted a simple way to translate “I’m busy” into automation logic. Hubitat iCal Switch does exactly that.

This driver monitors an iCal/ICS feed and maps eligible calendar activity to a virtual switch. When an event is active (based on your rules), the switch turns on. When you’re free again, it turns off. From there, you can use the switch in Rule Machine, Mode Manager, notifications, dashboards, and more.

Note: if you need to log in to your Outlook or Google calendar, check out the OAuth version.

What it does

• Monitors an iCal/ICS calendar feed and tracks upcoming and active events
• Turns a virtual switch on or off based on eligible calendar activity
• Filters events using keyword include or exclude rules
• Supports event eligibility controls (busy-only, tentative, declined, all-day)
• Uses the hub’s timezone for display and scheduling
• Handles Outlook / Microsoft 365 timezone metadata (X-WR-TIMEZONE and VTIMEZONE)
• Expands common weekly RRULE patterns and applies RECURRENCE-ID overrides
• Uses transition-based polling at event boundaries plus a regular polling cadence for resilience

Why this is useful

• Quiet hours when a “Meeting” event is active
• Auto-silence announcements, chimes, or TTS during appointments
• Pause robot vacuums or reduce HVAC setbacks while you’re on a call
• Trigger “work mode” only when your calendar shows you’re busy
• Drive status indicators on dashboards (Busy / Free)

How it works (high level)

1. Provide an iCal/ICS feed URL
2. The driver periodically checks for calendar updates
3. Events are evaluated against your eligibility and keyword rules
4. The driver determines whether an eligible event is currently active
5. The virtual switch is updated accordingly

Getting started

Prerequisites

• A Hubitat Elevation hub
• An iCal/ICS feed URL from your calendar provider

Install and configure

1. Add the driver code to Hubitat (Drivers Code)
2. Create a new Virtual Device using the Hubitat iCal Switch driver
3. Paste your ICS URL into the device preferences
4. Configure eligibility settings and keyword filters
5. Save preferences, then verify switch behavior as events start and end

Support

If you need help, use the Support page on this site and include:

Relevant logs or screenshots (redact any sensitive details)teps to reproduce, and any relevant logs (redacting keys/tokens).

• Project name and version
• Hubitat model/firmware
• What you expected vs what happened
• Steps to reproduce