Thanks for your report and help!
I’ve fixed that issue in the 3.3/3.4 binding and updated the download-links above.
I will see if I can make it into the next release of openhab as an official binding.
Any luck in getting this to be an official binding? Also, will there be a new version for OH4?
Will there be a version for openHAB4.x as well?
Hey,
I can build them within next 2-3 days and let you know here.
I am basically out of this because I dropped my sync-box (no support for hdmi 2.1 etc) and use the newly released offical hue-sync-app on my samsung tv now: Works much better than the sync-box.
For LG-TVs I use hyperHDR application with some limitations.
I dont think I will ever make it official binding. There is my GIT-Repo with source-code available, feel free to take over and make it official 
1 Like
Hi Marco,
thanks your answer!
I installed your latest jar on OH4 and it worked. The syncbox was added as thing and I can control it with OH4.
Can you give us some details what is working better with that new App - from your point of view?
I am just curious
Unfortunately I don’t have a Samsung and the Philips App is not available for my TV…
I updated to the 4.0.4 binding. Unfortunately i am unable to discover new devices, because the binding is invisible for me, when trying to add a new thing via MainUI.
But i can ensure that it is installed and works, because my previously added SyncBox-Thing is working. It is connected to the binding and is providing channels.
This should be no problem, BUT: If i buy a second SyncBox, i am unable to add this one. AND, my current SyncBox-Thing uses a hostname instead of an IP. But i changed my network setup and got no longer hostnames working. Everytime i restart openHAB i need to change the Things-IP manually, because it gets resetted o the hostname.
Do you know how i can fix this? The binding isnt appearing, but working.
1 Like
I do have exactly the same problem as @DivineJimmi - and can confirm this.
When restarting OH the IP gets overwritten by a hostname - which can not be found (in my network). When I change hostname to the IP it is working immediately again.
@HomeyGER
Do you see a chance to check this, please ?
That would be great - although you stopped using the Box 
Hi @DivineJimmi,
as a workaround I changed my (Synbox) config from GUI based thing-config to textual config.
This solved my issue that IP gets overwritten with hostname after reboot.
Maybe this solves your issue as well?
That’s my huesyncbox.things:
Thing huesync:box:01 "Philips Hue HDMI Sync Box" [
host="192.168.2.115",
httpPollingInterval=60,
apiAccessToken="abc123...="
]
best, Kai
Thanks, works!
1 Like
Hi Marco,
recently I added a Hue-HDMI-Sync Box to my setup and I’m now interested in integrating it into the OH. Is is correct, that you did not contribute your work to the official repository?
Do you mind if I fork your code and have a look if I can add it to the official repository/add-on collection? I have to see if an API update makes sense, or if it even can be merged with the existing hue binding … 
I’ll have a look and continue the technical discussions in
Let me know in case you do not like that approach. I do not want the credits for your work of course - I just hink it would make sense to have it in the official repo for convinience …
with kind regards,
Patrik
1 Like
Hi Patrik,
Marco wrote in November to me:
So I assume you @patrik_gfeller could take over as well.
It would be nice to have an official binding - without the hostname/IP bug.
I also chatted with AndrewFG (maintainer Hue Binding) and he confirmed that the APIs are different and I am not sure, if it makes sense to incluce it into the Hue binding. A separate SyncBox Binding would be ok (at least for me) 
I am looking forward for a binding 
I am pretty sure that it does NOT make sense to include it in the Hue binding.
1 Like
I am pretty sure it does make sense to include it to the binding. Most of the people (me included) are not that familiar with APIs and programming of binding. And since the official Hue App merged with the Official SyncBox app, for most of the people it is the same. Regardless of any APIs being different.
In the official app i can see my lights AND my SyncBox. So why shouldnt be this only ONE binding, instead of two?
And having someone making it official and being able to contribute further to the binding (which is not happening with this one in here) is probably a big benefit for the community. (Which is already asking on github)
Because they are referring to two different physical devices, with different network IP addresses, one on WiFi and one on Ethernet, different communication APIs, different discovery mechanisms, different thing and channel structures, different authentication etc. So the code will be 100% non congruent. And therefore it is essentially a different binding. Basically the only thing in common between the two is that they both have the word ‘Hue’ in their name. Of course if the author wanted to be perverse they could artificially package both bindings in the same jar. But that would make maintenance 4x more difficult. Keeping the code base separate is the most logical approach. Of course the whole point of OH is that you can display things and channels from multiple bindings in a common user interface. So really I don’t understand your issue.
2 Likes
Hi & thank you for your feedback ,
first when I had a look into this I also thought that the device should be supported by the Hue-Binding; but form a technical standpoint (as elaborated by @AndrewFG) this does not make sense. But for the OH user I do not see a major disadvantage - yes, you need to install another binding - but the box will be discovered automatically & the registration process you have to do either way. Once this is done you have your things and stuff as usual. You do not need to take care about the technical API stuff in the background. The official app probably does the same thing. In the end the OH UI is the application - and there it will be integrated seamlessly. That’s up to you and your configuration (yes - OH is a bit more demanding in that regards, but also more flexible than other solutions).
Another valid concern - it should be easy to contribute; but the Hue binding is already quite complex (as it supports different API versions and thing types). The Sync-Box binding on the other hand will be quite simple in comparison; and it should be easier for others to fix potential bugs and to add features without risking side effects.
As you said you do not care much about code - but just comparing the amount of code you’ll see that this is quite obvious:
In my opinion proper documentation on how to use a binding and for what is important to make it user friendly. Documentation is not my strong point - but this is a place where you can contribute without coding knowledge to fill the gaps if you think the things are too complicated. A good documentation will help to avoid frustration …
That said - we aim to make the things user friendly and maintainable; but here it is easier for implementation, maintenance - and with proper documentation, also for the users if we use two bindings.
If you own a sync box and you are interested to help testing and/or to write the readme or other documentation to help to improve the experience please contact me (e.g. PM).
1 Like
… as I’m currently working on the port to of the hue-sync binding to the official repo. I do not just copy the code - but change it to my taste (the code review will show if I have a good one 
). You mention a bug in the current implementation. Do you have some details for me - so that I can make sure I do not make the same mistake - thanks.
Hi Patrik,
sure - as described above the bug is:
after restart of openHAB the IP adress got overwritten by Hostname, which cannot be resolved or found in (my) network.
When I change hostname to the IP of the Syncbox it wil be found immediately and it is working again.
As a workaround I changed my config from GUI based thing-config to textual config - I never ran into this problem again. But when using the GUI-based thing-config you need to change the hostname to IP after every OH reboot.
Best, Kai
let me know when you are ready to review it …
Thanks … I had a bit problems with the re-base, as I was working on 4.1.x branch - so not sure if the code still runs - will check that next (took me longer than expected to learn how to re-base properly).
PR: [huesync][WIP] Hue Play HDMI Sync Box Binding - Initial contribution #16516
Hi @April_Wexler (Kai) and other Hue Sync Owners,
I’ve finished the infrastructure of the refactored binding. It should support device discovery via mDNS, registration - and unregistration on removal.
There are no channels yet - so no interaction is possible; but it would be interesting to know if the discovery and connection check works on other systems as well (without the hostname/IP problem). If the communication works reliably, then I know the implementation handles the API (discovery, dto serialization … etc) properly. I’ve invested a bit more into the infrastructure to be able to implement things/channels effectively and to provide a code base that should be easy to maintain in case someone else needs to follow up.
The binding should work with a 4.1.2 system (that’s what I use to develop/debug). I use a docker container for those tests (no risk for the productive system and available on my laptop - no need to connect to the real server). Below the config files if someone is interested in such a setup:
.env
COMPOSE_PROJECT_NAME=openhab-development
USER_ID=9001 # openhab
GROUP_ID=9001 # openhab
MOUNT=/home/user/Temp/openhab
VERSION=4.1.2-debian
#VERSION=snapshot-debian
TZ=Europe/Berlin
docker-compose.yaml
services:
openhab:
# https://hub.docker.com/r/openhab/openhab/tags
container_name: ${COMPOSE_PROJECT_NAME}-server
image: openhab/openhab:${VERSION}
restart: unless-stopped
network_mode: host
volumes:
- /etc/localtime:/etc/localtime
- /etc/timezone:/etc/timezone
- $MOUNT/addons:/openhab/addons
- $MOUNT/conf:/openhab/conf
- $MOUNT/userdata:/openhab/userdata
environment:
- CRYPTO_POLICY=unlimited
- KARAF_DEBUG=true
Just copy the .jar into the addons folder. The container will not work on a system where openHAB is already running - because the port(s) are already in use …
Download is available from JFrog
Log can be enabled using the UI, or the config file:
<Logger level="TRACE" name="org.openhab.binding.huesync"/>
<Logger level="WARN" name="org.openhab.binding.huesync.internal.discovery"/>
<Logger level="WARN" name="org.openhab.binding.huesync.internal.factory"/>
Request for help to all potential users:
I’ll continue with the implementation/port (if no problems are reported back regarding the basic infrastructure I’ll start to implement the things & channels). But to be able to merge the binding once the code is ready the README needs to explain its configuration using files only. As I’m using the UI exclusively help in that area would be highly appreciated (unless the merge is accepted without the textual config description).
Feedback and review of the code base is also appreciated - as I’m not using Java regularly there might be more elegant ways to solve some of the things.
with kind regards,
Patrik