UNSOLVED deCONZ, Phoscon und Objekte Problem

[Jey Cee]

@Bielefelder81 das da noch ein Gateway Autaucht in der Phoscon App liegt an der Automatischen suche von Phoscon und deinem Internetanschluß. Das hat irgendwas damit zu tun das sich heute viele Internet Abschlüße eine IPv4 Addresse Teilen.
Dresden Elektronik weiss davon.

Das mit den Namen war schon immer so, Phoscon macht da was eigenes Intern und die Namen die vergeben werden wenn man ein Gerät anlernt über Phoscon werden nicht über die API ausgegeben. Das was in ioBroker ankommt sind die Namen wie sie in deConz gespeichert werden.
Wenn man die Namen später in Phoscon ändert wird das dann auch deConz mitgeteilt und dort geändert, dann sieht das auch der Adapter.

@Bielefelder81 sagte in deCONZ, Phoscon und Objekte Problem:

Die Gruppe wird aber in der Phoscon App auch nirgends namentlich erwähnt und somit kann man sie auch dort nicht ändern.

Dieese Gruppen werden von deConz oder Phoscon angelegt. Denn Sinn dahinter hab ich auch nicht verstanden. Die Gruppe und der Sensor existieren unabhängig von einander, heist der Gruppe ist egal wie du den Sensor benennst.

@Bielefelder81 sagte in deCONZ, Phoscon und Objekte Problem:

Dazu kommt dann auch noch, dass wenn ich einen Sensor in der Phoscon App lösche, dann ist er nachwievor im deCONZ Adapter bzw Objekt vorhanden - trotz Adapter Neustart etc. Ich kann die Sensoren nur über die Objekte hart rauslöschen...

Das ist so.

@Bielefelder81 sagte in deCONZ, Phoscon und Objekte Problem:

Außerdem macht es mich wahnsinnig, dass die Nummern für die Sensoren immer hochzählen und nicht die nächst freie Zahl verwenden.

Sei froh das es so ist. Bei anderen werden die freien Nummern belegt was zur Folge hat das sie keine Daten für diese Geräte bekommen weil deConz denkt das es dieses Geräte nicht mehr gibt. Diese Lücken entstehen wenn man Geräte löscht.

[Bielefelder81]

@Jey-Cee sagte in deCONZ, Phoscon und Objekte Problem:

@Bielefelder81 Das was in ioBroker ankommt sind die Namen wie sie in deConz gespeichert werden.
Wenn man die Namen später in Phoscon ändert wird das dann auch deConz mitgeteilt und dort geändert, dann sieht das auch der Adapter.

Hi @Jey-Cee und danke für deine Antwort.
Leider ist dem bei mir ja nicht so. Wenn ich über die Phoscon App ein Gerät anlege und es über die Phoscon App namentlich ändere, dann taucht es ja nicht im Adapter bzw in den Objekten mit richtigem Namen auf.

Ich muss dafür ja erst den Adapter stoppen, den Ordner der Sensoren in den Objekten löschen und erneut den Adapter starten. Dann tauchen alle Ordner wieder auf, aber mit korrektem Namen...

[onkel-ede]

@Jey-Cee
Ich weiß gerade nicht, ob mein Problem im Zusammenhang mit dem Thema steht.
Ich habe den deconz-Adapter noch in der Version 1.3.10 laufen.
Der conbee-II-Stick steckt an Synology NAS 218+.
Iobroker und die Software laufen in docker-Containern (marthoc-deconz).
Läuft auch alles stabil.
Ich stelle in letzter Zeit immer wieder Probleme bei der Beleuchtungssteuerung fest.
Schalte ich ein Licht über die phoscon-App funktioniert alles.
Ändere ich den Wert direkt im Objekt funktioniert es auch (deconz.0.Lights.3.on von true auf false und umgekehrt).
Steuere ich jedoch die Änderung des Wertes per javascript, wird diese zwar korrekt im Datenpunkt angezeigt, aber der Wert erreicht die phoscon-App nicht und das Licht reagiert auch nicht.

[Asgothian]

@onkel-ede

Hallo,

das Problem befindet sich im Skript. Du aktualisierst die Datenpunkte nur, um diese Anpassungen in den Adapter als Steuerbefehle zu senden musst du den "steuere" Baustein an Stelle des "Aktualisiere" Baustein nutzen.

A.

[StephanJanine]

also ich habe das gleiche Problem mit den Namen. Sensor in der phoscon app angelernt und Namen geändert aber im ioBroker tauchen die nur mit "Presence 2" beziehungsweise 5 auf... funktioniert zwar aber ist unschön.

[Phil Ipp]

@StephanJanine

hatte diese Problematik auch.
Nach Installation einer neuen deconz Instanz, die alte einfach vorerst deaktiviert, waren alle Namen übergeben und alles sauber aufgelistet in den Objekten zu finden.
Nun muss ich halt "nur" noch alle Skripte anpassen

[Wildbill]

@Phil-Ipp Da wäre es vermutlich einfacher gewesen, den Deconz-Adapter zu stoppen, einmal alle Datenpunkte des Adapters im Objektbaum zu löschen (den gesamten Deconz-Zweig) und den Adapter wieder zu starten. Dann wird alles neu eingelesen und aktuell benamt. Hätte Dir vermutlich bei den meisten (allen) Skripten eine manuell Anpassung erspart.
@StephanJanine Solltest Du mal so versuchen, bevor Du was anderes testest.

Gruss, Jürgen

[Phil Ipp]

@Wildbill

guter Punkt - danke für den nützlichen Hinweis!
Weiß auch genau, wann ich den brauche: Sobald das nächste Gerät bei deconz dazukommt... ,)

