Performance of the HW about homebridge-homewizard HOT 14 CLOSED

Totally agree, currently i already limit the number of outstanding request to the HW in api by using a queue, otherwise HW couldn't handle it at all. But that's not enough, im working an local branch to implement pushing state changes of sensors to Homekit which means i need to fire state request for accessories every couple of seconds. I build in a form of caching in there in the sense that if two accessories both do the same api call (sw-list for example), they will share the same request and response.

Might wanna think indeed about debouncing the setters as well, i'll try to make some time tonight to finish this up and commit it 👍

from homebridge-homewizard.

Just released version 0.0.29 which has huge improvements related to re-using of API calls and caching.
The api calls: get-sensors (15 minutes, only used for battery status rightt now), get-status (1 second) and swlist (1 second) are now being cached and requests are being shared so when homekit asks for the status of all accessories it results in only 1 or 2 requests to the HW instead of one or more calls per accessory 😄

No solution for setting values yet, will look into that tomorrow 👍

from homebridge-homewizard.

For your information when I try several times to get-status with "time curl http:////get-status"
I obtain always a global delay of 0.14 sec.
The HW Wi-Fi is 802.11g at TX/RX 24Mb/s and my Mac is connected to the box with Ethernet 1Gb/sec.

from homebridge-homewizard.

I have in the same room 2 HUE lights.
When I ask to SIRI to turn on light on in green, it works.
When I ask to SIRI to turn all the lights in green, very often I have e socket hangup.

For the main room I have 10 ordinary lights, it is the same. 7 /10 works at mean, always with socket hangup.

All the HTTP request are emitted in a very short delay by SIRI and redirected "immediately" by the plugin to the HW.

from homebridge-homewizard.

Hmmm ok, currently requests are being queued. Meaning that if api.request is called 10 times, only 3 should be fired immediately. And once one of them resolves the next once should be fired until the queue is empty. This is currently being unit tested and seems to be working properly.

There are 2 things you could try to see if they improve your situation:

1: Lower the number of simultaneous request in api.js, at the top is a variable limit.

2: In api.js in change the function _queueResolve, to set a timeout. This means that it will wait a little time (200ms in the example) before firing a new request to the HW. See example below (untested):

  _queueResolve() {
    // Just popping an item. We just need to queue to shrink,
    // so items in the queue aren't always the non resolved promises!
    this.running.pop();

    if (this.queue.length > 0 && this.running.length < this.limit) {
      const next = this.queue.shift();
      this.running.push(next);
      setTimeout(next.resolve, 200);
    }
  }

Both these methods should give the HW a bit more air to breath between requests, maybe this solves the issue. Maybe you could also test if the queue mechanisme is working correctly, maybe i'm testing it wrong. It's just sad that the performance of the HW is so terrible :(

from homebridge-homewizard.

The HW response time for any set in HUE est 0,4sec !! And the response is very light !!
I will look the api.

from homebridge-homewizard.

How is this working out for you @ygageot, still having performance issues?

from homebridge-homewizard.

Globaly it’s ok.
But the main residual problem is coming from the service WindowCovering because the positions in HomeKit are in percentage 0% >> 100% drives by sliders on UI and converted in up/stop/down for Somfy or Brel.
I will try to change minStep to 50 to see the impact on the apps UI.

from homebridge-homewizard.

Ok might want to change the switch statement which now is using those exact values to something with ranges. That way the position on the slider determines the action? First part is down, biggest part in the middle is stop and last part is up? Just an idea, don't know if it improves the experience.

if (level <= 20) {
  value = 'down';
} else if (level >= 21 && level =< 80) {
  value = 'stop';
} else {
  value = 'up'
}

from homebridge-homewizard.

I tried this before with 1/3, 1/3, 1/3

For the moment my best personal version is :

const WIDTH = 10;
if (level === 0) {
value = 'down';
} else if (level === 100) {
value = 'up';
} else if (level > 50 - WIDTH && level < 50 + WIDTH) {
value = 'stop';
} else {
return callback();
}
without debounce

It works well with MyTouchHome with a slider, less with Eve with +/- buttons and a long delay to go to 100% or 0% or the middle ….
The property minStep is not effective !

Le 9 mars 2016 à 15:49, Raymond [email protected] a écrit :

Ok might want to change the switch statement which now is using those exact values to something with ranges. That way the position on the slider determines the action? First part is down, biggest part in the middle is stop and last part is up? Just an idea, don't know if it improves the experience.

if (level <= 20) {
value = 'down';
} else if (level >= 21 && level =< 80) {
value = 'stop';
} else {
value = 'up'
}
—
Reply to this email directly or view it on GitHub #11 (comment).

from homebridge-homewizard.

Ok, think we tackled the biggest performance issues now 👍 Closing this issue for now. If we find any other performance related issues we can reopen it or create a new one :-)

from homebridge-homewizard.

@rthewhite
Playing with Siri, I asked to change the color or intensity of two HUE lights in one room.
Sometimes it works well, sometimes not.
In fact two HTTP requests are emitted quite simultaneously by the plugin, the first is executed by the HW API, but the second has a { [Error: socket hang up] code: 'ECONNRESET' }.
These type of HTTP request has a duration of 0.7 sec, probably because it must travel via the HUE bridge.
I hesitate to change the code

• several retries ?
• building a queue 1 by 1 of the HTTP requests
  What do you think ?

from homebridge-homewizard.

@ygageot looks like the HW can't handle both requests simultaneous....

Have you tried changing the limit at the top of api.js to 1? This will queue the requests in a way that only 1 request is send to the HW at a time. Once the response comes in the next one is send.

from homebridge-homewizard.

I tried with 2 but the problem is still here.
With 1 it works with my test !

from homebridge-homewizard.