I wander if an automated conversion tool could be created ?
8 Likes
LAN WiFi Devices not Throttled.
In SmartThings, there is a restrictor (throttle) that sends Hub LAN commands about every 100 ms. I believe that Hubitat does not have this restrictor. Impact is that if you are sending commands close together, then you will need a "pause" execution on some devices (i.e., Samsung Speakers). Otherwise, return message are missed or confused, especially if you are using explicit callbacks.
Mike, Is this true. It is what I am seeing while developing the Samsung WiFi speaker driver. I get some really weird results until I insert a pauseExecution.
Dave*
1 Like
We don't throttle or rate limit anything, and the hub is fast enough that you need to consider device response latency and event ordering.
WiFi Command Firing. For some reason, WiFi commands are not transmitted if the firing command is followed by a log command. Example
This works:
private sendUpnpCmd(String action, Map body=[InstanceID:0, Speed:1]){ logTrace("sendUpnpCmd: upnpAction = ${action}, upnpBody = ${body}") def deviceIP = getDataValue("deviceIP") def host = "${deviceIP}:9197" def path = "/upnp/control/AVTransport1" def hubCmd = new hubitat.device.HubSoapAction( path: path, urn: "urn:schemas-upnp-org:service:AVTransport:1", action: action, body: body, headers: [Host: host, CONNECTION: "close"] ) log.info hubCmd hubCmd }
This doesn't work:
private sendUpnpCmd(String action, Map body=[InstanceID:0, Speed:1]){ logTrace("sendUpnpCmd: upnpAction = ${action}, upnpBody = ${body}") def deviceIP = getDataValue("deviceIP") def host = "${deviceIP}:9197" def path = "/upnp/control/AVTransport1" def hubCmd = new hubitat.device.HubSoapAction( path: path, urn: "urn:schemas-upnp-org:service:AVTransport:1", action: action, body: body, headers: [Host: host, CONNECTION: "close"] ) hubCmd log.info hubCmd }
is implicitly really
log.info hubCmd
return hubCmd
If you think of it this way, it makes more sense. In fact, I believe you can write it exactly as I have shown above to make it more clear. You would never issue another command after you 'return' from a routine.
In ST, you could use 'sendHubCommand()' to make sure the hub processed the request as desired. Hubitat currently does not support 'sendHubCommand()' in drivers, so you need to make sure that the last thing you do is return the cmd you want processed.
If I am mistaken about this, someone please clarify. This is just from my experience on both ST and Hubitat.
1 Like
You are correct. That is part of the groovy standard, the last line is considered an implicit return. The Apache Groovy programming language - Semantics
Also, sendHubCommand will be available for drivers in the next release. (it is currently available for apps)
5 Likes
A couple of basic syntax that also appear to differ between the platforms:
DOESN'T WORK:
input "fieldName", type:"text", title: "The Title", description: "The Desc"
WORKS:
input "fieldName", "text", title: "The Title", description: "The Desc"
DOESN'T WORK:
section("a title")
WORKS:
section("a title"){}
I'll add more as I test more of my code as I move it..
Can this thread be made sticky somewhere, it's been the most useful tread for me so far and Discourse search is a little painful.. 
4 Likes
This may be a dumb question, but I'm stumped about how to obtain OAUTH cloud endpoints using a typical OAUTH flow with Hubitat. Do I use the same calls as with SmartThings? Does it return the "code" as ST does that then requires another call to get the auth token? If so I don't see why you would need the calls above since the oath flow would return the endpoint. What am I missing? I can easily call these on the groovy side but that doesn't help me get the info into my PHP app that runs on a random server that may or may not be on the local LAN. I couldn't find any examples of OAUTH flow so any help will be appreciated. Also, will the httpPost work for local IP calls?
1 Like
I cannot find a solution to
Unable to resolve physicalgraph.app.ChildDeviceWrapper [...]
I replaced physicalgraph with hubitat, but that just changed the package name in the same error. Anyone have any idea?
The function with the error is:
private physicalgraph.app.ChildDeviceWrapper getChild(Integer childNum) {
return childDevices.find({ it.deviceNetworkId == "${device.deviceNetworkId}-c${childNum}" })
}
you don't need any of class path, replace the above with:
private getChild(Integer childNum) { return childDevices.find({ it.deviceNetworkId == "${device.deviceNetworkId}-c${childNum}" }) }
2 Likes
Thanks for the help, but I am returning my device. The SmartThings driver will require too much time to convert and understand (I have other more pressing projects), and the Hubitat DH for Aeon Home Energy Meter does nothing. After running for several days, and not collecting a single bit of data, it is time to abandon this idea for now. Hopefully someday soon an actual DH implementers document will be published, and we can bring custom DH code mainstream. My brain just isn't plastic enough to figure out undocumented systems.
3 Likes
I hadn't realised that Telnet access was possible from Hubitat ... this alone justifies the move from Smartthings and opens a world of possibilities.
Thankyou devlopers... 
4 Likes
@mike.maxwell I'm tagging you because I believe that you were one of the original creators of this project here that links squeezebox to smartthings.
Im trying to port it over to hubitat but I think its this line that's giving me issues in the squeeze switch server driver
sendHubCommand(new hubitat.device.HubAction("${playerID} ${command}\r\n\r\n",hubitat.device.Protocol.LAN, "${device.deviceNetworkId}"))
My json slurper sees login information being sent from the python script to telenet but noting is sent when i change a player switch state... I changed the port in my python script from 3500 to 3501 and made the device id changes required so I think its this line thats holding me up... any suggestions or a workaround?
Hasn’t this already been done?
Andy
2 Likes
see I knew there was a reason I posted here instead of messing with it all day hahah Ill look into this new one as it sounds way more capable. Thanks for the link
Search is your friend 
1 Like
Yeah I've often said that to other people.. I guess I just got focused on porting over my existing handler instead of looking for a new project. hence how I found this thread haha. This integration works way better than my old one so thanks for the solid recommendation!
Would be nice to see this community post converted over to the new docs.hubitat.com if that is the new home for official documentation.
2 Likes
Is it true that we are replace st with he? I vaguely recall seeing that a few weeks ago, but cant find it now, and st and he are too short on which to search.
such as this:
"st cmd 0x${device.deviceNetworkId} 0x12 0x0006 0x0 {}"
