Releases: peter-murray/node-hue-api
v4.0.8
4.0.1
4.0.0
-
Deprecated v2 API and shim and modules removed from library
-
Introduced rate limiting in the Light and Group set States to be compliant with the Hue API documentation best practices.
This only has an impact on this library, so it may be possible if you are running other software on your network
accessing the Bridge, you will still able to overload it.- The whole API is currently limited to 12 requests per second by default (currently not configurable)
lights.setLightState()
is limited to 10 requests per secondgroups.setState()
is limited to 1 request per second
-
v3.discovery.nupnp()
Now returns a different payload as it no longer accesses the XML Discovery endpoint to return
the bridge data as this can become unreliable when the bridge is overloaded. See the documentation
for specifics. -
v3.api
removed thecreate
function as it was deprecated, usecreateRemote()
fro the remote API,createLocal()
for the local API orcreateInsecureLocal()
for non-hue bridges that do not support https connections -
v3.Scene
has been removed, use the following functions to create a new Scene instance:v3.model.createLightScene()
v3.model.createGroupScene()
This change has also allowed for the separation of the attributes and getter/setters locked down properly based on
the type of Scene, i.e. Cannot change the lights in a GroupScene (as they are controlled by the Group). -
v3.sensors
has been removed, usev3.model.createCLIPxxx()
functions instead -
v3.rules
has been moved intov3.model
- To create a
Rule
usev3.model.createRule()
- To create a
RuleCondition
usev3.model.ruleConditions.[group|sensor]
- To create a
RuleAction
usev3.model.ruleActions.[light|group|sensor|scene]
- To create a
-
v3.model
added to support exposing the underlying model objects that represent bridge objects. This module will allow
you to create all of the necessary objects, e.g.createGroupScene()
-
Capabilities API:
capabilities.getAll()
now returns aCapabilities
object
-
Groups API:
- The following API functions will accept a Light Object as the
id
parameter as well as an integer value:groups.get(id)
groups.getGroup(id)
deleteGroup(id)
enableStreaming(id)
disableStreaming(id)
groups.createGroup(group)
introduced, it expects a pre-configured Group instance created using the model functions:model.createLightGroup()
model.createEntertainment()
model.createRoom()
model.createZone()
groups.get(id)
has been deprecated, usegroups.getGroup(id)
instead.groups.createGroup(name, lights)
has been deprecated, usegroups.createGroup(group)
instead.groups.createRoom(name, lights, roomClass)
has been deprecated, usegroups.createGroup(group)
instead.groups.createZone(name, lights, roomClass)
has been deprecated, usegroups.createGroup(group)
instead.groups.updateAttributes(id, data)
has been deprecated, Usegroups.updateGroupAttributes(group)
instead.
- The following API functions will accept a Light Object as the
-
Lights API:
getLightById(id)
is deprecated usegetLight(id)
insteadrename(id, name)
is deprecated, userenameLight(light)
instead- The following API functions will accept a Light Object as the
id
parameter as well as an integer value:getLight(id)
getLightById(id)
getLightAttributesAndState(id)
getLightState(id)
setLightState(id, state)
deleteLight(id)
-
Scenes API:
getScene(id)
introduced, can take a scene id orScene
instance as the id valueget(id)
has been deprecated, usegetScene(id)
insteadgetByName(name)
has been depricated usegetSceneByName(name)
insteadupdateScene(scene)
introduced to replaceupdate(id, scene)
for updating Scenesupdate(id, scene)
has been deprecated, will be removed in5.x
, useupdateScene(scene)
insteaddeleteScene(id)
can accept a scene id or aScene
object as theid
parameteractivateScene(id)
can accept a scene id value or aScene
objectupdateLightState(id, lightId, sceneLightState)
can take an id value orScene
/Light
for theid
andlightId
values respectively
-
Sensors API:
get(id)
has been depreciated usegetSensor(id)
insteadgetSensor(id)
will accept aSensor
Object as theid
or the integerid
value as parameter.updateName(id, name)
has been deprecated, will be removed in5.x
, usereanmeSensor(sensor)
insteadrenameSensor(sensor)
has been added to allow updating of the name only for a sensor (makes API consistent withlights
andsensors
)getSensorByName(name)
added to get sensors byname
-
Rules API:
- The following API functions will accept a Rule Object as the
id
parameter as well as an integer value:get(id)
deleteRule(id)
- Added
getRuleByName(name)
function to get rules byname
- Rule Actions were common to the new
Schedules
, so have been moved fromv3.model.ruleActions
tov3.model.actions
.
Use ofv3.model.ruleActions
is considered deprecated.
- The following API functions will accept a Rule Object as the
-
Schedules API:
-
The schedules API is finally properly implemented, along with all the various Hue Bridge TimePatterns
model.timePatterns
provides an interface with creating the various timePatterns, consult the documentation for details
-
The previous
schedules.update(id, schedule)
function has been removed and replaced withschedules.update(schedule)
.I am fairly sure that the previous version was most likely never used (base on the implmenetation as it would
have likely errored). With this knowledge, it was not deprecated and just removed. If you are impacted by this change, please raise an Issue.
-
-
ResourceLinks API:
- New API interacting with
ResourceLinks
via,api.resourceLinks
, see documentation for more details.
- New API interacting with
-
Configuration API:
get()
has been deprecated, usegetConfiguration()
insteadupdate()
has bee depricated, useupdateConfiguration()
instead
-
All creation function calls to the bridge will now return the created model object. This change makes it consistent as
some calls would return the object, others would return the id but no other data.This changes return object from the promise on the following calls:
api.rules.createRule()
api.scenes.createScene()
api.sensors.createSensor()
-
Type system from the
LightState
definitions is now used in all Bridge Object Models to define the attributes/properties
obtained from the Bridge.This provides a consistent validation mechanism to all bridge related attributes data. As part of this being used in
the models, some validation is performed at the time of setting a value instead of waiting on when sending it to the
hue bridge (some things still have to wait be sent to the bridge) so the validation is closer to the point of call. -
Added ability to serialize a model object into JSON and then restore it to a corresponding object from the JSON
payload. This was requested to aid in server/client side code situations, as the creation of the model objects are
not directly exposed in the library by design. Related to issue #132 -
Creating Sensors (CLIP variety) has changed as the classes for the sensor objects are no longer directly accessible.
AllCLIPxxx
sensors need to be built from thev3.model.createCLIP[xxx]Sensor()
function for the desired type,
e.g.v3.model.createCLIPGenericStatusSensor()
for aCLIPGenericStatus
sensor.The function call to instantiate the sensors also no longer take an object to set various attributes of the sensor,
you need to call the approriate setter on the class now to set the attribute, e.g.sensor.manufacturername = 'node-hue-api-sensor';
-
TypeScript definitions added to the library
-
Adding more in-depth tests to further increase coverage around types and models, and adding more edge case API level tests
v2.4.5
v2.3.0
1.2.0
1.1.2
1.0.5
1.0.4
- Fixes issue with scene ids created being NaN values