Also, despite setting --remote-name when pairing, the remote is always called “Living Room”
What type of device are you trying to pair? Can you provide the output of “atvremote scan” for the device you’re trying to pair (feel free to remove the identifiers)?
power_state is provided by the MRP protocol, so if your device doesn’t provide MRP, that feature may need to be gated. I’m working on that, but it’s not quite ready to go.
I suspected as much.
I’m trying to pair an Apple TV 4K. When I ran the pairing in debug mode, it had a message that MRP is disabled for iOS >= 15. I’ll post the output shortly…
I just took a look at the settings on my device and it appears that the Companion protocol pairing shows up as “Living Room” on mine as well (it’s an AppleTV Gen4, not 4K). The device I tested isn’t called “Living Room”, so that must be coming from somewhere inside of pyatv.
Edit: Actually, when I paired RAOP, I now have 2 devices: Living Room and Unknown device (regardless of whether I specify the remote name on the scan command. So, I think there’s a bug in pyatv. It doesn’t seem to affect functionality but perhaps worth reporting as it’s unexpected.
Sorry for all the replies here… didn’t notice your follow-ups.
I confirmed that on my TvOS 15+ device, MRP is disabled and I didn’t pair with that protocol, but I did pair with Companion, Airplay and RAOP (aka Airplay2). Check under “Airplay and Homekit” that you are set to “Allow anyone on the same network” is enabled and that “Require password” is off… people will still need to pair but it will at least be possible for you to pair Airplay and RAOP.
I just checked manually and if I have paired airplay, I can get power_state; if I only use the companion credentials, it fails. So, we have to make sure you’re paired with at least Airplay.
Example:
atvremote -i MYDEVICEID power_state --airplay-credentials MYAIRPLAYCREDENTIALS
PowerState.On
Unfortunately, the various control protocols in use by ATV and friends seem to be in a constant state of flux, and we’re left to play catch-up. Luckily, there seems to be a strong community around the pyatv project, so hopefully many hands can keep things working properly.
I’ll give that a try. I assume, there’s probably no way to authenticate HomeKit to keep it on “This Home”
That understandable, but I think atvscript shouldn’t just error out, it should just skip values it can’t read.
The mechanism for “this home” security is based on Apple IDs (those people you’ve invited to control the home). I don’t know if that’s been successfully implemented outside of Apple, but there’s also a cognitive disconnect there, because “this home” is actually a group of people using apple devices, versus things like openhab. I believe some work had been done to do PIN authentication to homepods, but it isn’t for the faint of heart. I think that is because there’s no way to effectively communicate a PIN from a device without a display.
Anyhow, hope you were able to get things sorted out; I’ve got a new version coming that does a better job of detecting the protocols available as well as the features supported by each device. Will post more about that here when it’s ready for testing.
Hi @hww3 sorry to ask, but are you making any progress yet? I would definitely like to know wether my AppleTV is playing or pausing the item it is playing currently so that I can dim the lights when playing and increase at pause.
Is there anything I can do for you to help you with the binding? 
Hi,
I’ve got a version that I’ve been testing; I haven’t made any announcements about it because I was having some problems with my openhab instance locking up and I suspected the problem might be related to a resource leak in the AppleTV binding.
My install has been running for about 2 weeks; if I get to 3 without having any problems, I’ll report back and make this new version available.
Bill
4 Likes
Ok, a quick update here; and a bit of a mixed bag, unfortunately. There is a remaining leak that eventually causes my openhab install to lock up. Basically, the process runs out of available file descriptors (ie, too many open files). I was able to grab some data, though, and it’s definitely coming from the AppleTV binding. I was sure I’d fixed the obvious source of the problem, but now I’m wondering if perhaps I’m not actually running that code. So, I’ll do a little more experimenting and should have some answers, hopefully in a week.
The good news, is that other than this resource leak, the binding seems to work with my non-4k AppleTV and my HomePod. There are limits to what you can and cannot do; but I think that’s more closely tied to what Apple allows each device to do. I also have preliminary support for using the speaker devices as an audio output for openhab, which is kind of cool.
If you don’t hear from me by the end of next weekend, feel free to remind me 
Bill
2 Likes
That’s really good news for Apple users, especially the HomePod support! It will be interesting to see what is and isn’t available to users. 
Hi-
Your timing is perfect. Over the weekend I found what I believe was the cause of the resource leak, and so far things are holding steady after 2 days, so I’m feeling good that the major source of the problem has been found. Obviously, this is still alpha level code quality, and there are problems that have been identified with pyatv’s communication with devices that translate into data changes not being noticed by OpenHAB, but a lot of the basics work pretty well.
Here is the readme with installation instructions. I’m linking to the raw markdown because I haven’t finished formatting the examples yet:
https://git.sr.ht/~hww3/org.openhab.binding.appletv/tree/master/item/README.md?view-source
Here’s the binding jar itself:
https://bitbucket.org/hww3/temp/downloads/org.openhab.binding.appletv-3.3.0-SNAPSHOT.jar
I should note that adding pyatv to openhab’s working path might be tricky if you’re using binary packages or openhabian. The easiest might involve adding the “source” line from the readme to the karaf script in your openhab’s installation and then restarting. I hope to have a better solution soon.
Bill
2 Likes
Thanks for publishing and thanks for the comprehensive docu. 
The only challenge I have:
how to install Phyton when OH is installed in a docker container?
I could install the binding, I could add a thing but pairing credentials are not available to me due to missing Phyton and missing commands (atvremote )… 
Is there an additional way to add and pair AppleTV with OH-binding?
2023-02-01 15:36:24.900 [ERROR] [enhab.binding.appletv.internal.PyATV] - Scanning for Apple-TV devices failed!
2023-02-01 15:36:24.900 [INFO ] [ding.appletv.internal.AppleTVHandler] - Apple-TV discovery returned null
2023-02-01 15:36:39.891 [INFO ] [ding.appletv.internal.AppleTVHandler] - Stopping Apple-TV discovery scan
Hi-
Unfortunately, I don’t think there’s an easy answer if you’re not building your own docker container. You could get a login shell into the running container and do the installation that way, but it would go away if/when you restart the container. You’d probably also need to install python3 and the build essentials package (compiler, git, etc).
The medium-term plan is to enable the binding to install pyatv if it notices that it’s not present, but that pre-supposes that you have a python installation (and development tools) available already. Docker containers tend to only have the bare-minimum software installed, so that likely wouldn’t help, either.
You could build your own docker container with pyatv installed; the openhab-docker repository contains the instructions for building a new container, and you could add the necessary commands in the Dockerfile located in the Debian directory there. You’d just need to add commands to install python3 and the build essentials packages before the commands that install pyatv.
I’m sort of short on free time right now, otherwise I’d look into doing that myself. I think all of the information you’d need to do it yourself is in that repository and my instructions, it just needs to be put in proper Dockerfile format.
Bill
1 Like
A further follow-up here:
The documentation for the openhab docker container includes the following section about how to deal with needing software installed:
I think the suggestion is to write a script that will install pyatv (along with the prerequisite of python3 and build-essentials) before openhab is started. I’ll leave that as an exercise for someone else.
I did have a little free time tonight and I was able to build an (alpine) openhab image with pyatv installed. An example of pulling the image and then running a scan:
docker pull hww3/openhab:pyatv-latest
docker run -it --rm hww3/openhab:pyatv-latest atvremote scan
I think the docker networking would need to be properly configured in order to see the devices on your network, but I think that’s a separate issue. If that works, I’ll make my changes available so that you can just build your own images using my changes.
Bill
1 Like
@hww3: any thoughts on using GraalPy to embed pyatv directly into the Java environment, negating the need to install a separate Python environment at all (or indeed, running separate processes)?
The previous attempt at a binding attempted to use an internal (cpython) instance of pyatv, and it was a big maintenance problem. I looked into doing something similar to what you’ve described, but pyatv has dependencies on native (c-language) code that can’t be run within a jvm python.
I have experimented a bit with bundling the correct pyatv code with the binding and then creating a python virtual environment local to openhab. This would isolate pyatv from the system python install and allow the dependencies to be installed in an automated way (once python was available on the system). I think that’s about as good as we’re liable to have things until there’s a jvm-native appletv library.
Is there a OH4 .jar available somewhere?
1 Like
Hi-
Here’s the openhab binding that I’ve been running. It’s not been updated to the 4.1 series (yet), as I’m still running 4.0.1. You’ll still need to install the customized version of pyatv as described in the README link below.
http://bill.welliver.org/dist/openhab/org.openhab.binding.appletv-4.0.1.jar
https://git.sr.ht/~hww3/org.openhab.binding.appletv/blob/master/README.md
Unfortunately, because Apple do not publish specifications for the various protocols they use, this will always bit a bit of a chore to set up and keep running. I’m hoping to get the pyatv installation automated, so at least that will be a bit easier in the future.
Please do let me know how you fare, and drop a note here if you run into any trouble.
Bill
1 Like