Post by bb83 on Jan 5, 2019 23:34:23 GMT
I purchased a DreamScreen 4K a while ago and I'm experimenting with controlling it from OpenHAB. I have some of the basics working. You can see my code here: github.com/bbrouwer/openhab2-dreamscreen
But there are certain challenges I am wondering if you could help resolve. The first thing I'd like to see might be simple to accomplish with a Firmware update.
Whenever any kind of change in state occurs on the DS4K or Sidekick, could it send out a UDP broadcast with the new state? It can be the exact same payload that is sent when I request the current state from the device. This has a number of benefits. First, it acts as a confirmation that the DS4K did in fact receive the message, which could be important as UDP is not a guaranteed delivery protocol. Secondly, it would send notice to other devices, such as my OpenHAB plugin whenever a change occurs by some other means.
For example, because the DS4K can automatically change inputs based on CEC commands. It would be very useful to me to detect that input change in OpenHAB so that I can do something else, like maybe dim some lights. Actually, what I'm experiencing with CEC is that if the TV is off and on input #1, but a CEC power on command comes on input #2, the DS4K does in fact switch to input #2, but the TV does not turn on. If the DS4K was already on input #2, then the TV does turn on. My hacky solution is that I want to use OpenHAB to detect this input switch and turn on the TV since it is not working via the DS4K.
Currently to get around this problem, I have OpenHAB requesting the refreshed state every 5 seconds to detect this input changes, which really seems like a waste and may be abusing my DS4K.
Also, could you document the Ambient Mode Type field in the current state payload. If it exists, I can probably figure it out just by analyzing the payload, but it would be nice if that detail were documented.
The next is a question. Recently I've noticed the UDP message from my Android device being detected by my OpenHAB code. The only way I would expect that to occur is if the Android device is sending UDP broadcasts. Is this the intended way to control the DS4K? Should all my code use UDP broadcasts, or should I really use unicast as described in that PDF describing how to control the DS4K? And if unicast should be used, shouldn't the Android app do the same for most commands? Or is it really all about group control? So long as the group number matches, that's all that matters?
Finally, I've noticed that whenever I start the DS4K app on my Android device, it never knows what the current state of the DS4K is. I see a few UDP packets coming from my Android device, but I don't see any UDP broadcast messages coming from the DS4K replying with its current state. The 2 message I see coming from the Android device are not standard requests for the current state.
I would appreciate any assistance you could provide, and once this is working well, maybe you will find it useful for some of your other customers who happen to be using OpenHAB. I do enjoy my DS4K.
But there are certain challenges I am wondering if you could help resolve. The first thing I'd like to see might be simple to accomplish with a Firmware update.
Whenever any kind of change in state occurs on the DS4K or Sidekick, could it send out a UDP broadcast with the new state? It can be the exact same payload that is sent when I request the current state from the device. This has a number of benefits. First, it acts as a confirmation that the DS4K did in fact receive the message, which could be important as UDP is not a guaranteed delivery protocol. Secondly, it would send notice to other devices, such as my OpenHAB plugin whenever a change occurs by some other means.
For example, because the DS4K can automatically change inputs based on CEC commands. It would be very useful to me to detect that input change in OpenHAB so that I can do something else, like maybe dim some lights. Actually, what I'm experiencing with CEC is that if the TV is off and on input #1, but a CEC power on command comes on input #2, the DS4K does in fact switch to input #2, but the TV does not turn on. If the DS4K was already on input #2, then the TV does turn on. My hacky solution is that I want to use OpenHAB to detect this input switch and turn on the TV since it is not working via the DS4K.
Currently to get around this problem, I have OpenHAB requesting the refreshed state every 5 seconds to detect this input changes, which really seems like a waste and may be abusing my DS4K.
Also, could you document the Ambient Mode Type field in the current state payload. If it exists, I can probably figure it out just by analyzing the payload, but it would be nice if that detail were documented.
The next is a question. Recently I've noticed the UDP message from my Android device being detected by my OpenHAB code. The only way I would expect that to occur is if the Android device is sending UDP broadcasts. Is this the intended way to control the DS4K? Should all my code use UDP broadcasts, or should I really use unicast as described in that PDF describing how to control the DS4K? And if unicast should be used, shouldn't the Android app do the same for most commands? Or is it really all about group control? So long as the group number matches, that's all that matters?
Finally, I've noticed that whenever I start the DS4K app on my Android device, it never knows what the current state of the DS4K is. I see a few UDP packets coming from my Android device, but I don't see any UDP broadcast messages coming from the DS4K replying with its current state. The 2 message I see coming from the Android device are not standard requests for the current state.
I would appreciate any assistance you could provide, and once this is working well, maybe you will find it useful for some of your other customers who happen to be using OpenHAB. I do enjoy my DS4K.