RPI4 Mit Fhem komplett neu aufsetzen...inkl HM/HMIP

Begonnen von misux, 21 Januar 2021, 18:44:04

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: misux am 28 Januar 2021, 12:28:13
HM würde ich gerät für Gerät "umhziehen" aber ohne das ich die neu einlernen muss...
[...]
Deshalb würde ich gern die HMID am neuen RAspi übernehmen... und dann das Gerät wirklich nur an einem bedienen...

Zitat von: Beta-User am 28 Januar 2021, 11:05:39
Jein, das geht zwar, ist aber (mAn.) sch...
[...]
- Ein Parallelbetrieb geht zwar, erzeugt aber vermutlich zuhauf "attack"-Meldungen, zumindest, wenn von mehreren Geräten aus versucht wird, Steuerbefehle abzusetzen. Acks werden ggf. verloren gehen usw. usf.

MAn. sollte man entweder direkt ganz umsteigen oder sich die Mühe machen, die Geräte dann halt im einen System ab- und im anderen anzumelden.
[...]
Also nochmal anders formuliert:

Man kann HM-BidCoS-Geräte IMMER von mehreren "Zentralen" aus bedienen (Ausnahme: AES war aktiviert, was aber - abgesehen von speziellen Funktionen - aus diversen Gründen kaum einer macht). Jede "Zentrale" braucht dazu im Prinzip nur die passende HmID.

Das kann man z.B. nutzen, wenn man von FHEM 1 nach FHEM 2 umsteigt (und nur die Hardware "mitnehmen" will) oder von CCU nach CUL_HM. ABER: Man trickst damit das System eigentlich aus und erzeugt - zumindest mit CUL_HM - auch Sabotage-Meldungen, und es fallen ggf. auch "(to VCCU)"-Events aus, weil EIN ANDERES System den Empfang bestätigt usw. usf....
Anders gesagt: Die Übernahmemöglichkeit der HmID ist toll, wenn man direkt 100% umziehen will, aber sie schafft mAn. mehr Probleme als sie löst, wenn man "Stück für Stück" umziehen will.

Wie gesagt: Wenn du bei FHEM bleiben willst (und der Teil gut läuft), macht ein Umzug des CUL_HM-Teils in die CCU sowieso keinen großen Sinn, ich würde daher schlicht ein 2. Interface beschaffen und beide Welten getrennt halten (und allenfalls dann nach und nach mit anderer HmID umziehen).

(Evtl. könnte man Horti bitten, das Umzugsthema noch mit in den Thread aufzunehmen, das scheinen viele nicht zu verstehen, was es in dem Zusammenhang mit der HmID auf sich hat).
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

frank

ZitatMan kann HM-BidCoS-Geräte IMMER von mehreren "Zentralen" aus bedienen (Ausnahme: AES war aktiviert, was aber - abgesehen von speziellen Funktionen - aus diversen Gründen kaum einer macht). Jede "Zentrale" braucht dazu im Prinzip nur die passende HmID.
mit passendem aes key und passender hmid ausgestattet, sollten auch mehrere zentralen parallel möglich sein.

wozu auch immer.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

dieda

Nur mal so als Hilfestellung, da man den Stick von ELV selbst zusammenbauen muss und dann die Garantie erlöschen soll...

Ich habe mir diesen hier besorgt: https://www.smarthome.de/geraete/smarthome-funkstick-fuer-homematic-ip-weiss
Komponenten:
Sensoren und Aktoren: FS20, Max!, Zigbee, Zwave
IODev:  Cul1101, MaxLan, ZWAVE, Deconz
Router: KD-Fritte (6360)
Sonstiges: Raspberries,  1x LMS,1 FHEM, 1 x zum Testen,  Logitech-Clients,  Onkyo, SamsungTV, Squeezebox, TabletUIs

tndx

Zitat von: Wernieman am 29 Januar 2021, 09:26:05
Ich glaube nicht, das das ich der Ansprechpartner für die Funkmodule war ... oder?

Stimmt, das war der Beta-User, aber er kennt die Seite ja eh :)

deimos

Hi,

Zitat von: dieda am 29 Januar 2021, 12:31:50
Nur mal so als Hilfestellung, da man den Stick von ELV selbst zusammenbauen muss und dann die Garantie erlöschen soll...

Ich habe mir diesen hier besorgt: https://www.smarthome.de/geraete/smarthome-funkstick-fuer-homematic-ip-weiss

Garantie gibt es bei den Homematic Sachen sowieso keine. Gewährleistung bekommst du auch bei den Bausätzen, sofern deine (Löt-)arbeiten fachgerecht erfolgt sind. Und grade elv ist da für ihre Kulanz bekannt.
Von dem Telekom Stick kann ich nur abraten: Der ist von der Hardware zwar baugleich, aber er ist mit einer speziellen Firmware ausgestattet, welche von eQ-3 nicht (direkt) supported wird. Bei Problemen wirst du da gnadenlos an die Telekom verwiesen und die gibt nur Support, wenn du es mit der Telekomlösung verwendest. Aktuell ist es so, dass du auch das letzte Firmware Update von eQ-3 nicht auf den Stick aufgespielt bekommst. Ob der Stick zukünftig überhaupt mit den CCU Diensten weiterlaufen wird, ist fraglich, nachdem es da scheinbar einige Umstimmigkeiten zwischen Telekom und eQ-3 gibt.

Aber auch den Original HmIP-RFUSB kann ich nicht empfehlen: Der wird massiv stiefmütterlich von eQ-3 gepflegt, kann maximal 100 Geräte (leider undokumentiert), kann kein BidCos und wenn man darüber nachdenkt, irgendwann mal mit HmIP Wired zu arbeiten oder einen HmIP Access Point für Reichweitenverlängerung nutzen will, dann kommt man um ein RPI-RF-MOD nicht herum, dieses kann man ggf. auch per HB-RF-USB-2 oder HB-RF-ETH an Systemen anschließen, welche keinen GPIO haben.

Viele Grüße
Alex