[Edge drivers] Issue with the logcat and driver installation

I’m trying to listen to logs using the CLI and I get the below warning. Is this an issue? Logs don’t seem to show:


Thanks!

When the CLI prompted you with “Are you sure…” did you type “y” to accept the connection?
Are you using the latest CLI version?
“Listening for logs” indicates it should be connected correctly, and the logs start to show when there’s an activity in the selected driver. For example, when you install a compatible device to it.

You can get the logs of all the drivers installed by adding the --all flag at the end of the command, for example:

smartthings edge:drivers:logcat --hub-address=192.168.1.11 --all

This is what I see with the latest CLI:

Now I’m seeing:


I was hoping to see info regarding the Roku Driver.

The timeout error can be because the connection isn’t stable…it’s strange that it showed you some logs and then timed out. I’ll check with the team if there can be another reason for that error.

Have you installed the device? I don’t know exactly how that custom driver works, but to see logs from the driver in the logcat, you need to:

  1. Install the device that will be controlled by the driver.
  • For the drivers that create virtual devices, you just need to select “scan nearby” in the app, but the author should include instructions on how to install his/her driver.
  • If there’s no device controlled by that driver, it won’t appear in the logcat.
  1. Receive events, for example, if the device is turned on or off.
  • There are some periodical events, for example, to check the device’s health but that’s mostly for Zigbee and Z-Wave devices

This driver ([ST Edge] Roku Driver - #30 by TAustin) is supposed to show my Roku devices on my network. I have a few roku TVs I would love to control. It isn’t and I’m trying to figure out why.

You won’t see any driver activity unless (1) you have Roku devices that are being monitored (which you don’t yet), or (2) there is a discovery process running. If your logging doesn’t time out(!), then try initiating an Add device / Scan for nearby devices and watch the log. You should see activity then and hopefully some clues why it’s not discovering any devices. It’s possible this hardware is working differently and, for example, using the multicast address is not functioning properly.

I have Roku devices. So the process should be:
1 - Start the logging process (hopefully no time out)
2 - Press the Add device / Scan for nearby devices
?

I’m not sure what you meant when you wrote “I have Roku devices” ?? Do you mean you HAVE now gotten them discovered and you got them created in SmartThings?

Assuming you have not gotten your devices discovered yet, start logging and then do the Add device / Scan for nearby devices. You should soon see a bunch of activity from the log showing the driver doing a multicast search for your devices and showing messages for anything that is responding on your LAN. It will be much easier to see things if you are logging for just the one driver rather than all drivers.

Got it. I’ll try later. I thought you referring to physical devices ;).

I tried many times to get the roku logs and I keep on getting a timed out error. I was able to start the log and immediately run the scan to get the below logs before it timed out. Do we know what can be causing it?

Thanks!
‘’’
2022-07-22T00:37:31.935584125+00:00 TRACE Roku Driver v0.1b Setup driver rokuDriver with lifecycle handlers:
DeviceLifecycleDispatcher: rokuDriver
default_handlers:
init:
added:
deleted:
infoChanged:
doConfigure:
driverSwitched:
removed:
child_dispatchers:

2022-07-22T00:37:31.940785735+00:00 TRACE Roku Driver v0.1b Setup driver rokuDriver with Capability handlers:
CapabilityCommandDispatcher: rokuDriver
default_handlers:
tV:
volumeUp
channelUp
channelDown
volumeDown
partyvoice23922.rokukeys:
selectKey
mediaPlayback:
rewind
fastForward
pause
setPlaybackStatus
play
stop
partyvoice23922.rokutvkeys:
selectTVKey
mediaPresets:
playPreset
partyvoice23922.rokupower:
setPower
powerOff
powerOn
child_dispatchers:

2022-07-22T00:37:31.945059011+00:00 INFO Roku Driver v0.1b Starting Roku Driver v0.4
2022-07-22T00:37:31.959064091+00:00 TRACE Roku Driver v0.1b Received event with handler environment_info
2022-07-22T00:37:31.964747660+00:00 TRACE Roku Driver v0.1b Received event with handler environment_info
2022-07-22T00:37:31.969006915+00:00 DEBUG Roku Driver v0.1b Z-Wave hub node ID environment changed.
2022-07-22T00:37:31.975247861+00:00 TRACE Roku Driver v0.1b Received event with handler discovery
2022-07-22T00:37:31.987252354+00:00 DEBUG Roku Driver v0.1b Making discovery request #1; for target: roku:ecp
2022-07-22T00:37:31.991204609+00:00 DEBUG Roku Driver v0.1b [upnp] Discovery parms: nonstrict=true, reset=true
2022-07-22T00:37:35.515546855+00:00 INFO Roku Driver v0.1b [upnp] Discovery response window ended for roku:ecp, 0 new devices found
2022-07-22T00:37:37.525790917+00:00 DEBUG Roku Driver v0.1b Making discovery request #2; for target: roku:ecp
2022-07-22T00:37:37.529610713+00:00 DEBUG Roku Driver v0.1b [upnp] Discovery parms: nonstrict=true, reset=false
» Error: timed out
‘’’

Can you let us know which CLI version are you using, please?

Execute the command: smartthings --version

In the latest versions, the time-out value was increased

@smartthings/cli/1.0.0-beta.11 win32-x64 node-v16.16.0

@nayelyz ,

I think @dotan_shai has observed the same issue.
Couple of lines of log messages, then connection timeout.

@dotan_shai could you please remind which cli version we were using?
Thanks

Hi @nayelyz ,

I think there is another report about cli logcat timeout.

Please see

Hi @nayelyz ,

Perhaps you would be interested to know that the previous cli version .10 does not seem to have the timeout issue.
Regards

This is indeed really useful for me. Thank you!
I’m using version 8, I’ll check if using the latest happens to me, my network is really spotty, so there’s a chance it does.

So, @Wajo357, please, download the version 10 of the CLI to see if this solves your issue as well.

2 Likes

Latest version:
1.0.0-beta.11

1 Like

Thank you, @ygerlovin, @dotan_shai, @Wajo357 for bringing this to our attention.
The internal team was able to reproduce the error and the latest CLI version (12) includes a fix for this issue, they will keep investigating the situation just in case there are other actions required.

4 Likes

I had the same error with version .11, and now it works fine with version .12 (Darwin-x64). Thanks!

2 Likes