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
I tested it and you don’t have to wait. You can queue up a couple button presses. I am working in the button format today.
I've been using it all day, it doesn't seem to queue up for me. If I hit the buttons too fast it definitely loses some of the keystrokes. But it's definitely usable, I've been using this dashboard in place of my actual roku remote listening to music today.
The big reason I wanted this in a dashboard is because I have to control my volume through my Denon AVR. I had to modify the HTTP driver by Scott Ellis to allow me to control my Zone 2 volume since the built in AVR driver can't control zone 2.
So now I can adjust my speaker volume and control my roku from a single dashboard, which is great!
-Jeremy
It does not queue up a lot, but you can press the volume up one or two time while the tile is still yellow, an occasionally some of the extra presses get dropped — on my system. I was merely pointing out a quirk if the system, not a feature of my driver. Still, I will likely get the button device option created later today. I have some plumbing repairs to do in my home, and a lot of other things related. But this will be a nice escape from home repairs.
Would it be possible to disable the "The device appears to be powered off. Please make sure Fast-Start is enabled on your Roku" messages? When no one is home, I power off almost everything, which causes that message to get printed on every attempted refresh.
Done. I moved the message to inside the log enable logic so it will only display if logging is enabled.
Update is now available in HPM and direct import.
Thanks!
The log message is still getting printed out from two functions: getInstalledApps and queryCurrentApp.
Thanks. I did not realize I had several duplicate log entries -- not my coding style, so I didn't search for it. I consolidated them to a central log function, there were several instances) and I also added a user customizable timeout for the API calls, so that wired Rokus can timeout aggressively, and slower wireless models can timeout after a longer delay. I also noticed that something changed the behavior of roku players being able to control power/volume on the TV. If I can work around it, I will post another update, hopefully, my HDMI cable is just faulty.
Anyways, please try the update.
I installed the Driver, no problem. Works great when I connect wirelessly. I want to run my Roku on my wired network. I have a Roku ultra hardwired to my network on a 10.xxx address. My Hub is in 192.xxx and it cannot find my Roku. I know this is a network issue and not a driver issue. Any help out there? I have an ATT router and a Velop mesh network.
Thanks,
I can help. Network address cannot simply be assigned arbitrarily. The simple answer for this thread is to move the Roku to the 192.x.x.x subnet, unless it needs to be on a different subnet, in which case, you will need to create a route on your router so that it know there is a 192.x.x.x and a 10.x.x.x network on the LAN side. And this means every attempt for any system on one network to access the systems on the other network, will have to pass through the router (this is why it is called a router -- it routes traffic between different networks).
Direct Message me, and I can provide you with specific one-on-one assistance for your network without cluttering the thread. I am a network professional, so I know what I am doing. (I only started coding professionally about 10 years ago, although I have been programming for 40 years now -- just not as my primary form of income)
