Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Homoran]

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

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!

[Homoran]

@foxriver76
Heute morgen -nach Hochfahren des PCs- waren die States aller drei Installationen auf dem aktuellen Stand.
Deine Änderung ist also sehr sinnvoll!

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

[Segway]

@Homoran
Hallo!
Ich lese aufmerksam die ganze Zeit mit, da Ichs selber grad kurz davor bin solange meine alte CCU2 noch läuft auf ein Neu-System umzustellen.
Werde das über eine VM machen und dabei dann das USB-Modul inkl. Funkmodul nehmen.

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 ?

[Homoran]

@Segway Viele Fragen ;-)

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

[Segway]

@Homoran
viele Fragen - viele Antworten DANKE

@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

[Homoran]

@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

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?

[foxriver76]

@Homoran habs veröffentlicht, schaden tuts auf keinen Fall. Im Zweifel kann man dadurch den Client im HM Log leichter zuordnen

[Homoran]

@foxriver76 Danke!

Habe den Thread auf [gelöst] gesetzt

[foxriver76]

@Homoran Gerne, und dein Log hat ja jetzt auch nicht mehr den removed interfaceid spam, also scheint schon daran zu liegen. Denke du bist halt einer der wenigen der mehrere ioBroker die nicht in einem Multihost vereint sind zu der gleichen CCU verbindet und die Namenskonflikte können ja nur in so einem Setting entstehen. + es macht wohl nur beim HMIPServer Probleme

[Segway]

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

@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

[Homoran]

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

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

kannst/darfst du!

[Homoran]

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

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

[foxriver76]

@Homoran ja man könnte auch einen Hash generieren Pro laufende Instanz, da wäre die Kollisionswahrscheinlichkeit sehr gering, aber denke das passt erst mal so. Villt änder ich es mal noch wenn ich den Adapter mal wieder anfasse.

[Segway]

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

@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:

[Homoran]

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

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]

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

@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

[Homoran]

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

alias.0 ist auch ein Adapter

Welcher denn?

[paul53]

@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.

[Segway]

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

@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 ?

[Homoran]

@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