seam logo

Changelog

New updates and improvements to Seam.

New Javascript SDK

New JavaScript SDK

This week, we’re excited to announce the official release of our new JavaScript SDK!

The new SDK has a smaller bundle size and fewer dependencies, and it is generated automatically on a daily basis to ensure that methods and types are always up-to-date with the latest API changes. Written entirely in TypeScript, this SDK works both on the server and in the browser, powering the Seam Console, Seam Components, Seam CLI, and more.

Our plan is to move all of our SDKs to this new auto-generated approach. We want to make sure that using any of our variety of Seam SDKs is always the best developer experience for integrating with Seam.

We encourage you to install the new Seam JavaScript SDK right away, using the following command:

1npm i seam

If you’re running the original Seam JavaScript SDK (that is, the seamapi package instead of the new seam package), see our migration guide. seam is mostly a drop-in replacement for seamapi, but some method signatures and options have changed to improve overall consistency with the Seam API.

2024.09.06 Change Log

New

  • Preferred access code length: We’ve added a preferred_code_length parameter to the access code create function. When creating an access code, if you do not specify a code (for example, “1234”), you can now set the preferred_code_length. Seam then generates a code of this length if the affected device supports the specified preferred code length.
  • August-Yale name change events: We’ve added support for immediately detecting name changes for August-Yale devices and updating our data. Previously, it could take a while for these changes to be reflected in Seam. Note that this addition is only for August-Yale devices in North America.

Changed

  • August-Yale online status: We’ve improved the detection of online/offline status for August-Yale devices. You should now see much more accurate reports.

Fixes

  • SmartThings events: Previously, our backend would occasionally throw an error on incoming SmartThings events, causing some events to be dropped. We have fixed this issue. Thanks to the couple of folks who reported this issue!
  • Igloohome access codes: Our Igloohome integration was incorrectly accepting PIN codes longer than six digits for online access codes on create. We’ve fixed this behavior to allow codes only between four and six digits in length. Note that offline access codes can still contain up to nine digits.
  • Console: Provider logos weren’t correctly showing up in the connected account view. We’ve corrected this view.
  • Seam Component edit access code function: We fixed a bug that would prevent users from editing time_bound ****access codes in our access code Seam Component.

Yale-August Real-Time Events

This week, we’re excited to announce that we’ve released real-time events for Yale and August devices within the North American region. That is, if you control your devices using the Yale Access app, you should now notice a massive improvement in how quickly you receive events relating to your device unlocking or changing online status. For devices outside of North America, we are working with Yale’s APAC and EMEIA teams to bring this enhancement later on.

From polling to real-time

The August-Yale integration is one of our oldest and has relied from the start on plain old polling to update device status and events. That meant that when a lock operation (such as an unlock) took place, it would take a few minutes for the event to be emitted from the Seam API to your server. Furthermore, as the number of Yale devices connected via Seam grew larger, we further decreased polling frequency to avoid flooding Yale’s server (fun fact: Seam’s Yale largest connected partner!).

Last spring, our friends at Yale informed us that real-time events would become available for Seam to consume and relay. We were thrilled and jumped at the opportunity to implement this enhancement for our customers. Not only does it improve the overall Yale-Seam integration experience, but it also ensures that our Yale friends can sleep soundly at night.

Rollout and available events

we began rolling out real-time events in late June. Given the importance of reliable events, we only slow rolled this out to more customers in July. As of August, we’re making this enhancement broadly available to all our customers, at no extra charge.

The following events are currently available:

  • lock.locked
  • lock.unlocked
  • device.connected
  • device.disconnected

We are also working on adding additional events for access code creation operations and device metadata updates, such as a user changing a device name.

What about Yale devices out of North America

As some Yale owners may recall, in May of 2023, Assa Abloy sold its Yale North American assets to Fortune Brands. As a result of this transaction, all Yale users outside of North America were migrated to a new backend accessible via the Yale Home app. For all intents and purposes, this is effectively a completely different integration. We are currently working with the Yale Home team to add support for real-time events and will release this at a later time.

Change Log

