March 5, 2018 at 11:15 am #1025
You two have lost me a bit on this. I’ve just been using the code provided but honestly not really understanding it. Is what you’re implementing meant for everyone, or is it really for something specific only you two are working on?March 5, 2018 at 11:22 am #1027
My hope was to implement a somewhat generic webhook type notifier so OG can tell any system (whether it is SmartThings or something else (like Node-Red) that a door or vehicle status has changed. This avoids the need for them to have to constantly query OG and watch for the status to change (This is what I currently do for the apple support and it is somewhat inefficient and problematic as the code every 10 seconds asks ‘OG Are you open or closed”?
So the specific case right now is for SmartThings and using that as a POC but I would like to make it more generic on the OG side at least.
Ben’s Smartthings app could then be used to pickup the notification and update the app
at least that was my thoughtMarch 5, 2018 at 3:01 pm #1028
@kculhane It is definitely for everybody but it is not ready yet. Don’t install it until we give you an okay.
Also, I think what Jeff is getting at is if we do this change correctly on the firmware for ST we may be able to get away from doing one-off changes for every integration we need.
@lawrence_jeff This is very interesting to me. Maybe what we setup in the GUI is something like the ability to choose POST or GET and then just provide a URL and then maybe even provide a way to add more of them and we can store the webhook configuration in an array. This way we could configure as many as we wanted until we ran out of memory or hit some imposed limit or something (like 5 or 10).
To your other question, yes, it is absolutely reasonable for us to want to send the data that we need so we don’t have to turn around and make another call right back and ask for it. I was just trying to make it as least impacting as possible. I would actually want essentially the same payload we get on calling “/jc” actually. Specifically the mac address, door, and vehicle. I can get the rest of the values from “/jc” if I need them.
To support 2 OGs in ST wouldn’t be via port, URL or payload. ST does this based off of the connecting device’s packet or TCP/IP connection information probably. It looks at the MAC address of the connection I think but it doesn’t send that information along to me. It just uses it to route and then drops it. I would be able to configure multiple OGs in ST though by giving each OG in STs the correct physical MAC address of each physical OG. Then the routing would work and each virtual device in ST would get the appropriate packets from that same URL and port.
Let me know if that makes sense.March 5, 2018 at 4:39 pm #1032
Thanks for the clarification. I kinda figured it was still in development phase, but just wanted to check.
You guys are awesome for putting this effort into it!May 31, 2018 at 8:11 am #1151
Was there any further progress made on this integrationMay 31, 2018 at 2:18 pm #1152
I don’t see any activity on lawrence-jeff on github so if Jeff is working on it it’s not committed yet.
I haven’t tested but I’m pretty sure you can still install my device handler and it will work as it did before. The problem is that SmartThings won’t know if you control the OpenGarage from the hardware button until SmartThings polls again. That’s the optimization that we needed a firmware change to fix. So, you can still use the current handler it just doesn’t update the garage door is open or closed for up to 5 minutes if you don’t do it through SmartThings.
It’s here. You don’t need the SmartApp. Just the device handler.January 14, 2019 at 4:48 pm #1395
Hello, everyone. It’s been a really long time since this thread has had any action. Jeff seems to have gotten busy and this finally came up on my list of priorities so I made a version of the firmware that supports SmartThings (and Hubitat).
The code for the firmware can be found here:
The code for the SmartThings device handler can be found here:
The code for the Hubitat device handler can be found here (this will probably change locations if Hubitat introduces a github integration):
Same concept to install as previously mentioned in this thread for the device handler. The only difference now is that in your OpenGarage firmware settings you need to go to Integrations and you need to specify the IP and port of your SmartThings (or Hubitat) hub.
For example, my SmartThings hub is at:
192.168.1.10:39500 (39500 is the default port)
My Hubitat hub is at:
192.168.1.11:39501 (39501 is the default port)
I’ve been using it for a couple of days. Hopefully it will work out for you guys.
January 14, 2019 at 4:53 pm #1396
- This reply was modified 2 weeks, 5 days ago by codahq. Reason: Updated links
That’s great codahq. I’ve dropped the ball since starting this project and haven’t updated my system with all new additions but plan to do that shortly. Particularly, because it seems to have broken since Samsung got involved and doesn’t currently work!
Looking forward to implementing your code codahq, and thanks very much for posting it here!January 14, 2019 at 4:53 pm #1397
Oh, by the way… For those of you have who have been using the device handler in SmartThings up to this point the only thing this changes is that instead of having to wait up to 5 minutes for SmartThings to poll the OpenGarage the firmware on the OpenGarage tells SmartThings (and Hubitat) when a change has occurred so they know immediately when the door has opened or closed.
This is much better for automations. For example, I have an automation that if the Garage Door has opened in the last 5 minutes and then the back garage door opens AND it’s dark a subset of lights turns on. It makes it so my wife never has to walk into a dark home when she arrives home. (Yes, there are other ways to do this with presence sensors. No lectures, please.)
You must be logged in to reply to this topic.