The values had to be manipulated in a special way and wasn’t intuitive at all.įor the firmware’s part it really is as simple as just the one header, the JSON payload and the destination address of I think.
Smartthings adding smartapp from github mac#
It was so specific in fact that I programmed around it making it easier for user by filling in values that work programmatically using the IP and port and then later putting the MAC address in there when it’s available from a response from the OG. If you are setting up the device in SmartThings it was something very specific that you have to do on the hub side. It isn’t anything you have to handle in the request on the firmware side. Here is the link to the updated device Ah, sorry for the confusion.
Smartthings adding smartapp from github code#
However, to receive inbound requests the device’s device network ID MUST be the MAC and not the IP:PORT so I adapted the code to use the IP:PORT until it could get the MAC from a “/jc” call and then fill it in so it could receive requests. I found out that routing also works if you use the MAC address as I described above. For example, when an outbound request is made from the device the response is only routed to the correct device handler if the device’s device network ID is the IPinHex:PortinHex. I had to change a few things in the current device handler to get this to work. I wrote this new local functionality into my device handler already. For example, mine is “” but my brother’s who lives only 30 miles away is different. The base URL will change depending on where you got hosted when you log into SmartThings first so it might be one of about 10 values. Here is some documentation here.Įssentially you would need to make a HTTP GET for each action to: If you want to add something to the firmware that would be awesome. Apparently it gets a little harder when you try to have a local device make calls at the SmartThings hubs directly. It is pretty simple to register a URL for events if the URL is hosted on the SmartThings platform. There might be other weird restrictions that prevent Yes, it does. I tried creating an OOB automation with the OG’s device handler in it but for security reasons any routines with doors in them won’t share through the integration. It would be weird to use because you would be saying something like… “Hey, Google… turn on the garage door”. I’m also considering implementing switch functionality so that an OG can be shared to Google Home through the SmartThings integration. I have implemented a way to poll the OG to synchronize its state as well but I don’t know if it’s best practice so I’m checking around before I push that change. If the door is found to be out of synchronization it updates the status and then decides whether or not the button should be pressed. Instead of (or perhaps alongside) polling the OG for state I put logic in the device handler to refresh state before it blindly performs an open or close.
0 kommentar(er)
