Umzug/Migration von VCCU auf CCU2

Begonnen von Dirk070, 06 Februar 2018, 14:28:19

Vorheriges Thema - Nächstes Thema

Dirk070

Hallo zusammen,

nachdem ich feststellen musste, dass der HMLAN nicht mehr hergestellt wird und die neuen IP-Geräte eine CCU benötigen, werde ich in Kürze wohl oder übel migrieren.
Meine FHEM-Installation ist mittels einer VCCU aufgesetzt. Da ich einige Funktionen in FHEM integriert habe, möchte ich die Steuerung wie bisher über FHEM laufen lassen.

Erleichtert die VCCU einen Umzug auf die echte CCU2? Und wenn ja, wie gehe ich das am sinnvollsten an?

Danke vorab und viele Grüße,
Dirk

Beta-User

Das Thema hatten wir schon ein paar Mal, Kurzfassung:

Das sind grundverschiedene Welten (CUL_HM und CCU2). Du kannst dir allenfalls das pairing sparen, wenn du der CCU2 dieselbe HmID verpaßt wie du bisher nutzt. Ansonsten: Es muß alles neu gemacht werden, die Datenpunkte heißen anders.

Aber statt eines HMLAN kannst du ja auch irgendein anderes Interface nutzen - ich habe ganz gute Erfahrungen mit einem Pi-PCB-Modul an einem USB-Seriell-Wandler (CP2102). Geht aber auch auch vielfältige andere Art, wenn du keinen Pi direkt nutzen willst.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Dirk070

#2
Vielen Dank für Deine Antwort.

Ich habe FHEM auf einem Syno-NAS und 2 HMLAN's, diese per VCCU in FHEM eingebunden.

Gut, die selbe HMID könnte ich vergeben, damit spare ich das erneute Pairing. Immerhin.
Wenn dann die Namen der Devices gleich bleiben, müssten doch weiterhin die selben SET- Befehle etc. funktionieren.
Oder meinst Du das mit den "Datenpunkten", die dann anders heißen?

Update: Gerade hier gelesen, ok, die Readings etc. heißen anders: https://wiki.fhem.de/wiki/HMCCUDEV#Datenpunkte_und_Readings

Danke vorab.

Schöne Grüße,
Dirk

Beta-User

Yup, alles heißt anders...

Wenn du wegen der Installation auf einem NAS ein anderes Ersatzinterface suchst:
Das kann (für USB) jeder andere Rechner sein, der ser2net oä. bereitstellt, (für die Ansteuerung des Moduls direkt) ein MapleCUN (hat 2 serielle Schnittstellen frei, die über's LAN erreichbar wären) oder ein ESP8266, oder ein CUL-Device, also neben dem genannten Maple z.B. ein umgeflashter Cube (notfalls, "echte" HM-IO's sind besser).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Dirk070

Danke für die Hinweise und Anregungen.
Ich bastel' grundsätzlich gerne und komme auch aus der IT, aber meine Zeit gibt das nicht her.

Daher das NAS (nun mit ActivePerl) das einfach läuft und bisher die HMLAN's.
Hoffentlich läuft die CCU2 auch ohne ständiges Admin-streicheln  ;)

Für die Umstellung werde ich also mal ein Wochenende opfern müssen.
Meine Funktionen muss ich dann mindestens mit Suchen&Ersetzen in der cfg auf die Datapoints anpassen. Wird eine Fleißaufgabe....

Beta-User

...dann nimm' wenigstens 'ne OCCU (oder Raspberrymatic?) auf Pi-Basis - die CCU2 scheint unglaublich lahm zu sein, was andere Probleme schafft (noch nicht da, wenn alles wg. Stromweg neu startet usw.)...

Ansonsten: jeder wie er mag. Das PCB ist jedenfalls in ein paar Minuten gelötet, und fertige MapleCUN kann man ja auch bekommen ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Dirk070

Schaue ich mir auf jeden Fall vorher mal an, Danke.

zap

Zitat von: Beta-User am 06 Februar 2018, 15:26:15
...dann nimm' wenigstens 'ne OCCU (oder Raspberrymatic?) auf Pi-Basis - die CCU2 scheint unglaublich lahm zu sein, was andere Probleme schafft (noch nicht da, wenn alles wg. Stromweg neu startet usw.)...

Die CCU braucht beim Starten sehr lange, bis alle Dienste gestartet sind. Wenn sie aber mal läuft, ist sie performant, insbesondere was das Schalten von Geräten und die Benachrichtigung von FHEM angeht. Außerdem ist die Funkreichweite etwas besser als bei den Raspi-Anbauteilen (gibt aber externe Antennen als Abhilfe).

Die Bedienung über das Webinterface ist auch nicht die schnellste, aber für mich akzeptabel, zumal man das nur selten braucht.

