My weekend project this weekend was the create a back end Python script that lets you command your DreamScreen Wifi using options. On my end, I'm going to be using a Raspberry Pi, FLIRC, and a Harmony remote (or Alexa + Harmony Hub) with it.
I can confirm, that chained commands should be spaced by atleast 10ms. This is because each packet needs to be received and processed before the next one is received. Interesting that you delay 2 seconds when setting Ambient Mode Type.
Suggestion for #color, maybe have the input parameter be represented as 3 byte rgb hex? Example -c 0xffff00 would set to yellow. Also don't forget to set Ambient Mode Type to 0 Ambient Static, as you are currently setting 1 Ambient Scene
So I was trying to limit the user's knowledge of the how the DS works, so some commands, like Ambient Scenes and Color, will send multiple commands for the single call. I probably should document that better.
The 2 seconds is pretty long, however a 1 second delay gave me a white screen and locked up my DS's ambient scene settings and I had to use my phone to get it working again. 2 seems to work generally. There has to be a better way, so that's why I'm still debugging it. What are you thoughts on that behavior? Also, the DS seems to be able to switch automatically to ambient scene mode sometimes without explicitly switching the mode (which is why i commented it out). Is the intended behavior switching mode, then ambient type, then ambient scene?
Yeah, I'm back and forth on color implementation concerning hex versus dec versus names. Dec is easier for python to parse and for people to understand, but its also more to type. Maybe I should just be able to switch between... And thanks for catching my incorrect payload in color. That's what I get for cutting and pasting old code .
4 further questions: - Is there an easy way to figure out what the DS IP address is? That took me a large chuck of Saturday...esp since it was before I got the CRC to work... - Is there a response that the DS sends? - Can I query the current state of the DS? I can see instances where knowing the current mode or color would great to have. - Is there a secure port to the outside world? I know you're working on Alexa skills programming, but IIRC, you kinda need that for it to work...
I just commented out the time.sleep(2) of #setScene and my DreamScreen is not 'locking up'; even >python DreamScreenCommander.py -a 0 -a 1 -a 2 works as expected. Can you reproduce the 'locking up' with the DreamScreen app?
You are correct DreamScreen will automatically switch to Ambient mode when setting an ambient scene, if ambient mode type is already smbient scene. The DreamScreen apps set Mode, then Ambient Type, and then ambient scene / ambient color, like how you suggested.
One (ugly) option to find DreamScreen's ip is to login into your router and check its client list, DreamScreen will be listed. Noone has requested it, but it would be trivial to display it in the DreamScreen app settings.
Depending upon the message context, DreamScreen may or may not respond to messages it receives. In simple terms, an example response to 'write Mode 3' is 'wrote Mode 3'. The way the apps perform discovery is sending 'read' UDP broadcasts out, and listening for all of the DreamScreens/SideKicks to respond; you could get the IP address in this manner. But to receive these responses, you would need to open a datagram socket (udp listener), and optionally parse the message when received. I have no sample code for python to offer but this should not be too difficult to implement. If wished, I can provide the required 'read' message.
At this time we have no plans to open the new 'Remote' api to 3rd parties. Quite frankly, I don't see any use case for controlling your DreamScreen remotely. The Remote api is the only secure way to communicate with DreamScreen outside of your LAN.
I'll try to reproduce the behavior if I get some time this weekend. I just didn't want to break it. Kinda like it.
I think it would be great to get the IP address of your Dreamscreen somewhere in the app. It took far to long to determine which address was the dreamscreen's
I understand and respect if you don't open up the Remote API, but I would strongly urge you do. It would allow developers to make hooks into cloud services like voice UI (Google Assistant and Alexa), smart home systems (wink and smart things), or integrations with lighting, scheduling, and control. Integration is survival, it is it sorely missing from the product.
I wrote the code for color, decimal method first, and I'll finish off the hex method soon. I'll upload it when I test it.
ggexe, Honestly, this "Weekend project" of Dreamscreen commander started on Friday to make an Alexa skill or Google Assistant action, but I couldn't think of a secure way to do it with the docs I had on the Dreamscreen device itself. Instead, I did the next best thing was to make the python script for a secured device that *could* make and receive local and remote triggers. That device could get the triggers and send the appropriate commands the the Dreamscreen.
The insecure alternative, until a remote API is released, is that you can open up a port directly to your router to port 8888 of your Dreamscreen's IP address. The Dreamscreen doesn't seem to use HTTPS, so people will tell you that it is a bad idea. Bad things can happen if you don't use HTTPS when communicating on the world wide web.
I tested it again, and you're correct that removing the delay can produce the desired results. It will be removed in my next push.
However, it seems that I'm getting some phantom errors in the Ambient modes when sending data that made it seem like the delay was needed. I just spend an hour and a half debugging the Color method, and the only thing that fixed it was switching back to scene mode, switching scenes there, and then trying again to change the color. This is similar to my experience with Ambient scenes.
I do now that in both cases, my initial payload had errors. I'm not sure if sending initially bad instructions messes with the Dreamscreen, so that when correct packets are sent for a particular function, it keeps giving errors.
I really do hope that you release the Remote API. I'd love to be able to write a Voice UI skill/action and a Pebble app (RIP pebble)
Google Assistant/Google Home integration is indeed coming. "Hey Google ask DreamScreen to switch to Video mode." In addition, Amazon Alexa and IFTTT integrations are coming as well. IFTTT is interesting in that you can create your own Applets e.g. "When I come home, switch DreamScreen to Video mode and turn TV on". By using the IFTTT-DreamScreen service for your own Applets, you are securely using the underlying 'Remote' api. Note there are additional functionalities I have not mentioned; but I will confirm SmartThings integration is not coming.
I hate to take the wind out of building your own Alexa skill. I suppose we could consider a webhook specifically for 3rd party applications, requiring https and proper OAuth 2.0 flow. But quite frankly this is of low priority as we are busy working on everything else.
Configuring port forwarding on your router to DreamScreen is highly unrecommended.
Sending DreamScreen an invalid message can cause framing errors, meaning subsequent message(s) will get discarded. Sending DreamScreen an invalid payload (e.g. set Mode 0xFF) should not cause any errors as there is input validation. If you don't mind, could you detail the exact state and steps required to reproduce the issue for me? If there is a bug I would be interested in getting it fixed.
I've got it right now hooked in through emulated_hue so that I can have my Harmony remote automatically switch between different input sources since I've got an HDMI splitter on one and then an Apple TV and some other things on the other sources.
Thanks for the work here guys Indeed, i got myself Home assistant and smarthings running right now If dreamscreen would be using IFTTT then i guess i can make use of the makers channel to trigger events
We recently released some documentation on device discovery and reading the current state of your DreamScreen. Device discovery is useful for applications that do not want to hardcode IP addresses; Current state is useful for applications with a gui.
Hey kyle , thanks for this update! Been incredibly busy and am way behind on a few projects, but when I get a moment, I'll love to play with this more, esepcially the autodiscovery. For the last month, I been "almost done" with an integration that doesn't "require" me to use dreamscreen independently, but allows me to seemlessly merge it into certain actions I already do. I'll post a video and many how-to when I am done.
auengun , great stuff man. I don't have a terrible amount of experience deving with the Hue or its emulators, but i'd love to talk with you about this HA service more openly or in PM :-D.
Hey jjensn , appreciate your feedback. Please do read the docs, as I did state in the readme that you SHOULD hardcode the IP address. Also, that "-i" option is an untested option if you happen to have more than one dreamscreen. Are you saying it doesn't work? Can you give me a behavior or error? Finally, if you think my 2 day coding effort is a mess, you're more than welcome to do a pull request and refactor it. Maybe you can show me how I can make it less messy. That's why I released the source code in the first place .
I'm just really glad that so much progress was made in getting this far into dreamscreen automation. Thanks again, av and kyle for getting us started!
Post by freibiergesicht on Feb 19, 2018 9:57:44 GMT
thanks for your excellent work.
I´ve added this script into my homebridge and it is running well as a homekit switch. One question: Is it possible with your script to read and give back the actual mode of the Dreamscreen? I´m using this homebridge plugin with your script: github.com/pponce/homebridge-script2