Closed KnisterPeter closed 4 years ago
Sure I am open to PRs.
I would not want to expose all the model objects at this time, as they are meant for internal use and once they are exposed, it will lock them in the API, making the more difficult for me to change in the future. Also these are sometimes changed in the underlying Hue API on version changes, which these once exposed will not be a blessing to easily handle in their current form.
I understand your use case, so can make some of these objects available if that would be useful to to if you. Could you indicate which ones you would be interested in (e.g. Lights and Scenes, etc...), then I can review the underlying objects and plan a change to support what you need.
Thanks.
Hmm, only a few will not help, but maybe we could create some sort of 'proxy' integration or a plugin or something like this. That would keep the API internal for management but allows so get in between the handling. I know its not that good to give access to internal apis to someone else.
I will think about possible solutions of this and comment them here, okay?
I have been working on standardizing the model objects to accommodate changes to the underlying API that Signify do from time to time, whilst still providing these class based objects.
I am now at the point of trying to expose these in the library, but need some more information on how you would intend to use these in practice, so I can cover your use case.
In your proxy, would you be happy to get a payload JSON object from the model object, say a Group
for instance and then in the client have a function in that will take the JSON payload and return you a Group
instance populated using that data?
For example the proxy would generate a JSON payload like:
{
"_node_hue_api_type": "Group",
"id": 1,
"name": "VRC 1",
"lights": [
2,
3,
4,
5,
6,
7,
8
],
"sensors": [],
"type": "LightGroup",
"state": {
"all_on": false,
"any_on": false
},
"recycle": false,
"action": {
"on": false,
"bri": 61,
"hue": 14988,
"sat": 141,
"effect": "none",
"xy": [
0.4575,
0.4101
],
"ct": 366,
"alert": "select",
"colormode": "ct"
}
}
Then on the client side you could would have pseudo code like:
const bridgeModel = require('node-hue-api').model;
const data = {}; // Your JSON data payload from above
const group = model.create(data);
// The above group would be the model Group object
That would exacly meet my usecase. I've working around this right now (as you can see here https://github.com/KnisterPeter/hueup). Creating the model from a json strucuture would be very nice.
This is now done in alpha version 4.0.0-alpha-3
in the npm registry.
All Bridge objects, Lights
, Scenes
, Groups
, etc... all have the ability to be serialized into a JSON payload using the getJsonPayload()
function, and can be reconstructed using the v3.model.createFromJson(data)
function.
I have spent a fair bit of time building up tests to cover all the objects and they are now all passing, so it should provide you with what you need.
Awesome. Thank you
Released in 4.0.0
It would be great if you could expose (or export) the
bridge-model
types from the api. I'm in need to create a proxy between the remote api and my application, because phillips does not set correct CORS headers. When executing thenode-hue-api
on my proxy and return the result I'm ending up with the raw data objects. It would be awesome to construct the bridge models from the raw data again in my client.And just to ask: Are you open to pull requests?