@Segway sagte in [gelöst] Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Ist linkeddevices NICHT für den js-controller ?

nicht durcheinanderbringen:
linked devices ist ein Adapter, der natürlich unter dem js-controller läuft.

die Alias-Funktion des js-controllers ist jedoch kein Adapter

Leute Leute Leute.
Macht es doch mal kompliziert. Warum immer mehrere Wege ???????
Hab jetzt grad kein nerv darauf. Projekt kommt ganz unten auf den Stapel ... mir egal ... muß ich halt später alles per Hand ändern

@Segway sagte:

ich verstehe was das Thema ALIAS angeht grad nur noch Bahnhof

Siehe hier.

Danke, da hab ich dann auch Lesestoff

ich verstehe was das Thema ALIAS angeht grad nur noch Bahnhof

Siehe hier.

Ist linkeddevices NICHT für den js-controller ?

nicht durcheinanderbringen:
linked devices ist ein Adapter, der natürlich unter dem js-controller läuft.

die Alias-Funktion des js-controllers ist jedoch kein Adapter

@Segway sagte in [gelöst] Probleme mit HmIP-SFD über piVCCU und hm-rpc:

alias.0 ist auch ein Adapter

Welcher denn?

Also, ich verstehe ja anscheinend wieder nur die Hälfte.
So wie ich das sehe gibt es einen Adapter

• devices
  UND
• linkeddevices

Warum ? Keine Ahnung ! Unterschied ? Keine Ahnung !
Das eine wird unter Objekte dann unter alias.0 geführt und das andere wohl unter linkeddevices.0

@paul53 sagte in [gelöst] Probleme mit HmIP-SFD über piVCCU und hm-rpc:

@Segway sagte:

Nö, alias.0 ist auch ein Adapter

Nein, Datenpunkte unter "alias.0" erfahren eine Sonderbehandlung durch den js-controller: Spiegelung der Zustände von Adapter-Datenpunkten.

Sehe es mir nach aber ich verstehe was das Thema ALIAS angeht grad nur noch Bahnhof was für was ist. Ist linkeddevices NICHT für den js-controller ?

Nö, alias.0 ist auch ein Adapter

Nein, Datenpunkte unter "alias.0" erfahren eine Sonderbehandlung durch den js-controller: Spiegelung der Zustände von Adapter-Datenpunkten.

alias.0 ist auch ein Adapter

Welcher denn?

@Segway sagte in [gelöst] Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Es gibt ja alias.0 und linkeddevices.0

Das sind zwei verschiedene paar Schuhe. linkeddevices ist ein Adapter, Aliase sind selbst die Datenpunkte, die du (ggf. mit Umrechnungen) selbst erzeugst

Nö, alias.0 ist auch ein Adapter

Aber wie gehst du nun vor mit den ALIASSEN ?

noch gar nicht.

@Segway sagte in [gelöst] Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Es gibt ja alias.0 und linkeddevices.0

Das sind zwei verschiedene paar Schuhe. linkeddevices ist ein Adapter, Aliase sind selbst die Datenpunkte, die du (ggf. mit Umrechnungen) selbst erzeugst

@Segway sagte in [gelöst] Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Dann noch die Skripte sowie javascript.0 und userdata.0

Wo ist dort das Problem?
Bei Skripten ist doch entscheidend, dass du im Skript mit den Alias arbeitest, damit das in den 0_Userdata.0 abgelegte Ergebnis immer von den richtigen Quellen erzeugt wird

@Segway sagte in Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Alias hab ich mal angefangen aber da mach ich schon wieder eine zusätzliche Baustelle auf weil ich das schon wieder nicht raffe was das wie wo wann warum macht.

da sind wir schon zwei

Ich komme nochmal darauf zurück. Können das auch gerne in einen separaten Thread legen wenn du magst.
Aber wie gehst du nun vor mit den ALIASSEN ?

Es gibt ja alias.0 und linkeddevices.0
Dann noch die Skripte sowie javascript.0 und userdata.0

