How has the DS binding been working for you? I’ve been finding that sometimes it doesn’t actually turn on the DS. I can see in the logs that I’m sending the command to turn on the DS, and I can see in the log the confirmation message from the DS that it did turn on, but it did not actually turn on. Have you experienced any flakiness like this?
I was looking through some of the rkkoszewski code. He has one interesting undocumented feature that I was wondering if you would find useful. It can detect when an input starts to receive a signal. I haven’t played around with it yet, but it could be used to detect when a device turns on. DS can auto switch inputs and I’ve found this to work fairly well when the device sends CEC commands, but one of my devices is a computer that doesn’t send CEC. It could be interesting to detect when I, for example, were to hit a key on the keyboard, causing the device to wake up, and then switch to that input and turn on the DS.
@leaxi, In my latest DS binding, it has some support for Sidekicks. As I don’t have any, I have no idea how well it works, but it sounds like they work basically the same way the main DS works.
The binding adds the sidekicks as separate things. From those things, you would have separate channels to control.
Are you looking to control some RGB lights that are not actual Sidekicks? I can certainly see from the DS api that that could be accomplished by subscribing to sector data. I just have no such feature yet in this DS binding. There are 12 sectors that are updated at some rate (30fps, 60fps?). If each sector were a channel, that would be adding 12 channels, each changing many times per second. Is that what you’re looking for? Does that even sound like a good idea in OpenHab to be changing color channels that rapidly?
Would this possibly be some configuration where you specify how many channels you want and which sectors belong to each channel. Then the binding could average the colors together and represent, for example, a left and right color channel?
@bbrouwer, yes I like to control the color of light connected to the Hue Bridge. I know it sounds strage to update the color multiple times per second, but I think when then refresh rate could be configue, we can test with a refresh rate of 5 per second, thus every 200ms a new color.
Most RGB lights change color with a short fading effect, so it makes no sense to update faster.
So probably the binding should not offer a channel for the virtual Sidekicks, but it should send a color command to the configured item. Whatever channel is behind will receice the command and trigger the update of the real light source. Wenn can also use a channel which Updates an Item and them react by a rule, but this would be a lot unnecessary overhead.
Maybe even a different kind of addon would be correct here. The only channel that we might want to control for the virtual sidekick, is whether it should be active or not, so that the related light may either get color command from the sidekick, or work in its usual behavior.
Updating an item rapidly (200ms) sounds strange and put a significant load on the OH system. I would also expect side effects with other bindings and event processing.
Nevertheless if you want to do that way you should make if configurable/disable. You may also look into trigger channels. There is no way to directly update an item, everything goes through a channel and one or more items are linked to that channel. You could also trigger OH rules with a channel, so an item could be omitted.
This actually would replace a one way python script with no way to read something from DreamScreen. What I got so far working with this binding is ON/OFF - much more reliable than before.
Thing was added via Paper UI. Which is ok - but is there any way to add this as in a thing file? Was not able to make that work.
My .items file:
Switch dsWzPower { channel=“dreamscreen:hd:4249159:power” }
Number dsWzInput { channel=“dreamscreen:hd:4249159:input” }
Number dsWzMode { channel=“dreamscreen:hd:4249159:mode” }
Number dsWzScene { channel=“dreamscreen:hd:4249159:scene” }
Color dsWzColor { channel=“dreamscreen:hd:4249159:color” }
Did you tried to link the channels in PaperUI and use PaperUI->Control?
Even if yoi want to have the textial configuration that chrcknis useful, because it shows if the binding is working. After that you could sneak in the jsonsb files and check the channel definitions.
Enable Debugging and check event.log (showing changes to the item states/values) vs openhab.log (showing the binding sebug messages).
I have an older version running (supporting auto discocery) and everything runs fine.
Is there any further planned development for this binding? I have a DS 4K and 2 Sidekicks. At any given time, only 2 devices can show online, and the third always shows Unknown status. I can restart the binding via the OH2 shell and watch it seem to arbitrarily select which 2 DS devices show online.
Usually Unknown Device means that a device was added by the discovery, but OH can‘t the thing definition (device type). Try to power off one of the devices (one going online), delete all devices and re-run the discovery. I still one is unknown it‘s clear that this is the problem.
Anyways if the problem persists it requires a code change. @bbrouwer
This may be the issue, it appears as though the last item you add or that the binding adds at works briefly after initial discovery then goes to an Unknown status. Let me know what you’d like me to be doing when getting TRACE logs and I will do so, @bbrouwer
It has been a while since I’ve looked at this binding. I can certainly believe there are problems as I’ve never tested it with multiple devices. I only have the DS 4K. The rest of the code is based off from documentation.
What I use this binding for is responding to my Harmony remote to switch the input and turn the DS 4K on and off.
@zomed, I also added it through the Paper UI. I haven’t tried adding it via a .things file. If you look at the channel names, the number you see is the serial number of your device. You might be able to add it with something like this:
I have some rules setup with mine that look like this (you’ll have to change the IDs to match what you have (e.g. dreamscreen_hd_4249159:
rule "Basement Watch TV"
when
Item harmonyhub_hub_BasementHarmonyHub_currentActivity changed to "Watch TV"
then
sendCommand(dreamscreen_4k_8872823_mode, 0)
sendCommand(dreamscreen_4k_8872823_input, 1)
sendCommand(dreamscreen_4k_8872823_power, ON)
end
@nolan_garrett, I don’t have current plans to enhance this further as it is working fine for my single device setup. However, I’d be willing to help out however I can. It would be cool to get some sidekicks, but it doesn’t even look like you can buy them right now, at least not in the USA. Do you see all devices show up in the Things page of the PaperUI and do they all have different numbers showing for each?
Thank you! Device discovery works great. It can see all three devices, I can add them, and sometimes for a brief window all 3 show online and are even controllable. Then, after a short period, maybe 2-5 minutes, one and only one of the devices will show offline in Paper UI. From that point forward, it is no longer controllable and won’t ever be again until I either delete ALL DS devices and re-add them or restart the binding (see below for what happens in that case). During this period, the device showing offline in OpenHAB is fully accessible and controllable via the DreamScreen app. If I restart the binding via the karaf console, 2 of 3 devices will show online, and it’s not always the same device that shows offline. All devices show unique device IDs, and again, they are all controllable for a brief window after the initial addition of the devices to OpenHAB.
At this point, I don’t have any good guesses as to what is going on. I will need to see some trace logs to see what might be going on. As for what to do while the trace is enabled? It would be nice to see things all working and then changing to not working.
Sorry for the delay. Some medical issues have cropped up for me which partially explains the wait.
I’ve been looking at your logs today. I would normally expect to see every “Sending ???” log message to be quickly followed by a corresponding “Received ???” log message. This seems to work during discovery, which is the only UDP broadcast. All other commands are sent directly to specific DS devices. After the initial discovery message, the code requests more details (a Refresh message) such as its name. The code identifies DS devices by their serial number, not IP address. Once you add the DS device in OpenHAB, I “link” the serial number to the IP address of the DS device. From the logs, it looks like everything I’ve described so far seems to work every time.
Once linked, the code then immediately requests refreshed information from the DS device. This is where I see the first evidence of something going wrong sometimes. Usually, I see in the logs the “Sending Refresh to x.x.x.x” quickly followed by “Received Refresh from x.x.x.x”. But not always. Sometimes, the “Received Refresh from x.x.x.x” never comes. Once there is a “Sending” message not followed up by a “Received” message, the logs show there is never again another “Received” message until you restart the binding and go through discovery again.
The only difference at this point is that there is rate-limiting code to make sure I don’t send a DS device packets too quickly. I’ve seen the UDP messages get lost if they are sent too quickly. So the code makes sure there is 200ms between each message to each individual DS device. But each DS device has its own separate rate limit.
When I watch my logs, I always see the “Sending” log entry followed by a “Received” log entry. Is my understanding of UDP wrong? When I send a UDP message to a particular IP address, does only that IP address receive the message, or do all IPs get the message and just discard it if the message is not for them?
Even if a message were lost here or there, sending another command should be delivered later. And I see those “Sending” messages in your logs. Those are only printed in the log if they are actually sent, and I see no error log showing that the send failed.
So ultimately, I don’t have a good explanation for why you are seeing what you are seeing.
In the last 3 or 4 weeks I had more than once that the binding looses control over the DS. The App still works, but the binding is not able to switch the input channels. I can’t say that anything has changed, e.g. a firmware update.
I have not made any updates. You should have the same version that I’ve been running without significant issues. If you restart OpenHAB, does the binding start working again? If not, does restarting the OpenHAB host clear it up?
I never put any logic to retry a command if it fails to receive a reply from the DS. That is the only thing I can think of that could possibly help. But that should only help for the occasional command that gets lost. I can’t see how it would explain the loss of all communication to the DS. I have not experienced this issue so it will be difficult for me to troubleshoot.
If you have it in a broken state and are able to debug the binding from Eclipse, that could provide me very useful information.
As I noticed the binding doesn’t run on 2.5.1-2. I did a rebuild on 2.5.2-SNAPSHOT and it looks good (U somehow messup the device discovery, but adding thing manual works)
How do we proceed? It would also make sense to get the binding into the review process becoming part of the official distribution. What do you think?
I don’t think it makes sense to put this into the official distribution. DreamScreen never really took off and the company behind it seems to be basically gone, particularly here in the USA. I do love my DreamScreen, but I just can’t see it still being alive and working in 5 years.
I’ve started playing around with Home Assistant which already has some basic support for DreamScreen, which was enough for what I need.
I made this project as a way to learn about making my own home automation stuff using a skill set that I am strong in. But honestly, I don’t have enough time to devote to this and so far Home Assistant seems to require less care and feeding. Maybe my opinion will change as I only started with it a month ago and haven’t experienced its warts. Or maybe I’ll be back to work on OpenHAB some day.
But feel free to fork the repo and make it yours. I won’t be taking down my repo, so there is no rush.