Wenn ich neu starten würde, wäre vermutlich auch ein Raspi meine erste Wahl. Die CCU ist aber nicht so schlecht, dass ich zwingend wechseln müsste.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Dirk070

Auch nochmal ein guter Hinweis aus der Praxis. Danke.

axel.mohnen

Hallo,
ich stehe vor dem gleichen Problem. Mein CUL_HM ist am Wochenende abgeraucht.
Eine CCU2 habe ich bereits im Einsatz für HM-IP Geräte. Die Migration der alten HM Geräte auf die CCU2 habe ich immer gescheut.
Jetzt habe ich den Hinweis von "Beta-User" hier gelesen:
ZitatDas sind grundverschiedene Welten (CUL_HM und CCU2). Du kannst dir allenfalls das pairing sparen, wenn du der CCU2 dieselbe HmID verpaßt wie du bisher nutzt

Könnte mir jemand dazu mehr Infos geben? Wie soll das funktionieren. Einfach HMID im CCU2 eintragen und alle bestehenden HM Geräte (gepairt) werden gelistet?
Wo wird die HMID in der CCU2 eingetragen? Ich sehen in der CCU2 ein Device mit dem Namen "HM-RCV-50 BidCosRF". Muss ich diesen Namen auf die HMID abändern?
Wenn ich mir das "pairen" sparen könnte wäre mir schon sehr geholfen, zumal mache HM Aktoren keinen "Config-Button" haben.

Vielen Dank im Voraus.
Viele Grüsse
Axel

MadMax-FHEM

FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Horti

Hi,

Zitat von: axel.mohnen am 29 April 2020, 07:36:24
ich stehe vor dem gleichen Problem. Mein CUL_HM ist am Wochenende abgeraucht.
Eine CCU2 habe ich bereits im Einsatz für HM-IP Geräte. Die Migration der alten HM Geräte auf die CCU2 habe ich immer gescheut.

das alleine sollte keine Grund sein, auf die CCU zu migrieren, es sei denn, Du willst es auch aus anderen Gründen. Das "alte" Funkmodul ist auf so viele Arten mit FHEM nutzbar, Du kannst Dir auch einen HMLAN-Ersatz bauen: https://wiki.fhem.de/wiki/Serial_TTL_to_Ethernet_Module.

Außerdem gibt es noch den regulären LANGW, so wie die Möglichkeit, eine CCU2 umzuwidmen oder einen Raspi mit Raspberrymatic.

Otto123

Moin,

Die Frage von Axel hat doch aber noch eine Kehrseite: Er hat die CCU2 ja schon für HmIp Geräte in Betrieb. Verwenden die auch die gleiche HMID? Weil dann könnte er zwar das pairen der Altgeräte sparen aber das "Pairing"  der HMIp Geräte wäre im Eimer?
Oder ist da ein ganz andere Mechanismus und die HMID spielt (auch in der CCU2) nur für "Homematic alt" eine Rolle?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

axel.mohnen

Vielen Dank für Eure schnelle Hilfe und Hinweise.
Echt Top!

Ich denke Ich werde den Umzug auf die CCU2 wagen. Dann wird meine Funkmodul Architekture etwas erleichtert (habe noch einen Jeelink) :-)

Hier ist meine Idee für meine bestehenden Geräte in FHEM zu migrieren.
1) Die bestehenen Geräte umbenennen (zb. rollo.wohnzimmer -> rollo.wohnzimmer.old
2) Neues Gerät mit HMCCUDEV anlegen (rollo.wohnzimmer)
3) Readings im neuen Gerät mit ccureadingname anpassen

Könnte das funktionieren?

Frage: Was passiert mit den bestehenden NOTIFY/AT/DOIF Routinen?

Viele Grüsse
Axel
 

Horti

#14
Moin,

Zitat von: Otto123 am 29 April 2020, 09:25:21
Die Frage von Axel hat doch aber noch eine Kehrseite: Er hat die CCU2 ja schon für HmIp Geräte in Betrieb. Verwenden die auch die gleiche HMID? Weil dann könnte er zwar das pairen der Altgeräte sparen aber das "Pairing"  der HMIp Geräte wäre im Eimer?
Oder ist da ein ganz andere Mechanismus und die HMID spielt (auch in der CCU2) nur für "Homematic alt" eine Rolle?

Soweit ich weiß letzteres. Auf der anderen Seite weiß ich, dass HMIP flexibler ist und kann auch ein sog. "Rekeying" durchführen, wenn sich irgendwas an der Konfiguration ändert. Das erfordert eine Internet-Verbindung, dürfte aber hier nicht zum Tragen kommen.

Edit: ganz so einfach ist es aber doch nicht, hier wird vom Rekeying berichtet beim Wechsel eines Funkmoduls. Es ändert sich hier auch allerdings nicht nur die HMID sondern auch das Funkmodul-Modell. Im Zweifel also vielleicht im Homematic-Forum nachfragen, oder "einfach" ausprobieren ;)