philips hue modul

[Thyraz]

Hallo Andre,

kann man eigentlich die HUEDevices in Fhem von original HueBridge einfach und schnell auf Conbee umziehen?

Der Umzug von der Bridge zum Stick in den jeweiligen Original Softwaretools hat super geklappt.
Ich habe die Birnen in der Hue App gelöscht, dann in Phoscon nach Lampen gesucht.

Mein Problem ist jetzt, dass ich die Lampen gern unter altem Namen mit den ganzen bisherigen Attributen übernehmen würde.
Ich habe ne Menge Userreadings, MQTT Publishs, dazu Grupen, Räume, Homebridgemappings...
Da arbeite ich erstmal ne Woche bis ich das alles aktualisiert habe. 

Die neuen Devices wurden alle durch das autocreate mit neuem IODev=conbee2 erstellt.
Nun hab ich jeweils das DEV und das Attribut IODEV vom passenden Conbee HueDevice in das alte HueDevice übernommen.

Damit klappt an sich auch alles:
Ich kann über beide FHEM Instanzen die Lampe steuern und es aktualisieren sich auch beide.
Lösche ich aber nun die neue HUEDevice Istanz, welche ich ja nicht benötige, dann kommen im Log solche Meldungen:

Code Auswählen Erweitern

conbee2: message for unknown device received: conbee2-1
Nach einem FHEM Neustart werden dann auch alle Conbee Huedevice Doubletten wieder angelegt.

Ist da nur irgendwas in den Internals noch falsch, dass er das nicht erkennt das ich umbiegen kann?
Oder hab ich keine Chance und muss die Attribute mühsam umkopieren?
(Plötzlich kommt mir mein HUE Gerätepark ziemlich umfangreich vor )

Grüße,
Tobias

[P.A.Trick]

Hi Tobias, ich stand vor demselben Problem. Ich habe (ja ja jetzt werde ich wieder totgeschlagen) FHEM gestoppt und die fhem.cfg manuell editiert.
Du musst in der Device Definition hue_bridge durch deCONZ ersetzen und die jeweilige ID anpassen. Danach FHEM wieder starten und dann sollte
alles klappen.
Mir ist kein anderer Weg bekannt, wie man das sonst machen kann.

[justme1968]

das problem ist das die device id mit der eine lampe im api angesprochen wird nicht bridge übergreifend eindeutig ist. das dies mal ein problem wird weil jemand mehr als eine bridge hat war am anfang kein thema

als die der erste mit mehr als einer bridge um die ecke gekommen ist war es zu spät die eindeutige serien nummer der lampe zur identifizierung zu verwenden. abgesehen davon das diese bei ikea gateway nicht gibt hätte das aber auch ein paar andere nebeneffekte. z.b. kann man dann nicht mehr einfach von hand ein device anlegen da man die serien nummer in der regel nicht kennt.

das hat zur folge das statt der eindeutigen serien nummer die kombination aus id und bridge als eindeutiger schlüssel verwendet wird. um die lampe intern in diversen datenstrukturen zu identifizieren. deshalb kann man zumindest rein von hand id und bridge im define nicht einfach ändern weil alle internen verknüpfungen dadurch nicht aktualisiert werden.

lange rede... kurzer sinn: nein das geht aktuell nicht und wäre auch nicht ganz einfach umzusetzen.

was aber geht wäre fhem anhalten, config anpassen und dann neu starten.


wenn es genügend fürsprecher gibt würde ich mir etwas einfallen lassen. ich könnte mir vorstellen das das modul automatisch schau ob die nachricht für ein unbekanntes device die gleiche serien nummer hat als ein schon bekanntes und dann das iodev automatisch wechseln. dafür bräuchte es dann aber auch einen willigen beta tester der mehrfach lampen umzieht und in kauf nimmt das es am anfang nicht reibungslos geht.

[Thyraz]

Ich habe (ja ja jetzt werde ich wieder totgeschlagen) FHEM gestoppt und die fhem.cfg manuell editiert.

