Just wanted to say, the new connect app is awesome!
Thank you for that! Makes managing the apps I actually use way way easier!
THANK YOU.
Yeah, I thought so too. I don't write this stuff for myself. I have three Roku devices, but I only use them for on/off controls via Alexa. I write this stuff in hopes that people like you will enjoy it, and can sole your unique use cases. The app is not done yet, but I felt it was time to release what I had since I too felt it made managing the system substantially better too.
1 Like
Very cool! Thanks for all the work you have put into this. It's mind blowing to a guy like me. I do CyberSecurity professionally, and as such, I rarely, but sometime do a little programming from time to time. I am skilled enough to hurt myself is about it. You guys that can crank out this level of work are true artist.
Thanks for making my life better, man!
The ON/OFF capability is perfect for what I need. I just need to make sure the kids don't leave the thing on all the time. Also want to put it on a timer which should be no problem with the on/off switch.
Thanks again!
Please have this added to the Hubitat package manager app.
It will give you a lot more exposure.
1 Like
I am not familiar with that. What is the package manager app?
It's a community app which automates installation and updating of community apps and drivers:
[BETA] Hubitat Package Manager.
2 Likes
I shall get it done. Thanks!
3 Likes
Thanks for the 411. It is now added.
3 Likes
hey @armand -
I'm now seeing ROKU events in my "system events" panel in HE.
I don't recall having see these before.
Any idea if I can do anything to reduce/remove those?
These are related to auto discovery protocol. I will see if I can determine what the trigger is for this logging. It happens behind the scenes as part of HE logging. There is not explicit code for this in my app, but my app does use SSDP to auto discover the roku devices.
I have confirmed, these are just SSDP messages that the hub is receiving and logging. It is not related to my driver specifically. When the Roku:ecp value is received, it it forwarded to my Roku integration app, but if you get a Hue Hub, Chrome Cast, or a number of other SSDP enabled devices, when the hub receives those solicitation responses for auto-discovery, they are being logged. I have about 10 different types coming in, on my logs, but I have a lot of SSDP enabled devices.
1 Like
Got it, thank you
I'm just now trying out. I see that it adds the "buttons" such as back, left, right, up, down, etc, as "switches" inside Hubitat.
Wouldn't it make more sense for these to be "buttons" inside Hubitat? The "left" button on the remote cannot be in an "on" state, for example. It's simply "pushed".
I'm trying to build my own Roku remote by adding all the buttons to a dashboard. (I can't use the app for reasons I won't go into) and I find when using a "switch" in the dashboard it wants to update the status of the switch from "off" anytime it's pressed. Of course this status never changes so it just gets stuck at "Sending..." which basically means I can only push any button once and then it stops responding.
Is there an easier way to accomplish this?
Wouldn't it make more sense for these to be "buttons" inside Hubitat? The "left" button on the remote cannot be in an "on" state, for example. It's simply "pushed".
Yes, it would be better, and I initially created them as buttons, because there is no state for a button. However, buttons do not work with Alexa, so the normal practice with Hubitat, to create buttons that need to be available to Alexa, is to create them as Momentary Switches. They turn on, then after 250ms they turn back off.
As for the switches not turning back off, what are you using for your remote interface? I will look to see if there was a bug introduced for the button device while I wait for a response.
[update]: I just confirmed that the buttons do work still. If I press the volume up button, my volume goes up. I also confirmed that the button is not longer a momentary switch. Apparently (I had forgotten about this) when I converted to using generic habitat component switches, I removed the momentary nature of the switch. It stays always in the off position. But the request to turn the switch on does perform an action in the parent device. Unfortunately, this means you cannot write rules that are tied to the button presses, which actually makes sense, since I cannot detect a button press from the physical remote control either.
Notice that that app is not a remote control, it is a setup convenience used to discover your rokus, and set them up for you. When the app is used to manage the Rokus, the Roku TV becomes a component of the app, and some of the settings may only be managed through the app. It is entirely your choice if you want to manually manage the Rokus or use the app to manage them.
2 Likes
What I did was create "child devices" through the UI for each button on the remote, up, down, left right, etc.
I then created a dashboard using Hubitat Dashboard using these buttons. But because they are "switches" I cannot use the "Button" tile in the dashboard, I have to use the "Switch" tile which doesn't work properly. Here's a screenshot:
Before I took this screenshot I tapped on some of the switch buttons. Notice how it says "Sending..." under the up, down, left and right buttons? I was able to use each button once (And that one press did get sent to the Roku) but then the button is frozen while it waits for the state to update. I've waited several minutes and they are still stuck at "Sending..."
Would it be possible to simply add:
capability "PushableButton"
To your child drivers? There's no reason they cannot offer both switch and button capabilities right?
I took a look to see if I could add it myself, but I've never worked on a driver where the same driver code was used for both parent and child devices so I'm not really sure how to do it.
Thanks,
-Jeremy
I
I do not have a custom child driver. The child driver uses the generic hubitat switch driver. The problem seems to be that the dashboard wants confirmation the on operation completed. This should be easy to address. I will take a look now that I know you are using hubitat dashboards.
Ohh, that explains why I couldn't find the part of the code that handled the "children" events. That makes much more sense now.
What about an option to simply create the children as "button" virtual devices instead of "switch"?
It would be ideal to have the option to use the "Button" tile in the Dashboard instead of the "Switch". Even if you made the code send a switch status update, the dashboard tile would still pause for a duration which would make it difficult to navigate menus using the remote because you have to press "Right" (Wait), "Right" (wait), "Down" (wait) etc.
Does that make sense?
Thanks again,
-Jeremy
I will see about allowing you to create it either way. Originally I created this as buttons, but buttons are event generators, not actuators, so there is no way to sending button push to the button controllers, therefore they were not commendable via a GUI for a while. And today, Alexa cannot control button devices. This is why I changed to a switch. We now have some controls over button devices, so I can see about putting the option to make either buttons or switches for the keypresses. Until then, I fixed the switch so it is momentary. Give me some time to get the change checked in, and deployed.
I will work on adding the option to create buttons but for now, I have confirmed the current logic works in the dashboards now. Let me know what you think.
It works! It's a bit weird waiting for the dashboard button to turn yellow and back to gray again, but it's fast enough to be usable.
Thanks so much for fixing!
-Jeremy
