[huesync] Hue Play HDMI Sync Box Binding - Initial contribution

[pgfeller]

This binding integrates the Play HDMI Sync Box into openHAB. The integration happens directly through the Hue HDMI Sync Box API.

The binding is using mDNS to discover HDMI Sync devices in the local network. The LED on the Sync Box must be white or red. This indicates that the device is connected to the Network. If the LED is blinking blue, you need to setup the device using the official Hue Sync App.

Community discussion thread: Philips HDMI Sync API

Closes #10218

Credits

• Marco Kawon: The code is based on his work - but the binding code was refactored/re-implemented. The refactoring is done to implement functionality step-by-step, so that I understand the code and in the hope to simplify it a bit to improve maintainability (and as a learning exercise for me).
• Andrew Fiddian-Green: Code review and technical support/advice
• April_Wexler (Kai): Testing

---

Tasks

• ☠️ Binding skeleton created for org.openhab.binding.huesync
• 🔎 skeleton mDNS discovery implemented
• communication infrastructure
  • 🔎 mDNS device discovery - use API to get device information
  • 🔐 SSL Handshake & 🔎 Discovery
  • 🤝 Device registration
  • 👋 Device unregistration (remove thing)
  • ⛔ solve timing problems during shutdown
  • 📜 improve handling of configuration update(s)
• CI/CD & Code maintainability
  • ⛔ Fix CI validation errors
  • ⚠️ Fix PR CI validation warnings
  • 🗨️ check feasibility of re-using resources for log & exception messages ✅
  • 🗨️ check feasibility of using AuthenticationStore ✅
• Implementation
  • 🔌 device status polling
    • 🐞Solve handling of invalid tokens (automatic re-registration)
    • 🐞Investigate and resolve "Bad Request" warning
    • 🐞 Investigate and resolve partial device information during "poll"
  • 📦 Create device state DTO
    • Device status
    • HDMI input/output status
    • Commands
  • Channels
    • 📜 update/revert icons to use basic icon set
    • Create .channel xml declaration/poc for device information
    • Create .channel xml declaration prototype for HDMI input/output status
    • ➕ HDMI input/output channels (read only)
    • ➕ "execution" API infrastructure added ...
      • ➕ Add support to switch ambilight on / off
      • ➕ Add support to select mode
      • ➕ Add support to select HDMI source added
      • ➕ Add support for HDMI active channel
      • ➕ Add support to adjust brightness
      • ➕ Add support for intensity channel
  • 📜 Documentation
    • README
    • PR in Docu-Repo to add binding icon

---

ℹ️: The 1st version will not support all possible functions - as the basic setup can be done via the official App ➡️ - I'll focus on status information and commands that are most relevant for automation in this PR.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/philips-hdmi-sync-api/111679/39

[andrewfg]

@pgfeller I will start to look at this tomorrow.

[pgfeller]

@andrewfg Thanks! Take your time - progress will be slow unfortunately; as free time is a rare commodity ...

[pgfeller]

@andrewfg Hi Andrew,

I hope you are fine!

I'm not sure if you're following the progress of the implementation from time to time. I've finished most of the infrastructure that I plan to use in the binding. Next I'll will implement the most important channels that are relevant for automation (this PR will not support all the available options the API provides).

I'm a little bit unhappy - as I do not manage to provide/declare all the relevant information in the .xml definitions to automatically create a nice semantic model. Is this a limitation (no problem - but then I can stop to investigate) ... - or do I miss something in the .xml structure?

I've found that there is an advanced configuration option in the UI to add channels from the equipment (very cool). I will use this in the readme to show how to structure things (here comments are also very welcome - as I'm still not familiar enough with the semantic types and properties etc ...

I think the biggest problem of OH is, that most people (including me) are not aware how powerful it is what it is capable of ... e.g. today I learned that it is possible to use f7 and other icons via advanced UI configuration ...

with kind regards,
Patrik

[andrewfg]

I'm a little bit unhappy - as I do not manage to provide/declare all the relevant information in the .xml definitions to automatically create a nice semantic model. Is this a limitation (no problem - but then I can stop to investigate) ... - or do I miss something in the .xml structure?

I am not sure what you think is missing? Perhaps have a look at the example below..

https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.neohub/src/main/resources/OH-INF/thing/thing-types.xml

[pgfeller]

Thank you for the example; I've also checked the .xsd definitions - but it seems that I've already added all the info I can. When the equipment/items are automatically created it does not look as nice as I would like to have it ... but that's not a huge problem. With the manual configuration I've added to the readme the representation in the model looks nice.

I'll keep it as is for the moment and continue with channel implementations to get functionality into the thing 🙂. I already use the alpha for some 1st simple automation tasks 👍.

Let me know if you see something I should change from a Java/openHAB framework perspective ... the infra is approaching its final shape; so I do not see any major gaps anymore in that area.

[pgfeller]

Commit 742872d is related to the following proposal/issue raised in the doc repository: #2276

➡️ simplify contribution with a lightweight environment depending on minimal configuration

➡️ might be that those files (.vscode) will not be merged, but be part of the documentation in the end. Subject to discussion ...