SOLVED [gelöst] HUE Adapter v3.25 und v3.27 fehlerhafte Datenpunkte
-
@Mauflo sagte in HUE Adapter v3.25 und v3.27 fehlerhafte Datenpunkte:
Die History ist nicht so schlimm. Aber die Datenpunkte werden jetzt in meiner VIS nicht mehr gefunden, weil der Name verändert wurde
Mache es so: View exportieren Text kopieren, Notepad++ öffnen - Txt einfügen und dann ersetzte xxxxx mit xxxxxx - Txt kopieren dann View wieder importieren. Vorher alte View Name umbenennen.
-
@sigi234 ist nicht mehr notwendig mit der "Legay" Struktur. Allerdings werden im VIS Editor die Namen jetzt anders angezeigt. Sollte man die "Legay" Struktur canceln? Das wäre auch mit Deinem Tipp immer noch ein Haufen Arbeit.
Siehe:
Dabei fällt auf dassder Unterstrich bei Philips hue nicht mehr angezeigt wird. @foxriver76 war das so gewollt? -
@Mauflo
Mit der Methode von @sigi234 ist das fix erledigt, ich habe das früher mit meinen Broadlink Datenpunkten mituunter machen müssen, wenn der DeviceName geändert wurde. -
@Mauflo Jop, im Namen werden Leerzeichen angezeigt, falls welche da. Nur für IDs ist das nicht ok.
-
@BBTown Die Methode von @sigi234 brauch ich nicht mehr, da Dein Tipp mit der "Legay" Struktur goldrichtig war. Ich möchte nur verstehen, was die Legay Struktur ist und ob ich für die Zukunft die ändern muss!? @foxriver76 ,danke hab's jetzt auch gesehen.
-
@Mauflo
Die Legacy Struktur habe ich weiter oben hier im Thread erklärt (da hatte ich mich nur noch nicht an den Begriff "Legacy" erinnert)
In den ersten Versionen des HUE-Adapters wurden alle Datenpunkte unter
hue.0.Phlips_hue.xxxxabgelegt. Im Laufe der Entwicklung hat @foxriver76 dann die "Zwischenstufe"Philips_hueweggelassen und alle Datenpunnkte wurden ab sofort im "root" also unterhue.0.xxxxabgelegt, da man im Grunde selten bis nie eine weitere Ebene a laPhilips_huebenötigt.Um aber allen die bereits vorher die Datenpunkte unter
hue.0.Philips_hue.xxxxhatten nicht dazu zwingen zu müssen alle Scripte und Views umzubauen, kannst Du mit Setzen des Hakens "Legacy Struktur" die alte Schreibweise bzw Struktur weiter verwenden. -
@BBTown jetzt hab auch ich es kapiert. Danke.!
-
@BBTown ja genau bzw die Ebene macht keinen Sinn weil man nur eine Hue Bridge mit dem Adapter verbinden kann. Somit tut Hue.0 eigentlich sinnvoller Weise die Bridge selbst darstellen. Nur stieß das für bestehende Installationen wegen Unbenennung auf wenig Gegenliebe, weshalb ich auch ermögliche die DPs wie früher anzulegen. Jetzt ist es mir wohl mal auf die Füße gefallen.
Grundsätzlich wenn du sowas vermeiden möchtest würde ich den Verwahrungsort auf stable stellen @Mauflo, da kommen nur Versionen rein die schon einige Zeit getestet wurden. -
@foxriver76 na ja, wir wollen die Fehler ja gemeinsam mit dir finden um dich zu beschäftigen damit Du dir die Nächte um die Ohren schlagen kannst
-
@foxriver76 Nein ist schon ok. Ein bisschen thrill und Unterstützung der Entwickler beim debugging braucht es schon. Wir wollen ja alle, dass das Projekt erfolgreich weitergeht!
Im Übrigen habe ich das Gefühl, dass seit Herbst 19 der ganze ioBroker wesentlich stabiler läuft. Es kommen immer weniger Warnings und Error Meldungen im log vor. Wie gesagt ihr macht tolle Arbeit!
-
Alt
Neu
Habe das selbe Problem.. wenn ich es also richtig verstehe ist das so gewollt das das ganze HUE jetzt untereinander steht statt sauber in "Ordnen"? (hue.0.WZr_01_Hue_color | Bild 01)
-
@conectas
gucksu hier https://forum.iobroker.net/post/419640 -
Sorry verstehe ich trotzdem nicht, was hat das mit den Geräten Ordnern zu tun
WZr_01_Hue_color
WZr_02_Hue_color
WZr_03_Hue_colorhue.0
--> WZr_01_Hue_color
----> .onund das es jetzt WZr_01_Hue_color_on unterstich statt WZr_01_Hue_color.on Punkt
-
mal abgesehen das wenn ich in tab-objects -> hue.0.WZr_02_Hue_color_on auf true setzt das nicht geht..?
Nachtrag: sehe gerade das es Update hue from @3.2.5 to @3.2.8 gibt.. mal sehen.
Nachtrag II: in @3.2.8 wieder da
