-
Notifications
You must be signed in to change notification settings - Fork 26
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
c251de5
commit effb20c
Showing
2 changed files
with
44 additions
and
144 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
effb20c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kann ich zu diesem commit für die 2.3.0 bitte mal nachfragen wieso das gesamte management via bottleneck wieder entfernt wurde? Hat sich irgendetwas im event management im node-hue-api paket geändert, das dieses nun die Auslieferung von events an die hue bridge anhand dessen event limits managed? Damals hatte ich ja das event management via bottleneck klasse extra in iobroker.hue eingeführt da es ansonsten recht schnell zur Überlastung der hue bridge kommen kann und somit events verloren gehen. Hat sich hier also irgendetwas geändert das wirklich das event management via bottleneck nicht mehr notwendig ist?
effb20c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sehr gerne. Vorab: Erst mal ist es nur experimentell. Im Stable ist die Queue drin.
In der Vergangenheit wurde für jede Gruppe + jedes Licht im Polling Intervall eine Anfrage an die API geschossen, was anscheinend dazu geführt hat, dass die Bridge bei größeren Installationen überlastet wurde. Deshalb hat BF auch die Queue eingeführt (?) und du sie anständig implementiert.
Das Polling ist nun nicht mehr abhängig von der Anzahl an Lichtern, Gruppen. Stattdessen werden alle x (pollingInterval) Sekunden fix 2 Anfragen (das config Objekt wird gepollt, welches alle Lichter, Sensoren und Gruppen, außer die all Gruppe enthält + die all (0) Gruppe wird gepollt) abgesetzt.
Aus diesem Grund vermute ich, dass die Qeue nicht weiter benötigt wird und zudem laut mehreren Berichten zu einer im 100er ms Bereich, jedoch merklichen Verzögerung führt.
effb20c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bei den ursprünglich umgesetzten Queuelösungen (auch die via bottleneck) geht es doch darum, das damit die von Philips hart vorgegebenen Grenzen der Philips Hue API eingehalten werden und es nicht zu der Situation kommen soll, das die Philips Hue Bridge in ihre API Limits läuft und dann komplett für den angegebenen API Key dicht macht. Natürlich sollte das regelmäßige polling alle X sekunden
submitHueCmd('getFullState')
vielleicht nicht alleine dazu führen, dass die Hue bridge in die Limits läuft (man beachte allerdings die Kommentare in der node-hue-api das man getFullState eigentlich nicht regelmäßig aufrufen sollte. Siehe: https://github.com/peter-murray/node-hue-api/blob/master/hue-api/index.js#L111-L112).Trotzdem gibt und gab es eben in der Vergangenheit sehr gute Gründe diese Queuelösungen umzusetzen, sodass ich es weiterhin für keine gute Idee halte diese Queue einfach komplett zu entfernen nur um etwaigen kleine Verzögerungen komplett aus dem weg zu gehen. Gerade bei aufwendigen Installationen mit vielen Lichtern und vielen via API getriggerten Lichtprogrammen kommt es recht schnell dazu, dass man die von Philips vorgegebenen Limits schnell erreicht und dann kommt es bei erreichen der Limits zu komischen Effekten da Events von der Bridge dann z.B. einfach ignoriert oder verworfen werden. So z.B. wenn man Lichter dann ein/ausschalten will, die Bridge aber eben das nicht mehr für einen gewissen Zeitraum zulässt und damit das an/ausschaltkommando komplett verworfen wird. Die via bottleneck umgesetzte Queue stellte aber eben sicher das die von Philips vorgegebenen Grenzen eingehalten werden und es zu solchen Effekten nicht mehr kommen sollte. Ich bleibe also dabei, dass mir das entfernen der Queue schon merkliche Bauchschmerzen verursacht, da ich weiterhin denke das man sicherstellen sollte das die von Philips vorgegebenen API Limits eingehalten werden.
effb20c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kann mir ehrlichgesagt nicht vorstellen, dass das annährend so ein großes Problem sein könnte, wie zu viele einzelne Anfragen zu stellen. Auch ist das Feedback von größeren Installationen nach der Umstellung sehr positiv (s. Forum). Letztendlich wird ein größeres JSON geparsed statt viele kleine. Auf unserer Seite ist das schon mal gar kein Problem und auf der Bridge Seite
sollte
es auch keines darstellen.Ich habe mal auf die Queue Implementierung zurückgerudert. Hierzu finde ich auf die schnelle leider keine offizielle Angabe zu einer Begrenzung (hast du hierzu eine Quelle?).
Edit: Gefunden https://developers.meethue.com/support/