Binding for Apple-TV


There are 2 versions of the AppleTV binding: the original version that uses an embedded python instance, and which only works with older versions of OpenHAB, as well as a version that I’ve been working on that supports openhab 4 and communicates with a customized version of pyatv.

I started working on the alternate version because I was never able to get the embedded pyatv to work properly. It sounds like you’re using the version that uses an embedded python interpreter.

Any chance you can confirm that? Letting us know the URL where you downloaded the binding would give us that information.

A side note: AppleTV/HomePod support is a bit of a DIY situation regardless, as Apple have not published details of their control protocols. However, I’ve been able to implement support for most of pyatv’s features on an ongoing basis. Perhaps long term planning to upgrade to openhab 4 would be your best bet if ATV support is important to you.


1 Like

Hi Bill.

I have used the binding jar link from your posting from Jan 2023.

But in the meantime, I have used a different solution for myself. I have installed pyatv-mqtt-bridge and have thus established the connection to Openhab via the mqtt interface. It works so far without any problems for me.


Hello Gents,

I updated today my openhab to version 4.2.0 (it was before 4.1.0) however later on I noticed that the ATV binding 4.0.1 stopped working noting that on the 4.1.0 it was working properly. and here is below the error showing on the logs:

2024-07-08 15:06:36.096 [ERROR] [enhab.binding.appletv.internal.PyATV] - Exception on PyATV call: Error executing [/var/lib/openhab/tmp/appletv-binding/bin/atvscript, scan] (class java.lang.RuntimeException)

java.lang.RuntimeException: Error executing [/var/lib/openhab/tmp/appletv-binding/bin/atvscript, scan]

