Umzug von HM-CFG-USB2/hmland auf Raspberrymatic mit HMIP dazu

[SonOfAbaddon]

Hallo zusammen,

da ich mir nun weitere HM-Geräte in den Zoo holen will werde ich zum erstem Mal hmIP kaufen. Damit BidCos/HMclassic und hmIP laufen habe ich vor Raspberrymatic mit dem hmIP-RF-USB einzusetzen.
Szenario:

IST:
- FHEM und Seitendienste im Docker auf einem HP ThinClient
- HM über HM-CGF-USB2 im host auf dem ein hmland Dienst läuft
- Anbindung der HM-Geräte über VCCU, die über den Stick als HMLAN bedient wird
- ca. 20 HM-Aktoren (Fenster, Thermostat, HM-UNI-Thermometer)

SOLL:
- FHEM und Seitendienste im Docker auf einem HP ThinClient
- HMclassic & hmIP über hmIP-RF-USB am host
- Raspberrymatic in Docker, HMCCU in FHEM
- bestehende HMclassic an neues Konstrukt anbinden und hmIP anlernen (Wenn die Geräte eintreffen)

Raspberrymatic läuft, der hmIP-Stick wird erkannt, in der FHEM-HMCCU ist Raspberrymatic als "active" anerkannt.

Meine Frage nun: Wie komme ich mit den Bestandgeräten von der hmland/bidCos-Stick/VCCU-Kombination am Besten auf die neue Kombi aus hmIP-Stick/Raspberrymatic/HMCCU ohne die Geräte in FHM zu verlieren? Da ich jede Menge Verknüpfungen und Abhängigkeiten gebaut habe würde ich ungern die alten Geräte aus den Routinen verlieren und "neu anfangen" müssen. Ich brauche die Geräte nicht zwingend in Raspberrymatic, die gesamte Logik kann sich ruhig weiter in FHEM abspielen.

Oder gibt es noch einen anderen Weg mit den gegebenen Geräten, der geeigneter erscheint?

Danke für Input vorab!

[frank]

- HMclassic & hmIP über hmIP-RF-USB am host

der kann nur hmip

Meine Frage nun: Wie komme ich mit den Bestandgeräten von der hmland/bidCos-Stick/VCCU-Kombination am Besten auf die neue Kombi aus hmIP-Stick/Raspberrymatic/HMCCU ohne die Geräte in FHM zu verlieren? Da ich jede Menge Verknüpfungen und Abhängigkeiten gebaut habe würde ich ungern die alten Geräte aus den Routinen verlieren und "neu anfangen" müssen. Ich brauche die Geräte nicht zwingend in Raspberrymatic, die gesamte Logik kann sich ruhig weiter in FHEM abspielen.

warum lässt du dann bidcos nicht wie es ist?

[MadMax-FHEM]

Meine Frage nun: Wie komme ich mit den Bestandgeräten von der hmland/bidCos-Stick/VCCU-Kombination am Besten auf die neue Kombi aus hmIP-Stick/Raspberrymatic/HMCCU ohne die Geräte in FHM zu verlieren? Da ich jede Menge Verknüpfungen und Abhängigkeiten gebaut habe würde ich ungern die alten Geräte aus den Routinen verlieren und "neu anfangen" müssen. Ich brauche die Geräte nicht zwingend in Raspberrymatic, die gesamte Logik kann sich ruhig weiter in FHEM abspielen.

Wirst du eh, da ja die Defines der Devices GANZ ANDERS SIND: CUL_HM (was du aktuell hast) vs. HMCCU (was du dann hast)

Es gibt eine Möglichkeit zumindest die Geräte nicht neu anlernen zu müssen: die bestehende HMID aus fhem in die CCU/raspberrymatic "pfriemeln" (gibt es Threads im Forum)
EDIT: sofern deine neue Plattform bidCos unterstützt, siehe Anmerkung von Frank (wobei ich dachte dass der Stick das mittlerweile kann?)

Ich würde ja die bestehenden (und auch zukünftige) bidCos Geräte per CUL_HM lassen und nur die neuen HMIP an der Raspberrymatic anlernen und die dann per HMCCU nach fhem...

Du kannst/könntest ja bidCos und HMIP Geräte auch nicht direkt verbinden, selbst wenn alle an der CCU/Raspberrymatic wären.

EDIT:

Vorteile von "zweigleisig" -> die Geräte/Devices die du hast funktionieren und die Logiken damit passen / für neue Geräte musst du eh neue Devices und Logiken anlegen

Nachteile von "zweigleisig": du musst bei CUL_HM "am Ball bleiben" und dich in HMCCU einarbeiten (aber das musst du eh)

Gruß, Joachim

[frank]

EDIT: sofern deine neue Plattform bidCos unterstützt, siehe Anmerkung von Frank (wobei ich dachte dass der Stick das mittlerweile kann?)

