fyi: binding runs like charme. did you decided on the repo?
Since youāre interested in contributing too, I created the repo: https://github.com/bbrouwer/openhab2-dreamscreen
I do think auto-discovery would be a good thing to do, and Iām guessing entirely doable. I just hadnāt gotten around to it yet.
Now that youāve used it for a little while, what do you think would be the next thing should be to get working?
I created a pull request. This includes my edits to allow the Maven build run through (mvn install). I also added the jar under target so people could download the jar and donāt need to build it themself.
I could have a look to the auto-discovery, but no insights to the protocol yet.
Do you know how the App discovers the DS units? UPnP etc. or do we need to scan the local ip net for a specific port?
After some testing of the current build we could put the binding on the market place to find more people willable to test. What do you think?
Iām working on some changes in this. The version you have keeps scanning the network every 10 seconds or so to make sure any changes to the DreamScreen are reflected in the OpenHAB state. Iāve determined that I can instead respond to other external commands, such as from your Android device by listening to those commands to know how the state should be changing.
The Dreamscreen devices are controlled in groups. You donāt actually send a command to a single device, so if you had the sidekicks, for example, they are controlled as part of the group with the DreamScreen 4K.
Also, I was identifying the DreamScreen by its name, not its IP address. But if I have 2 DreamScreens in my home, or 2 sidekicks, they would have the same name as each other. So I think it is going to be better to identify them by IP address instead. This means that the auto-discovery is going to be more important.
Auto-discovery should be easy to accomplish from the network protocol side. Itās actually the same method Iām using right now to discover the DreamScreen device by name. One UDP broadcast asks all DreamScreen devices to identify themselves. What I need to figure out is the OpenHAB side of the API.
Iāll be working on this for a few more evenings and then Iāll explore the marketplace. I see that I donāt really have any OpenHAB references in the code, so putting it in the Eclipse IoT Marketplace would be fine. Should I then remove the āopenhabā from the package naming and repository name?
I could add the discovery service and you attch the network part. If you point me to the processjng of the discovery responses I could add the thing creation there.
There is a category in the Eclipse IoT market place, do not change the binding name. You could supply a download link into your repo and it will be shown in PaperUI
If you look in DreamScreenDatagramServer, there is a requestRefresh method. This would be the first step and basically asks all DS devices to identify themselves. In the same file youāll see the refreshDreamScreen function which is called once for each DS device that responds. That gets you all the information you would need. Iām sure some refactoring will have to be done to handle the auto-discovery as that method is currently designed to only update each DreamScreenHandler.
Iāve also gotten some good information from the DS team that might make it so I can get rid of the network polling. Iāll be working on that soon. My new changes might make it a pain to merge your changes in with mine, but such is life.
If this you make significant changes to the code structure Iāll wait. Otherwise the discovery service will be a seperated class and then kind of hook into the above functions.
any update?
Iām still working on it. I decided to figure out the auto-discover piece, too. Iāve been struggling with getting the updates to the OpenHAB state to work on startup, though. Also, I discovered that the right approach is to use a bridge, rather than my DreamScreenServer class. Iām moving things around a bit to follow that practice. In some ways it is better. Give me a few more days to get this back to working.
I see the bridge approach if the Sidekicks are controlled by the DS device. If all devices are independent there is no need for a bridge.
Well, the bridge approach didnāt work. But after a ton of work, this thing might be working pretty well. Youāll need to delete the old DreamScreen thing from OpenHAB as I switched the ID mechanism to the deviceās serial number. Finding it is really only possible with the auto-discovery now.
I incorporated most of the changes from your PR, but as I made so many changes, your PR may as well be deleted now.
Give it a try and tell me what you think: https://github.com/bbrouwer/openhab2-dreamscreen/releases/tag/2.4.0-beta.0
try to test at the weekend
If you happened to have already downloaded the .jar file, youāll need to download an updated version. The previous one was compiled to Java 10 bytecode. This one is Java 8.
works in general
- device gets discoverd
- power on/off is fine
- but Iām no longer ablento change the channrl
Iām very sorry about that. It was a silly oversight. I made this new release 2.4.0-beta.1
It also includes some enhancements to force delays between messages. I started putting this into some rules and some of the messages were being lost by the DreamScreen. I havenāt finished testing that out, but I thought you would want the fix for the Input message first.
I improved the delays so typically this binding waits for a response before sending the next command. This has made my rules more reliable as it seems to take longer to get a response for an input switch than from other commands.
You can download my latest 2.4.0-beta.2
What channels are you using in this binding? Is it just power, mode and input?
Iām curious on what your thoughts would be for how some of the other channels are handled. Typically when I send messages for the other channels, (e.g. Scene or Color), this causes the DreamScreen to turn on. I do try to make sure that state is represented in the corresponding channels. But Iām wondering if you think it should be handled differently. If the Power channel is off, should I just ignore sending those commands until the power channel is turned on? If I did that, then those changes would not be reflected in other places such as the Android or iOS app.
I use Power, Input, Mode. I also bound Color, nut not Scene. I think the current handling is ok, if the other settings are preserved. Itās more comfy for the user rather than āhmm, doesnāt work, oh itās still off, so power on and redo the scene selectionā. Iāll test the new version tonight.