Would be nice to see this binding built for Openhab 3!
2 Likes
Would be really nice to control the ATV through openhab!
Hi all-
I’ve spent a little time looking at what needs to be done to get this binding working on OH3 and with newer ATV devices. I spent quite a bit of time trying to get jpy working and didn’t have much success. I think the limitations placed on us by OSGI and jpy make the problem unlikely to be easily solved.
However, pyatv includes a utility called atvscript, which I think can be used to avoid java-python inter-operation.
As a first step, I managed to get discovery working. I think pairing without running atvremote on the command line is going to be hard to do, but with good documentation that might not be a huge problem. The atvscript tool can also push updates to us in real-time, so there’s actually an advantage versus polling as the current binding does.
Hopefully most of the binding code can simply be reused, which is always a plus. Not sure how much time I’ll have to work on this, but if anyone is interested in testing, let me know!
Somehow the OH runtime includes jpy, but I never got to the point to get access to this instance. In general that shouldn’t be unsolvable, but you are right I also spent a lot of time on this. The reason for polling was just a lack of Python knowledge. The bindings brings a it’s own and modified copy of the older pyatv. The way to include external components in OH3 has also changed. The binding did it’s job for OH2, but I think a rework if the lower layer is required.
Using the command line tools and redirecting the output should be feasible. It did this once for my WhatsApp binding running youwsapp cli and this worked pretty well (I could re-open the repo if you are interested in the code). Let me know if you have questions in the existing code.
And yes, I could support testing, because I can’t control my ATV from OH anymore 
Hi-
Thanks for your feedback! I appreciate that you’ve responded so quickly. I had a look through your code for the binding and it seems pretty reasonable. Generally speaking, I give my work freely to whoever wants to use it, so regardless of whether I succeed, the changes I try will be free for anyone to take.
I do like the idea of jpy, and (oddly enough) I’ve got experience with java/native interaction. Unfortunately, I think that the restrictions OH3 have put in place mean that it’s maybe not worth trying. I am not a python expert but I think if (as the ultimate goal) the binding were to read the output of a python script that runs commands without having to start it each time, we can have all of the benefits of embedded python without the hassle of getting it to work. There’s support in pyatv for doing that with events, so I think any changes needed should be possible to send back to the pyatv folks.
Long story short, I have an idea of how this might be done, but I would be glad to look at your code for inspiration! I can keep you posted and once I have something that seems like it works, I’ll push it somewhere you can have a look.
One other thing, it seems like pyatv can control other devices like HomePod minis and such… was wondering if maybe there was a better name for the binding but am not sure I have a good idea. Something maybe to think about!
Hello all-
I’ve been working on producing a version of this binding that works with OpenHAB 3 and have something that I think I’d call a “proof of concept.” It’s very early in the development phase, so I wouldn’t recommend this for the faint of heart. That said, the basic functionality seems to work, and there are a number of additional features beyond what the previous versions provided. I’d love to get some feedback if anyone is willing to have a go.
Some details of what’s new, changed and where problems likely lurk are in the README:
https://git.sr.ht/~hww3/org.openhab.binding.appletv
I’ve also prepared a jar with the current version of the code, so the portion of the install dealing with building the binding can be skipped by downloading the pre-built jar from this download page:
https://git.sr.ht/~hww3/org.openhab.binding.appletv/refs/0.1.0
You’ll still need to install the enhanced version of pyatv, as described in the instructions. Hopefully in the future that can be simplified as well.
Note: I don’t use item or thing configuration files myself, so any questions about how to set those up (vs using auto-discovery) will probably need to be answered by others.
As always, please feel free to get in touch with any comments, questions or suggestions.
1 Like
Hi there,
as i´m now also a owner of an apple-tv, i just wonder what the current state is here?? I´m very open to do some tests if needed. Does it make any sense to use the code from @hww3 ??
I´m currently running openHAB 3.3.0.RC1 on Openhabian (raspberry) and have an ATV 4k, latest software-release. Let me know, how I can help, even I´m not able to code…
cheers
Hi-
Since you’re running openHAB 3, the rewrite of the binding I’m working on is your only option, as the previous version won’t work at all. I’m actively working on it, so if you do run into problems using it, I can likely fix them pretty quickly.
I’m in the middle of adding support for using AppleTV devices as “audio sinks” so that you can play sounds or speech to them. That will probably be ready for testing in a week or two.
Sorry for delayed answer, I missed out your answer.
back to topic: So you recommend to use the .jar in my environment, cool!
Will do so and report back, might take a while, much other things to do in summer
Regarding “Audio Sink”: Do you think this make sense? A ATV do not have own speakers (AFAIK), so you have anything additionally switched on and run the whole time to get the output heared. In my case it is a receiver, which consumes (for me) to much power to let it run 24/7. A Alexa/HomePod etc. consumes much less power, so it is for me the much better solution. Not sure, whether I got your use case for this??
Anyhow, I do not have a concrete use case for the ATV at all at the moment, just want to “see” it and probably switch it ON/OFF from my openhab-environment.
Yes, it may not be super helpful to use it as a default audio sink, but if there was a notification and you were actively using the ATV device (which is a condition you could check), you might want to route the audio to it.
Also, calling this the “Apple TV” binding is a bit misleading, as there are a number of devices that can potentially be controlled by it. I’m looking at supporting HomePods and other devices that support AirPlay, and those could be a default audio destination. Getting that working reliably is going to take a bit of work, so it’s not going to happen immediately but I think it’s a nice option for the future.
Anyhow, feedback is always welcome and I’ll try to keep those links updated with the latest versions!
1 Like
Hi, I just installed the most recent build with the current snapshot (3.4.0-SNAPSHOT - Build #3011). I had some trouble getting pyatv working, due to a library issue with miniaudio. For that, I had to install it from source, modifying the libs outlined here: _miniaudio.abi3.so: undefined symbol: __atomic_load_8 on raspbian · Issue #52 · irmen/pyminiaudio · GitHub
I am only able to pair with the “companion” protocol, and it wont receive any updates, giving the following error:
{
"result": "failure",
"datetime": "2022-07-20T15:14:33.403169-07:00",
"exception": "power_state is not supported",
"stacktrace": "Traceback (most recent call last):\n File \"/usr/local/lib/python3.7/dist-packages/pyatv/scripts/atvscript.py\", line 452, in appstart\n print(args.output(await _handle_command(args, abort_sem, loop)), flush=True)\n File \"/usr/local/lib/python3.7/dist-packages/pyatv/scripts/atvscript.py\", line 256, in _handle_command\n return await _run_command(atv, args, abort_sem, loop)\n File \"/usr/local/lib/python3.7/dist-packages/pyatv/scripts/atvscript.py\", line 281, in _run_command\n output(True, values={\"power_state\": atv.power.power_state.name.lower()})\n File \"/usr/local/lib/python3.7/dist-packages/pyatv/support/shield.py\", line 72, in _guard_method\n return func(self, *args, **kwargs)\n File \"/usr/local/lib/python3.7/dist-packages/pyatv/core/facade.py\", line 338, in power_state\n return self.relay(\"power_state\")\n File \"/usr/local/lib/python3.7/dist-packages/pyatv/core/relayer.py\", line 91, in relay\n target, chain(self._takeover_protocol, priority or self._priorities)\n File \"/usr/local/lib/python3.7/dist-packages/pyatv/core/relayer.py\", line 114, in _find_instance\n raise exceptions.NotSupportedError(f\"{target} is not supported\")\npyatv.exceptions.NotSupportedError: power_state is not supported\n"
}
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