So I’ve managed to add an Area Target of my house as a target on my edge server, and it works superbly well !
I then added the Hue interface, and my lights popped up as blank objects (after quite a while) on my server. First observation:
The settings in the Hardware Interfaces lists 30 lights, from Light1 to Light30. My objects are named From Light3 to Light47, with some number missing in-between. Is this expected ? Is it possible to get the names of the lights declared in the Hue app for easier identification ?
Second and probably more important observation for me:
They are objects, not tools : they hence require a target to be added. What if I want them to be attached to my Area Target ? I assume I could add my AT dataset as the target, but the name change for each light, making this very inefficient as I would need to recreate the AT for each target name on each light. Am I missing something here ? Is there a way to make the lights as tools instead of objects, that I could somehow place wherever I want in my AT target ?
I’m aware that AT support is super fresh and probably far from final. Happy to help on this front.
It feels like your testing the edges of the system Big space and tons of lights.
We were not thinking of pushing this basic interface to such an extreme, but I love it! We should find an away to develop the right UX. What you describe should be possible; we don’t have the infrastructure to experiment and develop the right look and feel for that scale. Do you want to help us designing/coding the right experience into this basic add-on?
The lights need to be objects, since you want to attach tools around them. Tools are only the digital / physical interface representation for an object.
However what you want to do is to define your home as a World Object and then make all your objects relative to this world.
Here is how:
Once you track a world object (your home) all normal objects will report their position relative to the last world object your phone registered.
At this moment in time you would need to have a target present at the location of your object to define this relationship for the first time. However, any time after if your target is not visible, the object should still track since its last position was recorded relative to the world object. The target however still needs to load into the editor. Its kind of pointing in the right direction, but I see what needs to happen.
What we should implement:
A method to define an object only as an anchor relative to the world object so that you do not need a target, only the world object (tracked via the area target).
Let me think for a moment how we can best implement that. Cause you also need to have some easy means to define and distribute these anchors in your home.
Yeah, I assumed that I was probably pushing a little too hard for a first discovery session !
Happy to help your team with this if you have the bandwidth to improve this “basic interface” addon, with testing/feedback and whatever you need. With the lockdown, pretty sure that’s where many people will start experimenting with !
Gotcha! I was wondering what were the differences between Object and World Object. I’ll experiment with that and image targets to place my lights then
That would be ideal. Again, happy to test and give feedback on any test implementation!
Thanks for having so many lights! I didn’t think the philips hue light id space could become discontinuous like that. I’ve made a PR fixing the display of ids on the configure interface. There are light names in the Hue API if I remember correctly but I’m not sure if there’s a good way to expose them to the user.
Once you start the Hue path, it’s hard to stop adding more!
Ideally, you would be able to grab the custom name you can specify for your light on the Hue app, like “Desk Left” or “Living Room Bloom”, etc. This way, it’s really easy to identify the light you need. Because currently, the light number do not correlate to anything in the Hue App. And I didn’t find an access to the mapping of the light number and the custom names I specified on my bulbs!
Thanks for testing out the Area Targets! I’ve got an Area Target of my apartment working, but so far that was the only one we had tested with (we only first started supporting them 2 weeks ago) - so it’s awesome to hear that they are working for you!
I’ll write a new article for the website soon that fully explains the difference between Objects and World Objects. If you run into anything else that isn’t fully explained, let me know and I’ll write up the documentation.
So if anybody currently experimenting encounters a similar issue with a significant amount of lights and is wondering to what each “LightX” corresponds to in their system, here is a trick to find out:
Go to https://<your bridge ip>/debug/clip.html
Press the Bridge button.
in “URL”, enter /api. In Body, enter {"devicetype":"my_hue_app#iphone peter"}. Hit POST.
You get a string that is your username.
in URL, enter: https://<bridge ip address>/api/<username>/lights and hit GET.
You get a JSON file where all lights are numbered (maybe discontinuously) and for each, there is “name” field that gives you the corresponding name in your Hue app.
Here is the server side corresponding work-stream:
We found a nice solution for the Spatial Toolbox UI, but it will take a couple of days to get it all implemented. However the result should allow you to comfortably place your hue lights relative to the world (for example the Area Target of your home).
Another remark : in the index.js, you check if there is a light.colorful value to enable the hue/sat nodes. But it seems that it doesn’t exist in the Hue API, even on colorful lights. I think it should be colormode instead, as it only appear if available, and check if it is set to HS. There are other mode tho (to control the color temperature on “white only” bulbs), so it may need to be explored a bit more to fully support the Hue capabilities range.
Yes, proper support for color/color temperature bulbs is something I need to add since the old implementation had the user configure it manually per bulb
If there is a World Object, new Objects automatically anchor to the World Object. You can see this with a little anchor Icon in the server.
The anchor default position is the world origin. Tap on an anchor and it snaps full screen. Your phone becomes the anchor token, so that you can easily walk around and place the anchor in your space. Tap again and the anchor is placed.
@valentin So, I managed to test the spatial anchors branch with the Testflight app:
It works perfectly on the technical level : ability to anchor object in the World and relocation of the Area Target
Using the phone as the anchor token is great and natural. Wish we could turn on an option to do that for tools as well
Positioning the Objects anchors at 0;0;0 is not a bad idea but for the Hue interface, it’s not the best : I got 30+ Objects anchors all placed at the same spot at once, and my 0;0;0 was far away from me, so really hard to see at first on the screen. A menu providing a list of the available anchored Objects that you can click and place, like done for tools, would be great.
Adding tools in space did not automatically attach to my World object : they were attached to (seemingly) random Objects anchors around me: placing labels for room, they got attached to Objects, not the World Object.
All my Objects generated by my link with the Hue Bridge got duplicated : all lights anchors were in more than one example (Light 35 was twice there, etc)
Overall, this is a huge step forward and it makes it viable as a large scale controller. I love it.
This shouldn’t be hard to do. We already have a list in the setup menu called found objects. We can make this list interactive, so that the anchors snap right away to your screen.
This is currently worked on. And should function better soon.
Would you be able to help us fixing it? The Hue light interface is a simple interface and could be a great entry to contribute code. I assume something in the interface generates the lights two times.
Yes, we can look into doing this for tools. It shouldn’t be much work to transfer the implementation from anchors to tools. We have a “repositioning mode” in the app (currently hidden – you can access by tapping and holding on the settings icon). Perhaps in this mode we can allow tools to be repositioned using the phone as a token.
I’m almost done fixing this part – I’ll post an update when it’s ready.
That’s a good idea. We can easily add a button to anchors in this list that makes them snap to the screen and hides the settings menu.
Big space and tons of lights.