at org.openhab.binding.appletv.internal.PyATV.exec( ~[?:?]

at org.openhab.binding.appletv.internal.PyATV.sendCommands( ~[?:?]

at org.openhab.binding.appletv.internal.PyATV.scanDevices( ~[?:?]

at org.openhab.binding.appletv.internal.AppleTVHandlerFactory.scanDevices( ~[?:?]

at org.openhab.binding.appletv.internal.discovery.AppleTVDiscoveryService.startScan( ~[?:?]

at java.util.concurrent.Executors$ [?:?]

at java.util.concurrent.FutureTask.runAndReset( [?:?]

at java.util.concurrent.ScheduledThreadPoolExecutor$ [?:?]

at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]

at java.util.concurrent.ThreadPoolExecutor$ [?:?]

at [?:?]

2024-07-08 15:06:36.101 [ERROR] [enhab.binding.appletv.internal.PyATV] - Scanning for Apple-TV devices failed!

And let me note that the “atvremote scan” command is still working and discovering the Apple devices

Any advice, please?

Just scroll to one of my posts above…
The instructions also states a reinstall is necessary after an update…

Thanks a lot @OMR, I did the same steps, and then the Apple TV was back online again.

Thank you

I’m trying to run the OH3 version of this binding, and I cannot get the binding to find the atvremote scripts. I’m in the same spot as @Adam_W - I’m running OH3 (3.4.5 to be exact) on an openHABian installation. I’ve downloaded the 3.3 snapshot jar from the git repo. Its installed, when I source the python venv I can run atvremote commands without any issue, but the binding won’t find the script.
I’ve tried the following:
Install the venv in OH_HOME/tmp, OH_HOME/userdata/tmp (created the userdata directory as it is not present in openhabian) - where OH_HOME refers to /var/lib/openhab, I’ve also tried creating folders /opt/openhab3 and installing pyatv there and referencing that as OH_HOME. But without knowing where the 3.3 binding expected to find the atvscripts I’m searching in the blind. Any help would be appreciated

I’ve made OH_HOME environment variable be declared along with other OH variables, in /etc/default/openhab, so it survives restarts (which I think is the problem @OMR was experiencing)

Did a apt update/upgrade Y’day. No OH update, so effectually just a restart of OH 4.1.1
After that, the binding showed a Configuration Error
Log said: Failed to execute commandLine '[/var/lib/openhab/tmp/appletv-binding/bin/atvscript, scan]'
After doing this, it started working again:
source $OH_HOME/tmp/appletv-binding/bin/activate
pip3 install git+
Not sure what happened there, as I’m fairly certain I have done reboots before …

The problem there I think was that when you declare an environment variable from the shell, it does not survive a reboot, you then have to declare the variable again.

I’ve also tried sourcing the venv on boot by editing the openhab startup script found at /usr/share/openhab/ - it now looks like this:


echo Launching the openHAB runtime...

if [ -r /usr/share/openhab/ ]; then
  . /usr/share/openhab/

if [ -r /etc/profile.d/ ]; then
  . /etc/profile.d/

if [ ! -z ${OPENHAB_RUNTIME} ]; then
    RUNTIME="$(dirname "$0")/runtime"

exec "${RUNTIME}/bin/karaf" "${@}"

where containse the sourcing of pyATV:


source "/opt/openhab3/userdata/tmp/appletv-binding/bin/activate"

I feel like I’ve tried all the options, but I’m probably missing something obvious.


I’m not using openhabian here, so I will probably be playing catch-up… I think the values you have in are probably incorrect (my openhab3 install is in /opt/openhab3, but I don’t think that’s where openhabian puts it.) You’re correct that changes you make on the command line won’t survive a restart. As you’ve noted, the start script sources a bunch of other files that you can edit to include the environment values you need. Hopefully if you change that to match the locations that openhabian uses, things will work. As a side note, there’s nothing magical about the locations that I or openhabian use… they just need to be correct so that the binding can find the pyatv scripts. It’s my hope that eventually this can all be automated, but unfortunately, that’s a task that’s been languishing on my to-do list.

Please get in touch if you have more difficulties getting things working, and I’ll try to help figure the problem out!


openHABian does a package installation in the background, therefore the folder structure described in our documentation applies:

Thanks for getting back, after a few more hours of trying to get the 3.3.0 version to work, I ended up recompiling your 4.x binding to v3.4.x - I only had to change a couple of lines of code, and some hours learning how maven works, and how to compile bindings :upside_down_face: - but all that it part of OH charm - I can now help out with bindings and test stuff!! Nice bonus :partying_face:

The changes I made were the following: - rogue character " ` "at line 482

And the pom.xml now looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project xmlns="" xmlns:xsi=""




  <name>openHAB Add-ons :: Bundles :: AppleTV Binding</name>

		<spotless.check.skip>true</spotless.check.skip> <!-- Spotless disabled for now -->


I’ve changed the version to 3.4.6, and added some properties to skip some fail checks - there were some 110-ish, and they all dealt with header comments and logging, which is all looks - so i wasnt too bothered about that.
I copied your binding into my oh-addons 3.4.x repo to get the pom to reference the appropriate “parent” and Bob’s your uncle!.

It is very certainly not the “proper” way, which is why I am hesitant to put a link to the jar file here, but I can put it on my github if others would like to use it, and there are no objections by the author or any moderators, or others of influence in the forum.

I’m glad you were able to get things working. The spotless checks vary from version to version so turning them off is reasonable. You can also use mvn spotless:apply to get it to “reformat” your code so that it conforms.

I think what you’ve done seems reasonable… I think I’d have taken a similar approach. Note that you don’t have to move the binding source directory into the openhab-addons repository if it’s easier for you to keep track of things. Just include this in the parent definition of your pom.xml (change the path as appropriate):


I don’t have any objection to you making that available, though perhaps it would be better to say it’s version 4.x.y compiled for openhab 3.4.x, so that people more easily understand it has the newer functionality rather than that from the binding when I started working on it a year or so ago. Pretty sure you can specify the version of the module independently of the version of the openhab addons dependency.