Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[AlCalzone]

@arteck Und deswegen ist es ein semver-major update

[foxriver76]

@arteck Zwingt dich keiner zum updaten und über die Art und Weise wie du hier schreibst solltest du nochmal nachdenken.

[arteck]

@foxriver76 na das ist mal wieder konstruktiv... da freut sich die kommunity

welchen positiven Aspket bringt eine umbenennung des Objektes ????
nur mal so zur Info.. es gibt Leute die mehr Lampen haben.. und diese Steuern ..

jetzt änderst du den Hauptknoten .. einfach mal so.. wozu ????

@foxriver76 sagte in [Aufruf] Hue Adapter 2.0.0:

über die Art und Weise wie du hier schreibst solltest du nochmal nachdenken.

jo nachgedacht...

[Jey Cee]

Ich kann zwar den Grund für die Umbenennung sehen, aber ich sehe keine Notwendigkeit dazu.
In sofern hat arteck mit seinem Einwand vollkommen recht das es nicht besonders Positiv aufgenommen werden wird.

Gibt es den einen Grund der die Veränderung der Struktur Notwendig macht?

[foxriver76]

@arteck Wir können gerne konstruktiv darüber diskutieren, 'ist nicht dein ernst' finde ich allerdings äußert unkonstruktiv. Genug hierzu. ;-)

Der Grund für die Änderung ist, dass suggeriert wird, dass der Adapter mehrere Gateways handhaben könnte. Harmony hat eine ähnliche Struktur, unterstützt jedoch auch mehrere Gateways, somit macht das Sinn. In Hue ist ein Channel der wiederum einen einzelnen Channel beinhaltet und auch niemals mehr beinhalten wird. So wie es jetzt ist wird strikt Device->Channel->State befolgt. Ich würde mir auch keinen Ordner im Filesystem erstellen um nur einen weiteren Ordner rein zu packen.

[arteck]

@foxriver76 na zumindest kannst du meine Aufregeung verstehen...

ja gebe ich dir recht. aber.. es tut nicht weh .. wenn das hauptobjekt da bleibt.. und du ersparst jedem der den Adapter nutzt die Umbenennung.... zur not würde ich vielleicht abfragen.. wenn schon ein Datenknoten exisitert dann belass es .. ansonsten lege den Baum neu an..

[foxriver76]

@arteck Denke, dann würde ich komplett zurück auf die 'alte Struktur'. Sonst hat der Nutzer das gleiche Problem wie jetzt, wenn er mal aus irgendwelchen Gründen die Struktur löscht, zudem führt es zu unnötiger Komplexität im Code.

[AlCalzone]

@foxriver76 Wäre es ggf. sinnvoll, eine Option einzuführen "legacy-Objektstruktur"? Wenn aus, dann wird die bisherige Struktur beibehalten, sonst die neue verwendet.

Könnte (falls nicht gesetzt) beim Adapterstart gesetzt werden:
Keine Objekte vorhanden ==> Option auf false setzen (Neustart)

So würden neue User die neue Struktur bekommen und alte könnten sich entscheiden.

[foxriver76]

@AlCalzone Ist wie Artecks Option nur dass sie jederzeit beeinflussbar ist. Denke so werde ich es machen. :+1:

[foxriver76]

Es gibt nun zusätzlich eine Option in den Adaptereinstellungen um die "Legacy" Struktur zu nutzen. Nach meinen ersten Tests läuft es wie es soll. Nach wie vor bitte von GitHub installieren und Upload nicht vergessen. ;-)

[arteck]

@foxriver76 jo geht :+1: :+1: ... so viel Aufregung :blush: ....... klasse Arbeit

[foxriver76]

Da die Checkbox von Anfang an auf false steht und somit beim ersten Start Chaos entstehen würde, wird die Checkbox ignoriert und die Legacy-Struktur automatisch genutzt, falls sie bereits existiert. D. h. wenn jemand auf die neue Struktur umziehen möchte, sollte er ein mal den kompletten Namespace löschen, da sonst die Legacy-Struktur automatisch genutzt wird. Somit wird die neue Struktur bei frisch installierten Adaptern automatisch genutzt und bei bestehenden die existente Struktur behalten.