Aber muss man die Scripte dann nicht auch anpassen, weil sich die Objektnamen geändert haben?

[Asgothian]

@Phil-Ipp
Nein. Die Text Benennungen der Geräte gehen nicht in die Adressen der Datenpunkte ein, nur in deren Benennung.

A.

[StephanJanine]

@Wildbill werde ich heute Abend mal versuchen. danke für den Hinweis.

[StephanJanine]

@Wildbill vielen dank, das hat funktioniert. also deconz Instanz deaktiviert. den kompletten Objektbaum von deconz gelöscht und erneut aktiviert. ich musste den api key erneut eingeben aber danach wurde alles mit Namen übertragen.
danke

[Toniinot]

Hallo zusammen,

Wollte mich auch kurz einklinken.

Nach einem update des Deconz Adapters auf 2.0.5 den ich gestern gemacht habe, habe ich ein sehr komische Objekt Struktur im Deconz Objektbaum.

Zu den ursprünglichen Objekt IDs, die auch normal Nummeriert waren und den Namen aus der Phoscon app korrekt übernommen haben, habe ich jetzt ein zweites Objekt für alle Geräte die unter einer komischen Objekt ID vergeben sind.

Nach stoppen des Adapter und komplettes löschen des Deconz Objektbaums werden die Geräte nur noch einmal aufgeführt aber leider mich dieser komischen Objekt ID.

Kennt jemand dieses Problem und gibt es eventuell eine Lösung?

[Asgothian]

@Toniinot sagte in deCONZ, Phoscon und Objekte Problem:

Kennt jemand dieses Problem und gibt es eventuell eine Lösung?

Das ist kein Problem, sondern eine systematische Umstellung die beim Wechsel von der Version 1.x auf die Version 2.x vorgenommen wurde. Dieses ist also gewünscht. Wenn du den alten Objektbaum zurück haben willst musst du auf die neuste 1.x version zurück gehen.

In der 2.0.5 gibt es nebenbei noch ein paar Auffälligkeiten, so das es sein kann das sie bei Dir nicht so läuft wie du das brauchst. Bei mir geht es, aber bei meiner Installation in Schweden geht es nicht - da habe ich 2 Zigbee-Geräte die jeweils 2 Lasten schalten können, und daher auch als 2 Lampen in der Phoscon App aufgelistet werden - bei der 2.x version des Adapters ist nur eine der beiden Lasten schaltbar.

A.

[Toniinot]

@Asgothian said in deCONZ, Phoscon und Objekte Problem:

1.x

Ok. Dann weiß ich Bescheid. Gehe davon aus, dass die Version 2.x weiter entwickelt wird aber nicht die Version 1.x.

[Jey Cee]

@Toniinot sagte in deCONZ, Phoscon und Objekte Problem:

Gehe davon aus, dass die Version 2.x weiter entwickelt wird aber nicht die Version 1.x.

Genau so ist es.

[M.M.]

@jey-cee Ich habe heute die Verbindung zu 2 Fensterkontakten verloren. Manchmal reichte es, wenn ich die einfach resette und Phoscon hat sie dann unter der alten ID erkannt.

Diesmal habe ich sie im Phoscon Gateway gelöscht und neu angelernt. Leider musste ich dabei feststellen, dass die Objekt.ID weiter hochgezählt wurde anstatt die nächste freie ID zu nehmen (ich bin noch auf deCONZ 1.3.16).

Gibt es ein config file (ich nutze marthoc-deconz in einem Container auf einer Synology NAS) dass ich ändern kann um sowas in Zukunft anzupassen? Am Ende habe ich 30 Geräte und falls ich die alle mal neu synchronisiere, müsste ich alle Scripts anpassen weil sich vermutlich dann alle ID's ändern(?)

Beim Umstieg auf die 2.x müsste ich dies dann auch machen, oder gibt es hier eine Art von Mapping bei einem Update (deswegen bin ich noch auf der 1.x)?

[Jey Cee]

@m-m die ID kommt von deConz, da lässt sich nix machen.
Die Version 2 hab ich eingestampft.

[M.M.]

@jey-cee said in deCONZ, Phoscon und Objekte Problem:

@m-m die ID kommt von deConz, da lässt sich nix machen.

deCONZ speichert den Zustand des zigbee Netzwerk mitsamt der angelernten Komponenten in einer SQLite Datenbank.
Löscht man ein Gerät via Phoscon wird es „intern“ als gelöscht markiert, aber die ID wird nicht wieder freigegeben.
D.h. wenn man das gleiche Gerät wieder neu anlernt, bekommt es eine neue ID.

Da müsste man direkt an die SQLite DB ran und die liegt normalerweise unter

/root/.local/share/dresden-elektronik/deCONZ

Ich denke den Aufwand spare ich mir.

Danke Dir!

[M.M.]

Falls mal jemand das Gleiche Problem hat (und mit dem Disclaimer, dass Ihr Backups macht, nicht an geöffneten Datenbanken/Dateien herumexperimentiert und auch sonst wisst was ihr tut):

Hab ich gesagt, dass Phoscon (marthoc/deconz) nicht laufen sollte, damit die zll.db nicht geöffnet ist? Ok.

Ich habe mit SQLiteBrowser die SID in der Tabelle sensors wieder in die Reihenfolge gebracht, die ich brauchte. Wenn ein neuer Sensor angelernt wird, nimmt Phoscon einfach den nächsten größten freien Eintrag.

Beispiel:
11
12
14

dann wird der nächste Sensor die ID 15 erhalten.

Bei mir hat das problemlos funktioniert.