I want to check the interest for a DreemScreen TV binding. This is a ambilight solution comparable to Hyperion, but easier to install and already supports 4k. I got in contact with the manufacturer and they already provided some doc.
Does anyone already have a DreamScreeen TV? What’s your experience? What functions do you like to see?
I’m curious why you are withdrawing this post? Just this weekend I decided it would be a good learning experience to write a binding for my DreamScreen 4K and I have the basics working
Spoke with the DS and they came back:
“We would be willing to answer any questions you may have. That java library does seem to implement most of the control functions you would need like setting mode, brightness, and ambient colors https://github.com/rkkoszewski/DSComEmu/blob/master/dsce/src/main/java/com/robertkoszewski/dsce/client/devices/DSDevice.java#L210”
I am currently trying to control my DreamScreen 4k. Turns out i am having trouble sending the UDP requests. Openhab does not complain - but my dreamscreen does not care about my udp requests either 
Can you give some insights on how you do it?
you should utilize their support, they came back is a readonable time and are opten to answer questions (see above)
Did you looked at the Java library the referred? Maybe it makes sens to work together with that guy
I’m slowly working on this, but have a bunch of features working. So far, I’m not using that library from rkkoszewski, though. While it does look well written, I already had good chunks working, and is better prepared for event notification (e.g. receiving color updates from the DS)
I ran into trouble getting the UDP messages to work as well. One day all is working, the next day: nothing. “WHAT? I didn’t change the code, what’s wrong?” I thought. It turns out that I installed Docker for a different project. The default constructor of the DatagramSocket binds to the first NIC reported by Windows, which happened to be the virtual NIC installed by Docker. Because DockerNAT installed on a 10.* address while my home network is 192.168.1.*, the UDP messages were never routed from 10.* to 192.*. Reordering the priority of the NICs in Windows fixed my issue. Alternatively, you can provide a different bind address in the constructor.
I am looking for opinions, too. DreamScreen doesn’t have a traditional On/Off setting. It simply has different modes: Sleep, TV, Music and Ambient. I figured it made more sense in OpenHab to have a traditional On/Off setting. That means the “mode”, should I make such a concept in the OpenHAB binding, would need to be remembered. And if I’m going this far, why not drop the “ambient” mode and expand that out to include each of the different ambient modes, giving me a list of modes like this;
What are your thoughts? I’m pretty new to OpenHAB, so pointers are welcome.
with regards to network interface selection: OH offers the selection of the primary network interface under PaperUI->Configuration->System->Network Settings. The binding could use the NetworkAddressService class to read this value (grep the other projects to get samples).
Yes, I know the ON/OFF problem - same with my binding. However, I don’t think that some kind of persistent ON/OFF value is a good idea. If the user uses a remote etc. to change power the binding will be out-of-sync. If you want to go that way you could use the OH persistence feature to store/restore an item representing the power state. Maybe you could use PING or ARP to check if the DS is running and Wake-on-LAN to wake it up. AFAIK you could connect the DS with your TV using a USB cable. The DS then stays in sync with the TV: TV off->DS off and vice versa.
ambient mode: Don’t add too many selections or at least have the simple ones
Hi, any update?
Development is going to halt until closer to Christmas time. My family makes an annual Christmas video, and if you think that sounds easy and shouldn’t take much time, check this out: https://www.youtube.com/watch?v=kEZMhkI0Wd8&list=PL2f8gRG8FKtIglcsU_Gi1AJVjuTYzjLFk
However, some of the basics do work. I can turn the DS on and off, change inputs and change at modes between music/video/ambient modes. It is certainly not finished, but feel free to try it out: https://github.com/bbrouwer/openhab2-addons/tree/dreamscreen
To add it, you just need to specify the name of the DreamScreen device. It uses UDP to find the device’s IP address on its own. This is where I had trouble for a while, but I think the code now uses the primary IP address that can be configured in OpenHAB.
I’ve only been testing it through Eclipse so far, so I haven’t created a binary or anything. I’ve never done that for OpenHAB before. I’ve done some OSGI stuff in the past, but it’s a long time ago. Maven and Eclipse I’m pretty good with, though.
Feel free to develop it further. I’d be interested in seeing any changes you would suggest.
you could build a jar as follows
mvn install
this produdes a jar in the target sub directory.
You could ignore formatting errors when running
mvn -DskipCheks=true install
I also added the target/…jar to the repo. This makes it easy to include a link here rather than uploading the binary.
I’ll order my DS 4k from the US (I’m living in Germany) and will be there beginning of December. Then I could join the testing.
I’ll send you some code, which does the local interface detection if someone couldn’t use the settings from openHAB. This is really stupid, because the JVM behaves different on various platforms (e.g. Debian/Raspian vs. macOS vs. Synology - stupid for a multi platform framework).
Is there anything other I could help at the moment?
fyi: DreamScreen 4K is on sales this week with a 20% discount
Sale this week: 25% + free international shipping, use code CYBERSECRET
so I ordered mine and will be ready to test 
@bbrouwer Got my DS 4K. Is the repo up to dater do you have more changes, which are not yet committed,
The repo is the latest that I have available.
Got my DreamScreen the last days. I was already looking for some projects and found the same resource in GitHub which ist mentioned above. Besides the feature to control the DreamScreen like from their app, this GitHub package contains an emulator for a Sidekick. This is what I was looking for, a chance to controll some RGB lights based in the colors provided by DreamScreen. So I would add a way to configue a number of virtual Sidekicks. These virtual Sidekicks are then own Channels. The colors given to these channels then could be used to control the colors of some lights. So something similar like Hue Sync.
I got my DS 4k. Could you please provide a jar (mvn install).
I’m not so happy with forking the complete openhab2-addons folder. This create a lot of overhead and prohibits to fork 2 or more different projects, because they all have the same root folder. I do the following
Saves a lot of overhead and keeps the project small.
In addition I check in the target/…jar so other users could download the compiled version rather than the need to build on their own (which could led into setting up the dev environment the first time)
Your concerns about forking the whole openhab2-addons folder seem to be about a design choice that the openhab team made. I don’t disagree that it would be nice to have a repo per addon, but if this is the approach the openhab team wants to take, I think I’ll live with the overhead. Merging shouldn’t be a big issue since there will never be any file conflicts. If, however, you want to work on this with me, I would consider doing as you suggested.
As for the .jar file, I created a release in my fork where you can download the compiled org.openhab.binding.dreamscreen-2.4.0-SNAPSHOT.jar
I have no idea if it really works on its own. So far, I’ve only been testing in debug mode on my machine.
yesterday evening I already integrated your binding in my codebase and did a compile. However, I need to make a few minor changes to get a “mvn install” working. I used my build for a quck test (copying the jar to the addons folder on my Pi) and it WORKED - I was able to turn on/off - no further tests made.
Do you plan to seperate the repo so I could create a Pull Request?
I noted that I had to add the thing manually. Do you plan to implement auto-discovery?
did some more testing - so far everything looks good
I just changed some debugging (using logger.debug rather logger.info) to avoid messing up the oh log
good job 