Pfui! 

Gerade ist mir aufgefallen, dass das DEV wenn man es bei laufendem FHEM ändert wieder zurückgesetzt wird.
Ich hab also wie du DEV und Attr IODev angepasst, nur eben in laufendem Betrieb.

Wenn ich dann speichere und FHEM neu starte wird aus dem gerade angepassten DEF "2 IODev=conbee2" wieder "2 IODev=HueBridge".
Keine Ahnung ob das HUEBridge Modul hier noch Daten hält und das dann übers speichern / laden beim FHEM Neustarten wieder neu geschrieben wird.

Dann gehe ich halt auch mal den Weg des FHEM editierens (den ich in all den Jahren bisher erfolgreich gemieden habe. )

[P.A.Trick]

Pfui! 

------

Dann gehe ich halt auch mal den Weg des FHEM editierens (den ich in all den Jahren bisher erfolgreich gemieden habe. )

Mache vorher eine Sicherungskopie!

[stera]

Mit einer Kopie der RAW Definition, löschen des Device und angepasst wieder über das "+" importieren geht das doch recht schnell.
So habe ich nach und nach auch die Device rüber geholt.

Gruß,
Stefan

Pfui! 

Gerade ist mir aufgefallen, dass das DEV wenn man es bei laufendem FHEM ändert wieder zurückgesetzt wird.
Ich hab also wie du DEV und Attr IODev angepasst, nur eben in laufendem Betrieb.

Wenn ich dann speichere und FHEM neu starte wird aus dem gerade angepassten DEF "2 IODev=conbee2" wieder "2 IODev=HueBridge".
Keine Ahnung ob das HUEBridge Modul hier noch Daten hält und das dann übers speichern / laden beim FHEM Neustarten wieder neu geschrieben wird.

Dann gehe ich halt auch mal den Weg des FHEM editierens (den ich in all den Jahren bisher erfolgreich gemieden habe. )

[justme1968]

beim drüber nachdenken ist mir noch eine idee gekommen...

es gibt eine routine HUEDevice_IODevChanged, die wird intern verendet wenn man eine bridge umbenennt. hier muss auch die interne verknüpfung gerade gezogen werden. die habe ich eben mal erweitert um auch die id umzubiegen.

d.h. ab morgen nach dem update bitte mal probieren:

- {HUEDevice_IODevChanged('lampe', 'io alt', 'io neu', 'neue id')}
- danach die id auch noch von hand im DEF anpassen

statt io alt kann man auch undef angeben.


wenn das klappt baue ich noch ein das die id im DEF automatisch angepasst wird und das ganze automatisch aufgerufen wird wenn eine nachricht für eine bekannte serien nummer über ein neues io rein kommt.

[justme1968]

könnt ihr mal schauen ob das uniqueid internal beim wechechsel der bridge gleich bleibt? auch zwischen hue und deCONZ?

[justme1968]

so...

ich habe noch etwas gebastelt:

- die routine von oben setzt auch die id im def. d.h. es muss von hand nichts gemacht werden.
- wenn beim wechsel der bridge die uniqueid gleich bleibt sollte die das verschieben automatisch gehen

es muss dafür pollDevices in der (alten) bridge gesetzt sein und fhem darf zwischendurch nicht angehalten werden. sonst ist die uniqueid aus den internals weg.

ab morgen im update

[Thyraz]

Danke dir.

Unique ID bleibt gleich, trotz Umzug zur anderen Bridge.

Habe es eben mal aus dem SVN gezogen.
So ganz klappt es leider noch nicht.

Es wurde dennoch ein neues Device in FHEM angelegt statt das alte umzubiegen.
Nachdem ich dieses dann gelöscht habe, wurde das vorhandene Device dann doch plötzlich angepasst (DEV und attr IODev).
Anstatt einem message for unknown device received war diesmal das im Log:

Code Auswählen Erweitern


