Async http Implementation documentation

[anon62731458]

Can anyone point me to any documentation or details on how the async handling was implemented by Hubitat? Specifically related to how it handles the callback functions to deal with the replies as they arrive.

Trying to work on figuring out the issue with controlling multiple wifi lights at once in synch, and think it may be related to the Async response handling by the hub or device driver.

Using async outside of HE allows synchronized control of 18+ lights before you start to get lag/popcorn, but i haven't been able to get the HE to reliably control more than 3 without getting popcorn. (of course using MQTT i can control all 60+ bulbs in synch, but that does the average user the platform is aimed at no good unless/until we get official native MQTT)

Anyone written anything to trace/debug the async and reply handling yet?

[gavincampbell]

Is this what you are looking for?

Async HTTP calls

Asynchronous calls are now available in the Hubitat Elevation system. The following methods are available: void asynchttpGet(String callbackMethod, Map params, Map data = null) void asynchttpPost(String callbackMethod, Map params, Map data = null) void asynchttpPut(String callbackMethod, Map params, Map data = null) void asynchttpDelete(String callbackMethod, Map params, Map data = null) void asynchttpPatch(String callbackMethod, Map params, Map data = null) void asynchttpHead(String callbackM…

It’s actually very easy to implement once you do it the first time.

[anon62731458]

Thank you but no. I want to know how they implemented it on the hub itself, not how we can make use of it.

I think there may be a bug in the response handling based on the behaviors I see when addressing more than 3 wifi lights at once.

Basically when the replies start coming back from the devices it seems to cause a delay in the hubs processing of the current outgoing calls.

It may be something else responsible for it, but with the limited access we have to the devices workings this is my first step in tracing the problem.

[gavincampbell]

Ahh ok. I think then @mike.maxwell may be better to answer.

However, I think if you let him know what app/driver your using and if there are any settings in it that you may have set or not set it may help him narrow down where the hangup may be.

The drivers can be a culprit if they don't use async as then the calling app may be waiting on it to complete for each one. He would know for sure though.

[anon62731458]

A bit more detail... C-5 hub, all devices at 70% or higher signal quality, live in the country and the only wifi networks aside from mine are the occasional vehicle that rides by that is wifi enabled, nearest non amish neighbor with wifi is over a mile away. Network is wired on a gigabit switch, each AP in my mesh is wired and on a different channel (no wifi repeaters), none overlapping, transmit power adjusted down to prevent AP interference, and zigbee is on channel 15.

Tasmota flashed bulbs, have tried with various firmware versions from stable to dev and even the ones markus made for hubitat.

Doesn't matter which driver or settings I use to control them, emulations on or off, groups set up or not, all exhibit the same behavior, which is why Im thinking something in the implementation versus the drivers themselves.

Issue async calls from outside of hubitat, all light change in sync no popcorn no delays.

Contacted the dev for one of the drivers, haven't reached out to others yet, (being so new to the community I still tend to get the you don't know anything backlash so i don't reach out much yet) he is using async and had actually noticed the same behavior himself but hasn't had the time to write up a driver to help trace where or what the issue is.