dann bin ich vielleicht nicht auf aktuellem stand?

[SonOfAbaddon]

der kann nur hmip
warum lässt du dann bidcos nicht wie es ist?

Da der hmIP-Stick  Firmware 4.4.16 auch BidCos können soll wollte ich alles vereinen. Auch um den Wust an Virtuellen Geräten und eingesteckten devices klein zu halten.

[MadMax-FHEM]

Auch um den Wust an Virtuellen Geräten und eingesteckten devices klein zu halten.

Virtuelle Geräte?
Temperatursensoren?

Ich habe irgendwie im "Ohr", dass das mit CCU nicht (so einfach) gehen soll...

Gruß, Joachim

[SonOfAbaddon]

Wirst du eh, da ja die Defines der Devices GANZ ANDERS SIND: CUL_HM (was du aktuell hast) vs. HMCCU (was du dann hast)

Es gibt eine Möglichkeit zumindest die Geräte nicht neu anlernen zu müssen: die bestehende HMID aus fhem in die CCU/raspberrymatic "pfriemeln" (gibt es Threads im Forum)
EDIT: sofern deine neue Plattform bidCos unterstützt, siehe Anmerkung von Frank (wobei ich dachte dass der Stick das mittlerweile kann?)

Ich würde ja die bestehenden (und auch zukünftige) bidCos Geräte per CUL_HM lassen und nur die neuen HMIP an der Raspberrymatic anlernen und die dann per HMCCU nach fhem...

Du kannst/könntest ja bidCos und HMIP Geräte auch nicht direkt verbinden, selbst wenn alle an der CCU/Raspberrymatic wären.

EDIT:

Vorteile von "zweigleisig" -> die Geräte/Devices die du hast funktionieren und die Logiken damit passen / für neue Geräte musst du eh neue Devices und Logiken anlegen

Nachteile von "zweigleisig": du musst bei CUL_HM "am Ball bleiben" und dich in HMCCU einarbeiten (aber das musst du eh)

Gruß, Joachim

OK, wenn die Logik von HM_CUL und HMCCU komplett anders ist werde ich wohl einmal in den sauren Apfel beißen müssen und nach und nach umziehen. Muss ich einmal durch die Konfig gehen und sichten wo ich die einzelnen Geräte eingebunden habe und dort austauschen (das HM_CUL erst entfernen, wenn überall das HMCCU mit eingebunden ist)

Virtuelle Geräte?
Temperatursensoren?

Ich habe irgendwie im "Ohr", dass das mit CCU nicht (so einfach) gehen soll...

Gruß, Joachim

Ich habe derzeit die gelöteten HM-UNI Temperatursensoren über virtuelle Geräte an die Thermostate gekoppelt (Abgleich klassisch über DOIF), weil ich bisher zu faul war die direkt zu koppeln (wenn es geht HM-UNI zu HM-nativ). Liegt daran, dass die Temperaturen vorher von LaCrosse-Sensoren kamen. Historisch gewachsen.

[MadMax-FHEM]

OK, wenn die Logik von HM_CUL und HMCCU komplett anders ist werde ich wohl einmal in den sauren Apfel beißen müssen und nach und nach umziehen. Muss ich einmal durch die Konfig gehen und sichten wo ich die einzelnen Geräte eingebunden habe und dort austauschen (das HM_CUL erst entfernen, wenn überall das HMCCU mit eingebunden ist)

Die physischen Geräte können aber nur an einer Zentrale hängen!
(ja man kann [wie geschrieben] die HMID -> "Kennung" der Zentralen auch der CCU "unterschieben" aber 2 Herren gleichzeitg geht eher schief)

D.h. wenn du ein Gerät "umhängen" willst, dann bei fhem/CUL_HM ablernen (oder zurücksetzen / Achtung, wenn AES mit EIGENEM Schlüssel im Spiel ist) und bei der CCU neu anlernen (wenn eben neue HMID, also die bestehende nicht "untergeschoben" wurde) und dann eben das entsprechende HMCCU-Device in fhem anlegen (lassen).

Du musst dir ja nur mal ansehen, wie sich die Device-Definitionen zwischen CUL_HM und HMCCU unterscheiden und dann verstehst du was ich meine

Ich habe derzeit die gelöteten HM-UNI Temperatursensoren über virtuelle Geräte an die Thermostate gekoppelt (Abgleich klassisch über DOIF), weil ich bisher zu faul war die direkt zu koppeln (wenn es geht HM-UNI zu HM-nativ). Liegt daran, dass die Temperaturen vorher von LaCrosse-Sensoren kamen. Historisch gewachsen.

Naja, wenn du das mittels DOIF gelöst hast, dann geht das weiterhin allerdings halt dann mit den neuen HMCCU-Devices...
...d.h. DOIF anpassen.

Gruß, Joachim

[SonOfAbaddon]

