SmartThings Community

Ryobi modular smart garage door opener

(Justin Dybedahl) #23

Yeah I need to do some more work on this as mine stopped working as well. I plan on doing some digging into the issues as soon as I have some time. Perhaps tomorrow while the wife is out with the kid. I’ll post a new version when I have something. Thanks for the post and glad it’s semi working for you. :grin:

(Justin Dybedahl) #24


My daughter decided to sleep long enough for me to get this figured out. The status was not working due to the Device Network Id value in the actual device properties in the IDE. This needs to be set to the IPofNodeJSHost:Port that is converted to hexidecimal. I’ve added some code to the device handler that will periodically set this automatically for you. Update the device handler and it should take care of that issue. The other issue was the _7 on the values for the battery, light, and door status. I figured not everyone would have an _7 in the name for these properties so I added some code to find the actual names your door uses and pulls those values. I’ve also turned off a lot of the debug messaging I had going to the ST logs. This should help clean things up in the logs.

Let me know how this works. Hopefully it helps.

(Projectskydroid) #25

Thanks for looking into it. I update the code on the server and device handler, but now I get noresponse from any of the commands in the app. They just toggle back and forth from on to off, or open to close etc, but no response from garage opener.

There’s no error messages being returned in the server console though.

I verified that your code did generate a new network ID like you discussed. I’m curious if this might be the issue. I verified the port is the correct hex for port 3042, but the IPofNodeJSHost section doesn’t look like any IP I’ve ever seen. What is this IP pulling from, my internal IP address where the proxy is running, or TwiConnect? Wondering if this might be the problem.

(Justin Dybedahl) #26

The ip address is the internal ip value you set in the device handler options that has been converted to hex. This should be the node proxy hosts ip. If you uncomment the console.log(request.url) line in the node code, does that them show requests going to the proxy? If not, I would check the internal ip value. Also, uncheck the log.debug lines in the parse section of the device handler code. Those might help in debugging if it’s a dth issue.

(Projectskydroid) #27

Ok. I see how it converts it, and that does show the internal IP for the server. I uncommented the console.log section though and it still isn’t displaying any requests.

(Justin Dybedahl) #28

Are you looking at the terminal output after starting the node proxy? It should show the URL output of the request when initiate some sort of command. Regardless of what the device network id is set to, it should send requests to the proxy. If you browse to the ip address and port of the node proxy in a browser, does it output anything in the browser?

(Projectskydroid) #29

Yep, I’m looking in the terminal window that the node proxy is running in. The only output is the initial “server is listening on 3042”.

I left it running for most of the morning while I was running around and the only additional messages that it displayed were a couple “favicon.ico” (not sure what that’s about". If I’m connected to the local network and try and send an open/close, or light on/off command, nothing shows up.

I also navigated to the proxy’s ip and port using chrome and was able to access a “site”. It just displays a single line of text reading “Not valid command!”, on the website.

(Justin Dybedahl) #30

There is some sort of disconnect with the hub and the proxy host. The traffic passed is essentially web traffic with a few parameters. Try going to this in a browser:


Replace the variables with their values from the device handler settings and be sure to take out the ${} too. That should open your garage door. That will verify that the proxy service is working correctly. If that works then we know it’s something to do with the hub or device handler. Let me know the results and if need be I’ll see if there is something that could help debug the device handler.

(Projectskydroid) #31

Yep, I entered that string with my credentials into the browser and the garage immediately opened, and the command registered in the proxy nodes terminal window. Something clearly isn’t getting sent right on the device handler side.

(Justin Dybedahl) #32

@projectskydroid do you have the port specified in the device handler settings? The only thing I can think of is that the internal ip and or Port is wrong or missing. I know the setting for port shows if not 3042 specify it but I’m wondering if there is a bug where if you don’t have it specified, it fails. Regardless, the traffic should be sent if those two are correct. Device network id in the IDE device settings should only affect the status and refresh processing.

(Projectskydroid) #33

Ok, I finally figured out what the issue was (at least partially). All of the settings and ports were correct and filled in. Turns out there’s some sort of bug in smartthings where the system can “drop” or block devices that report a battery voltage outside of a recognized value. I don’t have a backup batter installed in my opener, so smartthings was basically stopping all commands from the device handler. Not sure if that’s supposed to happen by design or not. Either way, I commented out the battery code in the device handler and commands immediately started working.

As I can now test the new code, I’m still seeing the same problems with the button status’ not refreshing. I’m seeing the same issues with the 1.0 code, except I no longer get the _7 errors in terminal.

(Justin Dybedahl) #34

I will add something to the device handler to report 0% if the value is not reported to fix that. The status issue should be the device network id issue. It needs to be the proxy hosts ip and port in hex. Check to see if it is still.

(Projectskydroid) #35

Yeah, those values are correctly filled in the network ID as you described.

(Justin Dybedahl) #36

This may still have to do with the battery reporting issue as they are all sent on the same string and then I parsed through that string to get the individual values in the device handler. I’ll pull my battery when I get home from work and do some testing. I’ll get back to you later tonight. Appreciate you working with me on getting this fixed. :slight_smile:

(Justin Dybedahl) #37

@projectskydroid Modified the DTH to account for your issue. Update it and let me know if that helps.

(Projectskydroid) #38

Thanks for continuing to look into this. I really appreciate it. I just tried the new code and the problem is still occurring. The device shows up in the IDE, but is missing from the smartthings app. If I then comment out line 29 capability “battery” the device immediately shows back up in the smartthings app, but fails to refresh properly. I’m perplexed. I’ve also opened a ticket with smartthings to make sure there’s nothing on there end thats broken.

(Justin Dybedahl) #39

I ran into this when the device had a bad value for the battery. Can you check the battery value in the IDE and verify that it’s not set to something outside the normal 0-100. I can’t remember if you can edit that value as I took the shotgun approach and deleted my device and recreated it. Once I did that, it showed correctly.

(Projectskydroid) #40

Ok. I’m going to try and deleted the handler and device and reenter everything from scratch. Wonder if there’s some value stuck from past code.

(Projectskydroid) #41

Ok. Deleted everything and reentered it and same problem. I was able to review the “events” in the IDE for the device and it is reporting a battery value of “undefined”. Definitely not show 0-100.

(Justin Dybedahl) #42

@projectskydroid Edit the proxy source code and find the line like the one below.

response.end(‘status:’ + String(lightval) + ‘:’ + String(doorval) + ‘:’ + String(batval))

Put this line directly above it.

console.log(‘status:’ + String(lightval) + ‘:’ + String(doorval) + ‘:’ + String(batval))

It’s essentially the same line but will output the value to the console. I’m thinking there is something value reported that I’m unable to reproduce on my end. Let me know what it outputs to the console. It should start with status: