Scan_interval still available?

[Mariusthvdb]

During the realization of the new architecture of this custom integration, a scan setting was introduced to diverge form the default 0.5 hz frequency:

remote:
  - platform: huesensor
    scan_interval: 1

is this still available in the new split-up configuration? I ask because it isn't mentioned any more in the docs, but very much needed in the real life setup...to not Hammer the Hue Hub with an overdose of requests

[azogue]

is this still available in the new split-up configuration?

Yes, you can customize the scan_interval. Now the config is:

remote:
  - platform: hueremote
    scan_interval: X   # seconds

You can inspect this in: https://github.com/robmarkcole/Hue-remotes-HASS/blob/f226d1d2fdf91906e1b62ae4bfb973c74b2ec7fa/custom_components/hueremote/remote.py#L40

BUT, the best refresh rate is reached with the default value, so if you want speed, do not set anything there. If, on the contrary, you don't need speed and want to relax the bridge hammering, then set a bigger scan_interval here.

[Mariusthvdb]

HI, thanks for a quick support answer! appreciated. Maybe update that in the docs?

Must admit though that using the default value did cause the error flood in the log to increase... I always used a lower refresh rate than the 0.1 value in the original custom Hue sensors, and upping it isn't appreciated by my Hub. As a consequence the lights simply wouldn't stay available for longer than a few minutes at most. It still is haphazard, even with a 1 second interval and I am truly sorry your effort to change the core files to mitigate this is blocked by Balloob.

But, getting back to this custom integration, all I can do now is lower the frequency here.

this doesn't adjust the Hue_sensors? Am I correct they now are in the identical flow the core integration uses?

[azogue]

It still is haphazard, even with a 1 second interval and I am truly sorry your effort to change the core files to mitigate this is blocked by Balloob.

IMO that is not what is happening. I don't feel blocked by Paulus in any way. On the contrary, I usually agree with him, always learn from him, and also enjoy interacting with him in any constructive discussion. So I'm on his side on this, if you chose to see this that way (but it is not that way, there are no 'sides')

But, getting back to this custom integration, all I can do now is lower the frequency here.

I've always understood that you wanted a high frequency rate, not a low one. If you are comfortable with a higher scan_interval, what's the problem with the official integration?

this doesn't adjust the Hue_sensors? Am I correct they now are in the identical flow the core integration uses?

No. They will be at some time when #7 is merged (actual release on HA doesn't include a necessary change used there).

Right now they are just using the same 'data update coordinator' that makes the calls to the bridge, so when the CC calls an update, both receive the changes and update states. The scan_interval on sensors is fixed at 5s. We set another extra scheduler with our own scan_interval, and that is why the sensors benefit from the high update rate (when both schedules collide only 1 call is made for both sensors in main hue and remotes here).

[Mariusthvdb]

just so I make myself clear and not cause confusion: If I say 'lower' the frequency, I mean going from 0.5 to 1 scan per second..

the problem with the official integration is that is is not stable, and all lights and sensors go unavailable all the time. It supposedly is not originating from the core Hue code as Paulus says, and indicates other problems in the setup, but, I that doesn't really help. Hence my disappointment when you were told you looked at things from a Hue perspective. I was glad that was finally happening as that is exactly what would help mitigate this issue. Had set my hopes on your option 2. Got to remember all of these issues were introduced when core Hue code changed (I've provided the link in 1 of the discussion threads) So instead of improving things at that time, which no doubt was reason to change, things started to go 'unavailable'.

Having said all that, why prefer the custom integration and its sensors? Well, because it is rock solid, and never fails! I have asked before if anyone could explain why this is, and it remained silent ever after.

I'd go for the core integration any time if is would be as solid. Heck, I try it on each iteration of the code. but the result is always identical.

[robmarkcole]

discussion resolved