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.
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.
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:
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:
OH_HOME=/var/lib/openhab
source $OH_HOME/tmp/appletv-binding/bin/activate
pip3 install git+https://git.sr.ht/~hww3/pyatv
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/start.sh - it now looks like this:
#!/bin/sh
echo Launching the openHAB runtime...
if [ -r /usr/share/openhab/test.sh ]; then
. /usr/share/openhab/test.sh
if [ -r /etc/profile.d/openhab.sh ]; then
. /etc/profile.d/openhab.sh
fi
if [ ! -z ${OPENHAB_RUNTIME} ]; then
RUNTIME=${OPENHAB_RUNTIME}
else
RUNTIME="$(dirname "$0")/runtime"
fi
exec "${RUNTIME}/bin/karaf" "${@}"
I’m not using openhabian here, so I will probably be playing catch-up… I think the values you have in test.sh 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!
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 - but all that it part of OH charm - I can now help out with bindings and test stuff!! Nice bonus
The changes I made were the following:
PyATV.java - rogue character " ` "at line 482
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.
I"m afraid you haven’t given us much to work with, can you be more specific what’s gone wrong? Log files that demonstrate the problem are most helpful here.
I just updated my ATV to tvOS 18 and it was showing as offline initially. I looked into it and it turned out that the network MAC address (and thus the identifier used to communicate with the device) had changed following the update. This is meant as a security feature to prevent tracking, but it effectively causes the device to be disconnected from openhab. iOS devices do this as well and while it’s a nice feature from a personal security standpoint, it’s a hassle as it results in “unknown” devices showing up on your network.
I only just made the connection (pun intended) that this was happening on tvOS as well. The long term solution is for the binding to periodically scan the available devices on the network to see if any things have matching names but different identifiers and update them accordingly. I probably won’t have time to do that in the next few weeks, so your options are:
Check your inbox to see if it’s discovered the “new” device, then add it and copy the settings from the old, non-working device to the new one. That should cause the new device to be online with the auth settings you previously configured. Once that’s working, you can delete the old device. Unfortunately, because the identifier is part of the default thing ID, you’ll probably need to re-link your items so that they point to the new thing ID.
If the device doesn’t show up in your inbox, you might have to delete the thing before it’s rediscovered. I recommend copying the auth settings from the old device so that you can paste them into the new one without having to re-pair.
If you are feeling brave, you can edit the config files directly by doing a find-and-replace across the files in your userdata/jsondb directory. You can get the old identifier and MAC address from the thing properties and the new MAC address and identifier by doing an pyatv scan (I’m pretty sure this is described in the setup instructions, but basically just run “atvremote scan”.) Make a backup copy of the json files and shut down openhab before making any changes. This is trickier, but has the side benefit of updating the item to channel links for you.
Once I fixed this problem, everything seems to work. If that’s not the case for you, please respond back with some more details of your situation.
Traceback (most recent call last):
File “/var/lib/openhab/tmp/appletv-binding/bin/atvremote”, line 5, in
from pyatv.scripts.atvremote import main
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/init.py”, line 24, in
from pyatv.protocols import PROTOCOLS
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/init.py”, line 10, in
from pyatv.protocols import airplay as airplay_proto
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/airplay/init.py”, line 28, in
from pyatv.protocols import mrp
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/mrp/init.py”, line 59, in
from pyatv.protocols.mrp import messages, protobuf
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/mrp/messages.py”, line 8, in
from pyatv.protocols.mrp import protobuf
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/mrp/protobuf/init.py”, line 9, in
from . import AudioFadeMessage_pb2
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/mrp/protobuf/AudioFadeMessage_pb2.py”, line 16, in
from pyatv.protocols.mrp.protobuf import PlayerPath_pb2 as pyatv_dot_protocols_dot_mrp_dot_protobuf_dot_PlayerPath__pb2
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/mrp/protobuf/PlayerPath_pb2.py”, line 15, in
from pyatv.protocols.mrp.protobuf import Origin_pb2 as pyatv_dot_protocols_dot_mrp_dot_protobuf_dot_Origin__pb2
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/mrp/protobuf/Origin_pb2.py”, line 15, in
from pyatv.protocols.mrp.protobuf import DeviceInfoMessage_pb2 as pyatv_dot_protocols_dot_mrp_dot_protobuf_dot_DeviceInfoMessage__pb2
File “/var/lib/openhab/tmp/appletv-binding/lib/python3.9/site-packages/pyatv/protocols/mrp/protobuf/DeviceInfoMessage_pb2.py”, line 34, in
pyatv_dot_protocols_dot_mrp_dot_protobuf_dot_ProtocolMessage__pb2.ProtocolMessage.RegisterExtension(deviceInfoMessage)
AttributeError: type object ‘ProtocolMessage’ has no attribute ‘RegisterExtension’
Please advise what I can do in this case to make this work again.
What kind of device are you using, and what version of the atv/homepod OS are you running? I haven’t seen this error before, but it’s possible that Apple has sprung something new on us. You might also try removing the python venv completely.
Also, have you updated your python version recently? The error seems like it might be coming from an “upstream” dependency (I see references to protobuf in the error you included) that’s made some incompatible changes. Let me know the version you’ve got installed and I can try to reproduce.
Hello OMR,
Yes in the openhab logs I see the same error.
I am sure that the problem is between the python virtual environment and pyatv because as I mentioned previously if I try the “atvremote scan” command outside the virtual environment I am able to find all the ATVs on my network.
If you look in your openHAB’s userdata/tmp directory, there should be a folder called appletv-binding. If you remove that, you should be able to reinstall a clean copy of the pyatv module.
Note that it’s still possible you’re running a version of python that doesn’t work with the version of pyatv module the binding relies on, and it’s not unusual for multiple versions of python to be installed at once. If you let me know what version of python you’re using that causes this error, I can check to make sure it will work properly.