Big re-write of the library to support the subscription api (basically the what the previous version used but new version from Vestaboard), the R/W api that is connected to the vestaboard cloud service, but allows for reading and writing specifically to the board, and the local API which (with proper enablement) allows you to read and write directly to a local board directly without the cloud/internet hosted services.
Basic Node API wrapper for the Vestaboard api
This is definitely hobby code at the moment, so no guarantees of anything,
contributions welcome.
Major Version Change -> 2.0
This version has breaking changes largely driven by enhancements to the
Vestaboard API offerings since 1.0 was created.
When 1.0 was built the Vestaboard only had a single available interface through
a now deprecated set of APIs. Now there are three ways to communicate with a
vestaboard:
The Subscription API is the closest in concept to the original API, it's
designed for writing to one or more boards based on a subscriptionID. It's
probably what you want if you are making an installable or other extension
that writes to multiple boards.
The Read-write API is similarly cloud based, and has similar functionality
to the subscriptionAPI, but only communicates with a single board. You need to
enable access via the Vestaboard web app, and then get the read write key. You
can now read the current message from the board, in exchange you lose the
ability to access multiple boards.
The Local API is similar to the read-write API, with a couple of exceptions.
It must be enabled via Vestaboard and they will provide you with a token, then
you call the enablement API with the provided token to get a local key. That
local key allows you to read and write directly to the local board, which
doesn't use the vestaboard services.
Feature set
Maps closely to the published Vestaboard API methods as described in the
docs
Given the three distinct models, and their idiosyncrasies, I built the three
interfaces on their own.
Each one requires different configuration settings (see types.ts). You can also
use the tiny helper creation function like:
const subscriptionConfig: SubscriptionAPIConfig = {
mode: VestaboardControlMode.Subscription,
apiKey: process.env.SUBSCRIPTION_API_KEY as string,
apiSecret: process.env.SUBSCRIPTION_API_SECRET as string,
};
let vesta = createVestaboard(subscriptionConfig) as VestaSubscription;
or just go directly
import { VestaRW } from 'vestaboard-api'
const vesta = new VestaRW({ apiReadWriteKey: 'Your_RW_API_KEY' });
Everything now throws errors of various levels of descriptiveness. Mostly the
post requests, so use appropriately.
New utility function isValidBoard is also exposed, it just checks that the
character array is valid. Local board api calls only accepts character arrays,
not the auto-layout text versions. There is a new(ish) package from Vestaboard
that can help build these if you like:
VBML
Migration
The migration from v1 api to -> subscription api is minor.
You could go from something like:
The only other change I noticed was that the subscription response on the
v1 API had a property of _id vs. the new structure of id so that needed to
change. Otherwise I didn't see anything that would really mess you up.
The R/W api and the local api are all new to the package so not so much of a
migration, but if you are converting to the r/w
Oh, and I changed the character codes to match the latest Vestaboard system with
support for filled etc. for white/black colorways.
Also killed the unescaped return character, and added a replacement for \n
that has the same behavior as *return.
A note on rate limiting
I believe the boards ignore subsequent messages within 15 seconds, and the APIs
definitely kick a 503 at about 15 seconds for rate limiting. It's a hardware
device after all.
Big re-write of the library to support the subscription api (basically the what the previous version used but new version from Vestaboard), the R/W api that is connected to the vestaboard cloud service, but allows for reading and writing specifically to the board, and the local API which (with proper enablement) allows you to read and write directly to a local board directly without the cloud/internet hosted services.
Basic Node API wrapper for the Vestaboard api
This is definitely hobby code at the moment, so no guarantees of anything, contributions welcome.
Major Version Change -> 2.0
This version has breaking changes largely driven by enhancements to the Vestaboard API offerings since 1.0 was created.
When 1.0 was built the Vestaboard only had a single available interface through a now deprecated set of APIs. Now there are three ways to communicate with a vestaboard:
Subscription API
is the closest in concept to the original API, it's designed for writing to one or more boards based on asubscriptionID
. It's probably what you want if you are making an installable or other extension that writes to multiple boards.Read-write API
is similarly cloud based, and has similar functionality to the subscriptionAPI, but only communicates with a single board. You need to enable access via the Vestaboard web app, and then get the read write key. You can now read the current message from the board, in exchange you lose the ability to access multiple boards.Local API
is similar to the read-write API, with a couple of exceptions. It must be enabled via Vestaboard and they will provide you with a token, then you call the enablement API with the provided token to get a local key. That local key allows you to read and write directly to the local board, which doesn't use the vestaboard services.Feature set
Maps closely to the published Vestaboard API methods as described in the docs
Given the three distinct models, and their idiosyncrasies, I built the three interfaces on their own.
Each one requires different configuration settings (see types.ts). You can also use the tiny helper creation function like:
or just go directly
Everything now throws errors of various levels of descriptiveness. Mostly the post requests, so use appropriately.
New utility function isValidBoard is also exposed, it just checks that the character array is valid. Local board api calls only accepts character arrays, not the auto-layout text versions. There is a new(ish) package from Vestaboard that can help build these if you like: VBML
Migration
The migration from v1 api to -> subscription api is minor. You could go from something like:
to something like:
The only other change I noticed was that the subscription response on the v1 API had a property of
_id
vs. the new structure ofid
so that needed to change. Otherwise I didn't see anything that would really mess you up.The R/W api and the local api are all new to the package so not so much of a migration, but if you are converting to the r/w
Oh, and I changed the character codes to match the latest Vestaboard system with support for
filled
etc. for white/black colorways.Also killed the unescaped
return
character, and added a replacement for\n
that has the same behavior as*return
.A note on rate limiting
I believe the boards ignore subsequent messages within 15 seconds, and the APIs definitely kick a 503 at about 15 seconds for rate limiting. It's a hardware device after all.