New

  • August-Yale real-time events: All August and Yale devices in North America now support real-time events for unlocking operations.
  • Connect Webview events: We’ve added two new events—connect_webview.login_succeeded and connect_webview.login_failed—to notify you whenever a Connect Webview completes. This will also create a more consistent developer experience with the events you receive from the iFrame-embedded Connect Webview.
  • Connect Webview styling: When you set a primary color, we now automatically adjust the text color to maximize contrast-ratio. Thanks to our friends at Lodgify for spotting this for us!
  • Lockly offline codes: You can now program offline access codes on all Lockly devices, and we also added the can_program_offline_access_codes capability flag. If you are not familiar with offline access codes, check out our Managing Offline Access Codes documentation.
  • Event descriptions: We’ve added an event_description to the payload for all events. It’s a human-readable string that tells you what the event is about and saves you a trip to our docs.
  • Access denied event: We’ve added a new lock.access_denied event to indicate when an incorrect access code is entered multiple times in a row on a smartlock device. This is only available on Kwikset devices at the moment.
  • Automatic relock event: We’ve added a new automatic value for lock_method events, which means that we now make it clearer when a lock automatically relocks after an unlocking operation.
  • Unmanaged device location: We now expose the location field for unmanaged devices. This enhancement can make it easier to identify where a device is located and whether it should be converted to managed.

Changed

  • Deprecate Get Locks: We’ve deprecated the /locks/get endpoint. If your code uses it, you will begin to see a warning.
  • Kwikset duplicate code name error: We’ve improved the error message to indicate clearly that Kwikset requires the first 14 characters of a Kwikset device access code name to be unique across the device.

Fixed

  • Schlage silent failing code: We’ve received a handful of reports that access codes on Schlage devices would occasionally report as set, despite not actually being set on the device. After weeks of investigation, we’ve identified the issue as a false positive status reported by the Schlage API. The good news is that we know how to identify this and have since implemented a fix that automatically recreates the code. We’ve seen a vast reduction in Schlage related access codes errors.
  • Kwikset Seam API unlock: Previously, lock.unlocked events on Kwikset devices didn’t reliably add the seamapi unlocking method to the event payload. We’ve improved the logic to make this detection more reliable.
  • Igloohome: We’ve fixed an issue related to the handling of invalid auth tokens whereas the renewal process wasn’t always correctly initiated.
  • Lockly: We now surface a clearer error message whenever a Lockly account’s API key does not have sufficient permissions.
  • Honeywell Resideo: We added a unique account id constraints on a given workspace because creating the same account twice lead to errors later on.
  • Nuki: We’ve improved the Nuki offline status detection because it was previously reporting devices as online when they were not.

New Capability Flags

This week, we’re thrilled to announce the release of our new device capability flags. Compared to the legacy capabilities_supported, these new flags provide far more granularity on what a specific device can do. They’re also computed in real time for each device to ensure timely knowledge of a given device instance’s functions. For example, these flags correctly detect the presence or lack of an accessory that is required for a specific function, such as an accessory keypad for programming online access codes.

Capability example

First four flags

For this feature launch, we are releasing the first four capability flags across all providers and existing devices that we support.

  • can_remotely_unlock: Indicates whether the device can perform a remote unlock operation.
  • can_remotely_lock: Indicates whether the device can perform a remote lock operation.
  • can_program_online_access_codes: Indicates whether the device can program online access codes. If true, it is currently possible to create new online access codes for the device, and Seam programs the device the next time it's online.
  • can_program_offline_access_codes: Indicates whether the device can program offline access codes. When this flag is true, Seam can generate an offline code for this device, regardless of the current online status of the device.

Example

1# Get the device.
2device = seam.devices.get(
3  device_id="11111111-1111-1111-1111-444444444444"
4)
5
6# Confirm that the device can remotely lock.
7if device.can_remotely_lock:
8  # Perform the lock operation.
9  seam.locks.lock_door(device_id=device.device_id)

Getting Started

We recommend that you begin migrating to these new flags because they will ensure that your applications correctly reflect the state and functions of a device.

To get started:

New Honeywell Thermostat Integration

This week, we are super excited to release our official Honeywell Thermostat integration! Along with Ecobee and Nest thermostats, you can now connect and control all Honeywell Resideo thermostats and control them through our SDKs, Seam-CLI, and the Seam Console.

Our office has a number of Honeywell thermostats. With the winter weather overtaking typically sunny California, we can confirm that the Seam CLI has been handy to crank up the heat on the Honeywell thermostats without having to get up and walk over to the actual thermostat…

Some resources to get you started with this integration:

As always, this integration will be in beta for the next couple of weeks; though we’ve thoroughly tested this integration, if you see any inconsistencies or bug, please let us know and we’ll patch issues right away.

Changelog

Added

  • Tedee: we added the ability to update an access code set on a Tedee device.
  • Seam Bridge: you can now setup Seam Bridge for on-prem systems through the Seam Connect Webview. If you need to connect on-prem devices or systems, contact us and we’ll fill you in on this Seam Bridge.
  • Seam Console & Account Disconnection: we added a button to let you quickly reconnect a third-party account; we also renamed the disconnect button to “delete” to avoid confusion with disconnection events tied to auth tokens expiring.

Fixed

  • Seam Components: we shipped a couple of visual tweaks to remove unnecessary borders and make components look generally better :)