-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for Televisions #121
Conversation
Sorry for the delay in responding to this, and thanks very much for putting this together. Is there a (public) document available with the actual HAP specs for TV's? |
No public document that i'm aware of, I think the only official one is the commercial HAP document that is under NDA. The IDs, Characteristic names, etc I found looking at the HAP-NodeJS repository. |
…hen they have write perms
Any progress on getting this merged? Im happy to keep my fork with the TV additions but it would be nicer for them to be merged into the main project i think... |
I'm currently working through compatibility issues and fixes so HomeSpan will compile and run under Arduino-ESP32 2.0.0 (released a few weeks ago) with support for the ESP32-S2 and ESP32-C3 chips (which are slowly replacing the ESP32 chip). Small differences between the chips are just enough to "break" certain HomeSpan feature. My plan is to weave the TV controls into a new 2.0 version of HomeSpan that supports all three ESP32 chips. |
Thanks again for adding in the codes for television support, as well as for the modifications to allow string characteristics to be updated. I've merged all the changes into the current dev branch (named dev+TV) that I will use for the next release. I've been testing all the TV features and think I have a good sense of how most of the characteristics operate. From the Home App it seems you can only turn on/off the TV and set the input source. Also seems that Characteristic:Name() is totally ignored and instead you need to use Characteristic:ConfiguredName() to pre-name the input sources as well as the TV itself. The input sources utilize IsConfigured() to control whether the source is accessible. It is also optional - if you leave it out the input source shows up as a choice but is not configurable (i.e. cannot be renamed) from the settings screen. The CurrentVisibilityState() and TargetVisibilityState() are likewise optional and allow you to select from the settings screen which input sources are visible as a choice. Renaming input sources from the settings screen works well, but Apple's HAP implementation for this is a bit over-the-top. Rather than propagate the new name across devices in the background (as is typical for name changes), HAP updates the name on the Accessory and then relies on the Accessory to notify all the other controllers. This is why STRING updates are needed. There's nothing wrong with this method, and it works fine, but Apple is using the Accessory to propagate information that the Accessory itself doesn't really need to know. The only other Characteristic that seems to do anything in the Home App is PowerModeSelector(). This poorly-named characteristic has nothing to do with on/off power, but rather activates a new choice on the settings screen that allows the user to open the TV Settings. Perhaps the word "power" is supposed to mean "power user?" None of the other characteristics seems to have any effect in the Home App. However, if you open the remote control widget the TV shows up as a choice with a fixed layout of one center button, 4 directional arrows, an "info" button, a "play/pause" button, and a "back" button. These cause updates to the RemoteKey() characteristic, which provides for more granular control of the TV. Unfortunately, the iPhone's physical volume buttons do not trigger any updates, and the TelevisionSpeaker service does not seem to do anything. Does all this match with your own testing? |
Essentially, yes.
|
This pull adds support for the following services:
And the following Characteristics:
Also adds an example for a sample Television