I AM LOST :man-shrugging: :man-shrugging: :man-shrugging:

Denke du bist halt einer der wenigen der mehrere ioBroker die nicht in einem Multihost vereint sind zu der gleichen CCU verbindet

Denke ich auch.
Das sind halt parallel laufende Testsysteme.

@foxriver76 sagte in [gelöst] Probleme mit HmIP-SFD über piVCCU und hm-rpc:

es macht wohl nur beim HMIPServer Probleme

und deshalb hatte ich erst nicht daran gedacht, dass es mit der "eindeutigen" ID klappen könnte.
Bleibt nur noch das Luxusproblem, dass zwei identische Hostnamen, dann wieder zu dem Problem führen würden

Weiss nicht ob ich das backup einfach in eine piVCCU oder debmatic einladen kann / soll / darf.

kannst/darfst du!

@Segway sagte in Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Alias hab ich mal angefangen aber da mach ich schon wieder eine zusätzliche Baustelle auf weil ich das schon wieder nicht raffe was das wie wo wann warum macht.

da sind wir schon zwei

Ja, ich tue mich da echt schwer. Anscheinend gibt es ja ja auch schon wieder mehrere Möglichkeiten, einmal mit diesem alias Adapter oder da war noch was anderes. Keine Ahnung raff das nicht, daher kommt das ganz unten auf die todo-Liste

bleibt immer noch die Möglichkeit ein Backup der piVCCU mit allen ihren möglichen Leichen einfach in die piVCCU3 zu spielen

Tja ich hab ja eine CCU2. Weiss nicht ob ich das backup einfach in eine piVCCU oder debmatic einladen kann / soll / darf.

Auch keine Scripte/Blocklys?

Doch aber noch nicht viele, so 10 Stück insgesamt. Die meisten laufen (noch) in der CCU2

Habe den Thread auf [gelöst] gesetzt

Alias hab ich mal angefangen aber da mach ich schon wieder eine zusätzliche Baustelle auf weil ich das schon wieder nicht raffe was das wie wo wann warum macht.

da sind wir schon zwei

bleibt immer noch die Möglichkeit ein Backup der piVCCU mit allen ihren möglichen Leichen einfach in die piVCCU3 zu spielen

aber wie du so schön schreibst:

@Segway sagte in Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Alles irgendwie hat Vor- und Nachteile.

Deswegen schiebe ich es schon so lange vor mir her. Habe auch deswegen schon länger keine neuen Geräte mehr angelernt, da es "sowieso keinen Zweck hat", jetzt aber doch etwa 20 neue Geräte.
Und schon ist die Hemmschwelle für einen sauberen Neustart noch höher

@Segway sagte in Probleme mit HmIP-SFD über piVCCU und hm-rpc:

ne vernünftige View habe ich gar nicht bei mir

Auch keine Scripte/Blocklys?

@Homoran sagte in Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Ich habe auch noch nicht alle Antworten, weil es immer mehrere Möglichkeiten gibt.

"Einfachster" Plan

• alle Geräte von der piVCCU mit Rücksetzung in den Werkzustand ablernen
• Abschalten der piVCCU
• neue piVCCU3 aktivieren
• alte IP vergeben
• alle Geräte hier anlernen

Anschließend müsste alles wieder laufen

Das wird auch bei mir bestimmt einiges an Zeit verschlingen und bestimmt binnen eines Tages machbar sein. Aber steht auch auf meinem Zettel die Variante

alternativ
Da das Ganze wahrscheinlich länger dauert, kann man es so machen, wie du es vorschlägst

• piVCCU mit anderer IP starten
• weitere Instanzen von Hm-rega und hm-rpc für die piVCCU3 anlegen
  • in allen Views und Programmen ändern sich dadurch die IDs
  • wäre ein Anlass ab sofort nur noch mit Alias zu arbeiten ;-)
• Geräte sukzessive umziehen
• abschließend piVCCU deaktivieren und die unnötigen Instanzen löschen

