ioBroker / ioBroker.rest-api

Swagger UI for ioBroker
Apache License 2.0
12 stars 8 forks source link

Some adapters seem to be unreliable with long polling (esp. hue) #77

Open i-am-magoo opened 1 year ago

i-am-magoo commented 1 year ago

I have fiddled around with only a single subscription up to multiple subscriptions, but that does not seem to be the problem. Subscriptions for most adapters seem to work lighning fast and reliable (e.g. zigbee and knx).

Whereas if I have changes to multiple hue devices at once, I only get a few of the updates reported back. And even those come in with quite a delay.

Is this something I can address within my application, or would you guys happen to know about this being a problem within the hue adapter?

Apollon77 commented 1 year ago

Hm ... can you provide more details? Logs from your app and maybe same timeframe debug log from the adapter? Else this question is noear to impossible to answer

i-am-magoo commented 1 year ago

I am fairly new to this sort of JavaScript application, so there just might be bad practices in my code. Also, in the browser console I do not get any errors. Neither are there any errors within any of the used ioBroker adapters.

I spare you the HTML part, which consists of a few tables, where the table cells only have span-elements with ioBroker datapoints as IDs.

What I adapted from the provided demoBrowserClient.html example:

` `

My problem is, when I activate a scene that includes multiple KNX lightgroups and multiple hue lights, the KNX datapoints report updates to the browser application instantaneous. But I only get updates on a subset of the hue lights. Unfortunately, there is no pattern either: I get updates on 2-3 out of 8 hue lights, and the updates that do come through, do not come for the same lights every time.

Like I said, the hue application does not seem to have any errors (those changes still get logged by the history and SQL-adapters with no problem). So I am not sure where to look first, why these updates get lost somewhere.