moving HUEDevice11 [00:17:88:01:02:9c:3e:89-0b] from HueBridge to conbee2
HUEDevice11: I/O device is conbee2


Das war dann auch im Device in FHEM so korrekt angezeigt.

Allerdings war nach einem Save und Fhem Restart dann doch wieder das alte IODev=xyz im DEF.
Attr IODev zeigte noch korrekt auf das neue IODev.

Es wurde dann aber auch wieder über Autocreate ein neues Device angelegt.


Kann man mit irgendwelchen Infos/Lists/... was dazu beitragen?
Ich hab auf alle Fälle noch einige Devices die umgezogen werden müssten und als Testballons für neue Versionen dienen können.

[justme1968]

autocreate wird nur beim fhem neustart aufgerufen. im betrieb nicht. d.h. ich verstehe nicht warum das neue device angelegt wird. steht dazu etwas im log? mit verbose 4? hilft es autocreate abzuschalten?

stimmt nach dem umzug das IODev im DEF?

du musst von hand save aufrufen. sonst bleibt ja die config gleich. das habe ich noch nicht eingebaut.

[Thyraz]

Also autocreate hat bei mir bisher alle Lichter in FHEM angelegt, sobald ich sie in Phoscon hinzugefügt habe.
Ohne Neustart von FHEM.
Bei Sensoren/Tastern musste ich hingegen händisch aktiv werden.

Ich teste es gleich nochmal mit abgeschaltetem autocreate.

Save hab ich vor dem Neustart wie gesagt gemacht.
Dennoch war danach wieder das alte IODev im DEF zu finden.

[Thyraz]

Hier noch das was im Log passiert ist:

Code Auswählen Erweitern


--> Davor ist mehrere Minuten nichts im Log zu sehen, war auch kein Neustart direkt davor

2020.01.14 21:12:16.385 3: conbee2_HUEDevice4: I/O device is conbee2
2020.01.14 21:12:16.410 2: conbee2: autocreated 1 devices
2020.01.14 21:15:40.622 3: harmony: IODev for device 35213790 is Harmony01
2020.01.14 21:15:40.624 3: harmony: IODev for device 33423468 is Harmony01
2020.01.14 21:15:40.626 3: harmony: IODev for device 35737686 is Harmony01

--> Hier hab ich dann das automatisch erstellte Device gelöscht woraufhin er das Device von der alten Bridge zugezogen hat:

2020.01.14 21:16:34.684 2: moving HUEDevice11 [00:17:88:01:02:9c:3e:89-0b] from HueBridge to conbee2
2020.01.14 21:16:34.684 3: HUEDevice11: I/O device is conbee2

--> Hier hab ich Save und danach ein Restart gemacht




[Thyraz]

Nun mit deaktiviertem autocreate.

Lampe in Hue App gelöscht und in Phoscon hinzugefügt, danach dann gleich das hier im FHEM Log:

Code Auswählen Erweitern


2020.01.14 21:54:34.701 2: moving HUEDevice9 [00:17:88:01:01:1c:ac:ad-0b] from HueBridge to conbee2
2020.01.14 21:54:34.701 3: HUEDevice9: I/O device is conbee2


DEF in Fhem von HUEDevice9 ist danach: 5 IODev=conbee2
Attr IODev: conbee2

Danach dann Save gedrückt und Fhem neu gestartet.
Nun ist DEF leider wieder: 5 IODev=HueBridge

Sehr komisch...

[justme1968]

das autocreate kommt im phoscon fall weil im api ein extra 'added' event für neue devices geschickt wird. dafür habe ich jetzt auch das verschieben eingebaut.

wenn autosave aktiv ist speichere ich jetzt nach dem verschieben.

wenn autosave nicht aktiv ist siehst du in fhemweb das rote fragezeichen.


warum im config die alte DEF landet verstehe ich aber gerade nicht...

bitte schau mal direkt nach dem verschieben das config file an. hat es einen neuen timestamp? was steht dort als DEF drin?