Naja ne vernünftige View habe ich gar nicht bei mir, weil ich da seit Monaten rumhample um die beste Grundversion für mich zu erkennen. Alles irgendwie hat Vor- und Nachteile.
Alias hab ich mal angefangen aber da mach ich schon wieder eine zusätzliche Baustelle auf weil ich das schon wieder nicht raffe was das wie wo wann warum macht.

@Segway sagte in Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Ob piVCCU oder debmatic weiss ich noch nicht

bei VM bleibt nur die debmatic

müsste gehen, allerdings HmIP-wired und der HAP zur Reichweitenverlängerung geht nur mit dem großen Funkmodul

Würde eh das große Modul bestellen mit zus. der USB2-Platine

Auf jeden schonmal DANKE für den Input

Ich habe auch noch nicht alle Antworten, weil es immer mehrere Möglichkeiten gibt.

"Einfachster" Plan

• alle Geräte von der piVCCU mit Rücksetzung in den Werkzustand ablernen
• Abschalten der piVCCU
• neue piVCCU3 aktivieren
• alte IP vergeben
• alle Geräte hier anlernen

Anschließend müsste alles wieder laufen

alternativ
Da das Ganze wahrscheinlich länger dauert, kann man es so machen, wie du es vorschlägst

• piVCCU mit anderer IP starten
• weitere Instanzen von Hm-rega und hm-rpc für die piVCCU3 anlegen
  • in allen Views und Programmen ändern sich dadurch die IDs
  • wäre ein Anlass ab sofort nur noch mit Alias zu arbeiten ;-)
• Geräte sukzessive umziehen
• abschließend piVCCU deaktivieren und die unnötigen Instanzen löschen

@Segway sagte in Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Ob piVCCU oder debmatic weiss ich noch nicht

bei VM bleibt nur die debmatic

@Segway sagte in Probleme mit HmIP-SFD über piVCCU und hm-rpc:

Geht dann eigentlich HM, HM-IP und HM-wired ?

müsste gehen, allerdings HmIP-wired und der HAP zur Reichweitenverlängerung geht nur mit dem großen Funkmodul

Ob piVCCU oder debmatic weiss ich noch nicht aber meine Frage lautet:
Wie gehst du vor um nach und nach alle deine Devices von der alten CCU aufs neue System zu bekommen ?

Lässt du im iobroker mehrere Instanzen der Homematic laufen ?
Praktisch eine für die alte CCU mit IP und eine andere für die neue CCU mit anderer IP ?
und das dann für jeden Prozess sprich CUxD, reg, rpc usw.

Nachtrag:
Geht dann eigentlich HM, HM-IP und HM-wired ?

Hier nochmal das aktuelle log
RasPi-PiVCCU-2021-01-04.log

Also bin leider auch etwas ratlos wo wir da ansetzen können

Ich kann wahrscheinlich Entwarnung geben.

Bin wieder gerade zurück und alle Installationen hatten den Timestamp bei 22:48
Nachdem vorhin ohne neustart der Instanz auf dem Produktiven System, nach einem Crash des Browsers dort auch die aktuellen Werte drin waren habe ich jetzt mal den Browsercache gelöscht und siehe da, alle Timestamps aller Installationen wieder aktuell.
Bei einem reload der Objekte Seite half das nicht.

Ich habe gestern eine neue piVCCU3 installiert und wollte eigentlich sukzessive alle Geräte (ca. 150!!!) manuell dorthin umziehen, weil ich das Setup bereits seit der CCU1 über lxccu, YAHM und diversen piVCCU Versionen mitschleppe.

Werde morgen, wenn es die Zeit erlaubt doch entgegen dieses Plans ein Backup aus der piVCCU(2) einspielen und testen

Danke erst einmal für deine Unterstützung!

Also bin leider auch etwas ratlos wo wir da ansetzen können, außer die CCU zu updaten, aber obs daran liegt..