[lobomau]

will bei mir noch nicht recht. Ich hatte gleich mal polling auf 5s runter gestellt. Bin jetzt wieder auf 20s hoch ohne, dass der Fehler weg geht.

hue.0	2019-09-25 22:14:10.490	error	Error: timeout of 10000ms exceeded
hue.0	2019-09-25 22:14:10.489	warn	could not connect to HUE bridge (192.168.178.22:80)
hue.0	2019-09-25 22:13:55.486	error	Error: timeout of 10000ms exceeded
hue.0	2019-09-25 22:13:55.485	warn	could not connect to HUE bridge (192.168.178.22:80)
hue.0	2019-09-25 22:13:45.405	info	starting. Version 2.0.0 in /opt/iobroker/node_modules/iobroker.hue, node: v10.16.3

Edit: liegt wohl eher an meinem System. Bin auf Vers. 1.2.4 und der Fehler bleibt bestehen. Erst Vers. 0.6.9. läuft bei mir vernünftig. Das war schon vorher so bei mir.

Nee... nicht mal 0.6.9. läuft mehr bei mir. Never touch a running system :-(

hue.0	2019-09-25 22:23:31.047	warn	could not connect to ip
hue.0	2019-09-25 22:23:16.041	warn	could not connect to ip
hue.0	2019-09-25 22:23:01.036	warn	could not connect to ip
hue.0	2019-09-25 22:22:50.961	info	starting. Version 0.6.9 in /opt/iobroker/node_modules/iobroker.hue, node: v10.16.3

Edit2: so... 0.6.9. läuft wieder. Ich habe neuen User erstellt. Morgen oder so traue ich mich wieder an die 2.0.0 ;-)

[sigi234]

Danke, funktioniert sehr gut.:+1:

[xADDRx]

Hallo,

ich habe mal die neue Version aufgespielt. Mir ist leider gleich der gleiche Fehler wie bei den vorherigen Versionen aufgefallen (jedefalls bei mir). Sobald ich eine Lampe über VIS einschalte, geht die Lampe an und gleich wieder aus, also regiert es 2x... Einzig bei der Version 0.6.9 funktioniert alles. Auch sind die reaktionszeiten bei der alten Version besser..

Gruß

Ben

[arteck]

@xADDRx es liegt am widget und entprellen.. bzw am Browser. hat nix mit Adapter zu tun

[foxriver76]

@xADDRx Mit der alten Version meinst du die 1.2.X oder die 0.6.9? Im Vergleich zur 1.2.X sollte es keinen Unterschied geben, zur 0.6.9 -> kann sein, da die Queue implementiert wurde, ich merke allerdings keinen Delay in der Praxis.

Ebenfalls lassen sich die Leuchtmittel ohne das von dir beschriebene Verhalten schalten (via Objekte und Bool Checkbox getestet). Evtl. siehe Antwort von @arteck, ich weiß nicht um welches Widget es geht - der Adapter liefert keins mit.

[xADDRx]

@arteck würde ich ja glauben, aber warum funktioniert es denn mit der Version 0.6.9? Ich habe damals auch auf 1.2.X geupdatet, da hatte ich die selben Probleme.

Ich habe übrigens die Version 0.6.9 wieder drauf und alles funktioniert wieder wunderbar. :woman-shrugging:

Muss mir die Widgets mal anschauen, aber komisch ist das...

[Mic]

@foxriver76
Vielen Dank für die Weiterentwicklung! Wie grenzt sich denn der Adapter zum https://github.com/Zefau/ioBroker.hue-extended ab? Den teste ich derzeit, weiß daher nicht, ob ich wieder "zurück" zum Hue-Adapter gehen soll.

@arteck sagte in [Aufruf] Hue Adapter 2.0.0:

ich muss jede Lampe anfassen im Script und in der Vis...
da sich hier die Datenpunkte geändert haben

Geht da nicht einfach ein simples suchen/ersetzen der Dateien? Also VIS (vis-views.json), /opt/iobroker/iobroker-data/objects.json etc.

[arteck]

@Mic der eine ist alt der andere ist neu