And yes, the component losing connection is expected behaviour as the joined space api stops responding after a while. I’m not sure if there’s a way around it as I haven’t tested if the official Philips remote app behaves the same. You could have a Wake on LAN switch to turn the TV on when the light component is unavailable, or alternatively, do the same with an IR blaster
The issue that I’ve described with turning on the ambilight via front-end is taking place after the TV is on enough time to restore the connection, i.e. 15-20 minutes. If the turn on called as service, there is no such lag and it turns on after a few seconds.
Huh, where are you seeing that? The page I linked states
Since 0.92.0, every integration has a manifest file to specify basic information about an integration. This file is stored as manifest.json in your integration directory. It is required to add such a file, including for custom components.
Ah, I understand what you mean now. I’ve observed the same behaviour, I always wrote it off as JointSpace closing the connection, but if it is, as you say, working perfectly fine when calling the service then it has to be something else. Maybe raise an issue on github?
It is inconsistent in the documentation which is not a surprise, but it do works without manifest.json for other customer components too, including this one.
I would gladly raise it as the issue on github because it looks like it is some specific to front-end, however, it is a customer component, so who is the owner, where to raise it as an issue?
I have a recent Philips TV with ambilight and jointspace v6, but not android TV.
As you suggest in the readme about older models I had to tweak the code a bit (i.e. plain http, different port, no authentication), but I got it to work - to an extent.
I hope to find the time to make a PR to avoid having to change the code (supporting non android TV models via config).
It’s a shame how limited jointspace is on these models (seriously, I cannot launch apps, I cannot switch to a specific HDMI input…It can crash sometimes requiring a power cycle of the tv…horrible), but at least the ambilight part is largely compatible.
One problem I noticed is that changing the brightness with the slider resets the color to white, and setting a manual color bumps the brightness to maximum. I have not investigated now if it’s something specific to my TV or something that can be addressed in code (I’ll have to try playing with the API directly).
Hi, glad to hear you got it working!
Unfortunately, the brightness issue is a problem for everyone, as far as I can tell, at least from the API standpoint, there is no “brightness” level when the Ambilights are in Follow Video (or Follow Colour) modes, as the brightness of each LED is determined by the pixels on the screen (or the audio). This means that the only way to implement a brightness slider that worked (when a specific colour was set from within HA) was to do it the was it is, unfortunately meaning it jumps the lights to white if pressed while in any other mode.
From my testing just now the following works (at least on a 2016+ model)
Changing brightness once a colour is set (Effect: Manual)
(After the previous) Changing colours without affecting the brightness
Changing brightness in any effect other than manual
That was the best I could achieve when I was looking into it (a long time ago now)
If you do find a way around it though, please let me know, I’ll update this component too
Ah wow, then it’s really different.
I cannot change color without affecting the brightness. It goes straight to full power.
I need to start playing with the api a bit and check out the hue component that I have not tried yet…
Another problem I found is that after powering the TV up after using the component, the /currentconfiguration endpoint returns always empty (component shows status unknown) and the only way out of it is to change the mode from the remote, where I find the ambilight in “follow app” mode, a mode that on my TV is usually grayed out.
I’m thankful for philips to have given us any api at all… But sometimes it really feels like a sloppy afterthought.
Just send a POST request to /menuitems/settings/update with the following body: {"values": [{"value": {"Nodeid": 2131230769, "Controllable": "true", "Available": "true", "string_id": "Brightness", "data": {"value": 10}}}]}
The "value" key should be an integer between 1 and 10.
Has anyone managed to set up an automation to turn the ambilights on at sunset, then off at say 2am, even if the tv and ambilights are off, so they do not come on the next morning?
I haven’t yet… because they show as unavailable one the TV is off. So I might do one using a LUX sensor and if above a certain brightness, when the TV is on turn them off and back on when it drops to a certain level
Thanks, I considered that, but would it work, if the TV was off when the lux dropped would it turn the lights off when the TV was switched on? Thinking about it, not sure having them turning on at dusk will work if the TV is already off…
I would have it check the light level when the TV goes from off to on and another automation that if the TV is on with a condition of light level being above a certain level to keep them off or on. I might have a bash tonight.
Hey, thanks for your amazing work on this! I wanted to implement it but I have a problem. When I set everything up I get this error when I check the config file:
Integration ambilights not found when trying to verify its light platform.
I put the light.py file in the right directory, and everything else like it’s stated on the Github Page. Does anyone know how I can solve this?