Die physischen Geräte können aber nur an einer Zentrale hängen!
(ja man kann [wie geschrieben] die HMID -> "Kennung" der Zentralen auch der CCU "unterschieben" aber 2 Herren gleichzeitg geht eher schief)

D.h. wenn du ein Gerät "umhängen" willst, dann bei fhem/CUL_HM ablernen (oder zurücksetzen / Achtung, wenn AES mit EIGENEM Schlüssel im Spiel ist) und bei der CCU neu anlernen (wenn eben neue HMID, also die bestehende nicht "untergeschoben" wurde) und dann eben das entsprechende HMCCU-Device in fhem anlegen (lassen).

Du musst dir ja nur mal ansehen, wie sich die Device-Definitionen zwischen CUL_HM und HMCCU unterscheiden und dann verstehst du was ich meine


Naja, wenn du das mittels DOIF gelöst hast, dann geht das weiterhin allerdings halt dann mit den neuen HMCCU-Devices...
...d.h. DOIF anpassen.

Gruß, Joachim

Ich meinte auch schon ablernen und neu anlernen. Wird dabei auch das FHEM-Device komplett aus der Config entfernt wie beim regulären Löschen? Ich hätte gedacht, ich kann die abgelernte Hülle in FHEM stehen lassen (dysfunktional) bis ich die neu angelernte Variante an alle Stellen geschoben habe.
Ich glaube ich teste das am WE einfach mit einem unkritischen Fenstersensor.

Da früher die Lacrosse-Werte irgendwie in HM kommen mussten habe ich die virtuellen HM-Thermometer angelegt und regelmäßig über DOIF befüttert. Diese Virt-Temp sind dann mit dem Weather-Kanal vom Thermostat gekoppelt. Beim Umstieg auf die HM-UNI Thermometer hab nicht versucht diese direkt mit dem Wetter-Kanal zu koppeln, weil ich mir nicht sicher war, ob die HM-UNI als "echte" HM-Geräte anerkannt werden.
Da ich jetzt eh an die Thematik muss werde ich natürlich versuchen die Virt-Temp rauszulassen. Ich könnte ja auch mal versuchen die HM-UNIs direkt ans Thermostat zu koppeln wie auch in HM vorgesehen. Die Liste der Schande könnte mal abgearbeitet werden, diese virtuellen Geräte sind mir seit dem Wegfall von LaCrosse bei mir ein Dorn im Auge. Aber: Never change a running system...

[MadMax-FHEM]

Ich meinte auch schon ablernen und neu anlernen. Wird dabei auch das FHEM-Device komplett aus der Config entfernt wie beim regulären Löschen? Ich hätte gedacht, ich kann die abgelernte Hülle in FHEM stehen lassen (dysfunktional) bis ich die neu angelernte Variante an alle Stellen geschoben habe.
Ich glaube ich teste das am WE einfach mit einem unkritischen Fenstersensor.

Nein es wird beim Ablernen in fhem nichts gelöscht auch nicht, wenn du das Gerät zurücksetzt.

Das Device in fhem wird halt nicht mehr "versorgt" und u.U. ist der ActionDetector "beleidigt" bzgl. dem nicht mehr "gefütterten" Device

Ja, üben ist sicher nicht verkehrt...

Wobei ich ja trotzdem (wenn ich umsteigen bzw. um HMIO erweitern würde) die bestehenden Devices lassen würde und nur die neuen HMIP eben per HMCCU...
...aber es ist dein System und dein Aufwand, den du treiben musst

Viel Spaß/Erfolg, Joachim

[SonOfAbaddon]

Wobei ich ja trotzdem (wenn ich umsteigen bzw. um HMIO erweitern würde) die bestehenden Devices lassen würde und nur die neuen HMIP eben per HMCCU...
...aber es ist dein System und dein Aufwand, den du treiben musst

Das Problem ist, dass Raspberrymatic beim Containerstart versucht sich den schon in hmland eingebundenen HM-CFG zu schnappen, was er aber folgerichtig nicht schafft, so dass der rfd nicht sauber anstartet. In Raspberrymatic ist der hmIP-CFG voll sichbar, aber bis die HMIP-Aktoren kommen könnte ich nur BidCos dranhängen um zu sehen, ob das egal wäre.

Für einen sauberen Start des gesamten Hosts (wenn denn mal nötig) müsste ich erst den HM-CFG abziehen, alle Container starten damit Raspberrymatic den BidCos-Stick nicht kennt und nur mit dem hmIP-CFG arbeitet, dann den Stick einstecken und hmland anstarten. Finde ich nicht sonderlich galant.


Danke auf jeden Fall für euren Input. Ich hätte gedacht, dass man die bestehenden Devices wie bei MQTT nur auf einen anderen Sender umlegen muss, aber ist ja bald wieder Winterzeit wo man in der Stube werkeln kann.