Hi Michel,
yes of course. I deleted the HomePod mini first and add it again.
Hi @BasMilius,
this is the no. of the new diagnostic report: f2bd15fd-a4d3-4038-ba95-fbbed94ba3d8
How is the Python version running for everyone testing it? I’ve postponed updates to see if it stops rebooting Homeys.
I’m currently debating with myself if the Python version is the right move. I’ve found a solution for the TypeScript-based version for keeping the Companion Link protocol for Apple TV’s alive and detect port changes. That was the biggest painpoint of the TypeScript based version. So, maybe porting the new features introduced in the Python-based version back to the TypeScript-based version isn’t that bad of an idea.
The reason I’m debating is that I don’t have a way to reduce CPU and RAM usage in the Python-based version, because all of it is managed in the PyATV library. It’s also a fact that that library alone takes up 99% of the app size and resource usage…
What does everyone think.. Is it a good idea to do a new TypeScript-based test release with some fixes and see how that runs?
Hi @BasMilius ,
I would vote for typescript. My biggest annoyance with that version was the companion link getting lost once per day (on average).
Although the python version runs stable for me, it is indeed eating a lot of memory and each update my Homey is indeed crashing or restarting.
I would also vote for typescript
Yeah, same here.
Thanks for letting me know @Anton_Wierenga @Asterix @DaneedeKruyff!
I’ve just finished backporting all new features to the TypeScript version. I’ll let it run for a few days in my own setup to see if anything weird happens. If everything is ok, I expect to release thursday 
Hi BasMilius, using less storage space is definitely a good idea. Do the play and pause functions still work in apps like YouTube, Netflix, and others?
@ChrisWat It works here, but there could be differences… We’ll find out I guess 
@BasMilius Thanks
That somehow works adding the devices again with the newest app version.
Until now I only added the HomePod minis. Surprisingly I could add them again/additional to the not working but installed devices. So I din’t need to delete the not working version/devices at first. This is just better for changing /adjusting all the flows where the old & non-working devices are still in use. Easier to swap them with the newer working versions.
AppleTV’s I didn’t test/replace yet.
Thanks @BasMilius for all your work and effort!
Homey Pro 2026, Apple TV & HomePod app v1.5.3
Issue:
The app previously discovered and controlled multiple Apple TVs and HomePods. After physically moving one Apple TV, the app no longer finds or controls several devices that were previously working.
Affected devices:
BR-Left (HomePod)
BR-TV (Apple TV, moved)
LR-Left (HomePod)
LR-Right (HomePod)
LT-TV (Apple TV)
What I tested:
Rebooted and power-cycled the affected Apple TV
Rebooted Homey
Confirmed devices are up to date
Confirmed AirPlay settings are correct
Confirmed all devices are on the same single home network
Temporarily tested discovery with the moved Apple TV in another location on the same network
From my Mac, dns-sd -B _airplay._tcp successfully shows the Apple TVs and HomePods on the LAN
Important detail:
My Mac can still discover the affected devices via Bonjour/AirPlay, but the Homey Apple TV & HomePod app no longer discovers or controls them.
Error seen in Homey before broader failure:
“Something went wrong while controlling BR-TV. Cannot read properties of undefined (reading ‘sendCommand’)”
Apple TV model involved:
Diagnostic code:
a99a2dd5-67fd-43f0-9da0-3da8107f1297
@Tom_Evans What happens if you delete the devices and re-pair them? I cannot find any errors in your diagnostics report, besides that the devices cannot be found on your network. Version 1.5.3 saves the hostname of the device as its ID, which can change. In a future update this will be changed to mac addresses.
So, Athom today released v13.1.0-rc.4 of Homeys software, which appears to fix the reboot issue of the Python version, at least, it works well over here. If anyone wants to try this, upgrade your Homeys software and reinstall the app. It should be fine.
Memory usage is still on the bad side however.
EDIT: Nevermind, replacing an installed app with `homey app run` for the development version still reboots my Homey 
Great news! Just now I experienced a Companion Link port change.
The production version (1.5.x) of the app that is running on my main Homey triggered the “Companion Link failed” trigger to restart the app automatically.
The new TypeScript version I’m currently testing on my development Homey is handling it and picking up the port change. So it seems fixed!
Everything is on track for a release thursday, it also has some new protocol level features that I’m able to explore later
You were correct. I recently renamed the Apple TV’s and that must have started the issue.
What I Did
Removed all Apple TV’s and HomePods from Homey.
On each Apple TV, went to Settings > AirPlay and HomeKit and made sure AirPlay was on. For testing, set access so it is available to everyone on the same network. This was specifically called out for discovery.
Rebooted Apple TV’s .
Rebooted Homey Pro 2026.
Since this app appears to discover over the local network, a stale network advertisement can keep a deleted device from reappearing until the Apple device restarts.
Re-added devices to Homey.
Devices were discovered and added to Apple TV & HomePod app.
Tested power on and power off with one TV with success. Will continue testing with other devices.
Do you have a timeline for the new MAC ID-based version? Will it require deletion of current devices and re-pairing?
Thank you for your rapid response!
@Tom_Evans Great that it’s working
Regarding your question for mac addresses, no timeline yet. There will be an in-between release first, but the plan is to automatically migrate to mac addresses, so as long as the devices keep the same name you’ll be fine I think.
Sounds promising @BasMilius ! Look forward to test it later this week.
A new TypeScript-based release with major improvements to the underlying set of Apple Protocol libraries. Expect connections that are a lot more stable and overall less ram usage compared to 1.5.x and a lot less ram and cpu usage compared to 1.6.x Python releases.
Changelog
Known issues
Disclaimer: If you currently have the Python test installed and are on Homey software prior to 13.1.0-rc.6, this update will reboot your Homey. This is because of the Python app and won’t happen again from this new version.
Disclaimer: Devices added in the Python-test need to be re-paired. This is because I focused on a migration path from 1.5.x instead of the Python-test releases, which store device credentials differently.
Apple Protocols library
I did a lot more reverse engineering with the help of Claude Opus 4.6, which resulted in a few new features in the underlying libraries powering the Homey app. I have yet to decide what I’m going to put in the Homey app. But it’s promising. Claude was also able to point out some logic that was faulty in both PyATV and my libraries.
For everyone running the new 1.7 test version, please let me know how it goes. Especially after a few days. If all goes well, I’ll do a new production release next week.
Imstalled 1.7.0 last night and it’s stable since then @BasMilius Also memory usage much better with this version. Many thanks!
