Hallo,
ich befürchte, mancher denkt jetzt "Oh Gott, nicht schon wieder"... Ich habe auch versucht, mich durch die existierenden Threads zu wühlen, das ist aber doch ein wenig unübersichtlich.
Also sicherheitshalber mal zusammengefasst: Soweit ich das verstehe, ist die derzeit einfachste und zweitgünstigste (nach selbst löten) Variante der HmIP-RFUSB.
Den kann FHEM aber (derzeit?) nicht direkt ansprechen, so dass pivccu(3) installiert werden muss. Besser pivccu3 oder pivccu (also CCU2)? Debmatic und RasperryMatic scheinen den HMIP-Stick noch nicht zu unterstützen, oder?
Dann kann HMCCU auf diesen virtuellen CCU zugreifen.
So weit korrekt?
Was mir dann noch nicht ganz klar ist:
Wie läuft dann das Anlernen der Geräte? Läuft das über Kommandos oder hat pivccu 'ne Web-Oberfläche? Wenn ja, kommen sich nicht die Ports von pivccu, FHEM und (bei mir) Apache ins Gehege, oder kann man die konfigurieren? Und wie sieht es mit anderen Ports aus, die pivccu evtl. benötigt? Irgendwie habe ich bisher nur Dokus zur Installation gefunden, nichts zur Benutzung...
Läuft pivccu eigentlich autark oder verwendet das die Homematic-Cloud?
Hallo Mort,
bei mir läuft auf einen RasPi 3 Fhem, Debmatic und PiHole. Als Modul verwende ich das RPI-RF-MOD mit Stromversorgung über das Modul und nicht über USB.
Angelernt werden die Geräte dann über die Debmatic-Oberfläche. IP ist die gleiche wie FHEM
Fhem baut dann eine Verbindung mit Debmatic auf und kommuniziert damit, wobei der eigentliche Befahl dann wieder aus Debmatic kommt.
Hi,
HmIP-RFUSB ist zwar nicht teuer und hat mit USB einen gewichtigen Vorteil, kann allerdings kein HM BidCos. Muss kein Nachteil sein, je nach konkreter Situation. Ist auch etwas exotisch, wird aber auch meines Wissens von RaspberryMatic und auch von piVCCU unterstützt.
Ich würde aber, sofern USB keine zwingende Voraussetzung ist, zu der günstigsten und wohl flexibelsten Variante greifen: HM-MOD-RPI-PCB. Kriegst Du gebraucht auch zusammengelötet für kaum mehr als den Bausatzpreis.
Moin
Ich wuerde auch den RPI-RF-MOD nehmen. Das Loeten beschraenkt sich auf einen Kondensator!
Meiner Meinung nach koennen alle Derivate auf den HmIP-RFUSB zugreifen. Ich habe es aber nicht probiert, da ich den erstgenannten habe!
Gruss Christoph
Zitat von: pc1246 am 02 Dezember 2020, 15:15:54
Moin
Ich wuerde auch den RPI-RF-MOD nehmen. Das Loeten beschraenkt sich auf einen Kondensator!
EDIT:
Zitat von: Horti am 02 Dezember 2020, 14:04:28
Ich würde aber, sofern USB keine zwingende Voraussetzung ist, zu der günstigsten und wohl flexibelsten Variante greifen: HM-MOD-RPI-PCB. Kriegst Du gebraucht auch zusammengelötet für kaum mehr als den Bausatzpreis.
ok, es wird hier in den 2 Antworten wohl von beiden Geräten gesprochen. Es gibt ja BEIDE Funkplatinen... ;)
EDIT: Unterschied zwischen den beiden Platinen (abgesehen vom Lötaufwand ;) ): knapp 20EUR
Wenn sich das nicht geändert hat (ich habe schon mind. 3 "verlötet"), dann muss eine Steckleiste auf die Platine und an die Steckleiste dann das Funkmodul und nat. die Buchsenleiste zum Aufstecken auf den PI gelötet werden.
Will niemandem "Angst" machen ;)
Wollte es nur "richtig stellen" (sofern es sich [wie geschrieben] nicht geändert hat) und nat. sofern von diesem Modul die Rede ist:
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
https://de.elv.com/elv-homematic-komplettbausatz-funkmodul-fuer-raspberry-pi-hm-mod-rpi-pcb-fuer-smart-home-hausautomation-142141
Und nicht die hier:
https://de.elv.com/elv-komplettbausatz-funk-modulplatine-fuer-raspberry-pi-3-b-rpi-rf-mod-fuer-homematic-und-homematic-ip-152941
(da ist es in der Tat [verm.] nur ein Kondensator)
Und auch den USB-Stick gibt es als Bausatz:
https://de.elv.com/elv-homematic-ip-arr-bausatz-rf-usb-stick-fuer-alternative-steuerungsplattformen-hmip-rfusb-fuer-smart-home-hausautomation-152306
Gruß, Joachim
ZitatEDIT: Unterschied zwischen den beiden Platinen (abgesehen vom Lötaufwand ;) ): knapp 20EUR
technisch gibt es schon noch deutliche unterschiede:
RPI-RF-MOD (~40eur):
- eine gepufferte RTC (uhr)
- einzige möglichkeit hmip-accesspoints als "repeater" zu nutzen.
Zitat von: frank am 02 Dezember 2020, 15:50:29
technisch gibt es schon noch deutliche unterschiede:
RPI-RF-MOD (~40eur):
- eine gepufferte RTC (uhr)
- einzige möglichkeit hmip-accesspoints als "repeater" zu nutzen.
Ja, war klar. Der Mehrpreis muss ja auch was "nützen".
Setzt halt voraus, dass man das mit dem Accesspoint auch braucht...
Das mit der RTC Uhr gibt es auch hier im Forum irgendwo mit dem "günstigeren" Funkmodul ;)
Gruß, Joachim
Der TE hat ja, zumindest so habe ich seine Aussage interpretiert, von lötfrei und günstig gesprochen, daher mein Tip in Richtung HM-MOD-RPI-PCB und gebraucht/zusammengebaut.
Klar, RPI-RF-MOD kann mehr, kostet aber auch mehr, hat einen anderen Formfaktor und Probleme mit RPI4. Außerdem gibt es im Moment im orangenen Forum Hinweise, dass das Ding zwar bessere Funkreichweite haben mag, dafür aber die Frequenz nicht korrekt einhalt, was wiederum für Kommunikationssschwierigkeiten sorgt (es ist noch nicht bestätigt, dass das ein grundsätzliches Problem von dem Modul ist).
Aber zumindest kann HM-MOD-RPI-PCB auch nicht weniger, als eingangs erwähnte HmIP-RFUSB, außer eben USB.
...stellt sich nur die Frage, warum überhaupt HM-IP und eQ-3...
Zitat von: Beta-User am 02 Dezember 2020, 16:24:41
...stellt sich nur die Frage, warum überhaupt HM-IP und eQ-3...
Nicht schon wieder diese Leier... Du musst nicht in jedem Homematic-Thread damit anfangen, mittlerweile kennt glaube ich jeder deinen Standpunt. Es ist was anderes, wenn nach Alternativen gefragt wird, aber hier geht es nun mal um HmIP.
Zitat von: Horti am 02 Dezember 2020, 17:18:58
Nicht schon wieder diese Leier... Du musst nicht in jedem Homematic-Thread damit anfangen, mittlerweile kennt glaube ich jeder deinen Standpunt. Es ist was anderes, wenn nach Alternativen gefragt wird, aber hier geht es nun mal um HmIP.
::) ...ist ja schon gut, und wenn der TE sich als erfahrener Anwender ausgegeben hätte, wäre ich auch gar nicht auf den Gedanken gekommen, irgendwas zu schreiben...
Dass der Stick auch 'n Bausatz ist, hatte ich übersehen.
Sieht dann wohl so aus, als wäre die beste Option, mal zu suchen, wo ich meinen alten Raspi 3B hingelegt habe (im Moment läuft alles auf 'nem 4er, dessen GPIO auch noch mit 433MHz-Zeug für Pilight belegt ist) und eine der Platinen zu nutzen.
PS: Hab mal auf eBay nach kompletten Platinen geschaut. Wenn da wirklich nur 'n Kondensator gelötet werden muss, lassen die sich das bei Preisen von rund 40 bis 55 Euro aber relativ stattlich bezahlen. Lustigerweise kostet dort RPI-RF-MOD als Fertiggerät auch nicht viel mehr.
Gibt's bei den verschiedenen CCU-Implementierungen eigentlich nennenswerte Unterschiede, oder ist das mehr Geschmackssache, welche Oberfläche einem am ehesten zusagt?
Zitat von: Mort am 02 Dezember 2020, 17:33:15
Gibt's bei den verschiedenen CCU-Implementierungen eigentlich nennenswerte Unterschiede, oder ist das mehr Geschmackssache, welche Oberfläche einem am ehesten zusagt?
Vielleicht noch was konstruktives zu dem HM-IP-Zeug; das ist doch alles recht verteilt:
(Zu debmatic)
Zitat von: zap am 12 Februar 2019, 12:12:45
Gegenüber piVCUU sind die Vorteile eher marginal. Die Konfiguration mit durchgereichten Ports ist einfacher und man spart den - zugegeben geringen, aber vorhandenen - Overhead durch den Container.
Im Vergleich zu RasperryMatic sind die Vorteile schon größer: Man kann problemlos weitere Software - wie eben FHEM und Perl - auf dem gleichen System installieren. Bei RaspberryMatic muss man alles "from Scratch" selbst bauen mit den bekannten Seiteneffekten (Dependency Hell).
Der Autor von piVCCU und debmatic ist derselbe, (Forum-User deimos) siehe sein Repo auf github, da ist auch stichwortartig was zu den Unterschieden zu finden: https://github.com/alexreinert
Und von ihm dann noch was zum USB-Bausatz und den anderen Unterschieden:
Zitat von: deimos am 04 November 2019, 13:32:02
Hi,
bei debmatic brauchst du für Homematic IP Funk eines der drei unterstützten Funkmodule, welche auch HmIP können, d.h. HmIP-RFUSB, HM-MOD-RPI-PCB oder RPI-RF-MOD. Da die letzteren beiden nur auf einen GPIO Header aufgesteckt werden können und das bei x86/x64 schwer möglich ist, habe ich die Platine HB-RF-USB entwickelt, welche einen für Homematic Funkmodule passenden GPIO Header per USB bereitstellen und auch die für die (virtuelle) CCU notwendigen Treiber bereitstellen.
Für HmIP Wired brauchst du zwingend ein RPI-RF-MOD und einen HmIP Wired AP. (Und für den Anschluss an x86/x64 dann noch die HB-RF-USB).
Aus der Erfahrung mit der Entwicklung von piVCCU und debmatic würde ich vom HmIP-RFUSB abraten, das wird gefühlt sehr stiefmütterlich von eQ-3 beachtet und auch die Funkleistung ist nicht so der Brüller. Zudem kann es kein BidCos. Ganz absehen sollte man von der Telekomvariante des HmIP-RFUSB, da scheint es irgendwelche Streitereien zu geben, so dass man auf dem kein Firmware Update einspielen kann und dieser bei einem Ersatz bei einem Defekt keinen Keywechsel durchführen kann, so dass man alle Geräte neu anlernen müsste.
Daneben arbeite ich aktuell an der HB-RF-ETH, mit welcher man die Funkmodule dann auch per Netzwerk anbinden kann. Bis die komplett fertig ist, wird es aber noch ein paar Tage dauern.
Viele Grüße
Alex
Ggf. macht es Sinn, im jeweiligen Original-Thread nochmal nachzuhören, ob das noch Stand der Dinge ist, aber afaik gibt's da wenig neues...
Nunja, man braucht eigentlich gar kein HM-Adapter, weder USB noch GPIO wenn man den Umweg über iobroker geht. Der dortige Adapter macht die Hautparbeit und man muss es nur noch mit FHEM verknüpfen: https://forum.fhem.de/index.php/topic,98067.msg1027029.html
Zitat von: dieda am 02 Dezember 2020, 18:28:49
Nunja, man braucht eigentlich gar kein HM-Adapter, weder USB noch GPIO wenn man den Umweg über iobroker geht. Der dortige Adapter macht die Hautparbeit und man muss es nur noch mit FHEM verknüpfen: https://forum.fhem.de/index.php/topic,98067.msg1027029.html
Hä?
Das ist doch Unfug!
"Irgendetwas" muss doch mit den Homematic IP Geräten "funken"!!?
Und ich glaube nicht, dass IOBroker das Homematic IP-Protokoll entschlüsselt hätte (und keiner wüsste das) und somit KEINE CCUx für Homematic IP bräuchte...
Aber wie geschrieben, selbst dann: "WER" funkt denn dann mit den Geräten?
Gut es gibt noch den Accesspoint.
Aber auch das ist (glaube ich) mittlerweile möglich den mit fhem zu nutzen...
Hab zumindest sowas im "Ohr" ;)
Gruß, Joachim
Bzgl. HB-RF-USB und Konsorten:
Es gibt von Alex Reinert mittlerweile 3 Platinen, die dazu dienen, die beiden HM-GPIO-Module von GPIO zu entkoppeln und damit auch auf anderen Hardware-Architekturen über USB oder Ethernet zu nutzen (was aber die RPI-Derivaten nicht ausschließt):
- HB-RF-USB
- HB-RF-USB-2
- HB-RF-ETH
Von einem anderen Entwickler (stan23) stammt eine weitere Platine: HB-MOD-UART-USB, die HB-RF-USB nur auf das kleine Funkmodul reduziert. Die Platinen sind teilweise richtig schwer zu löten, gibt es aber auch bestückt zu kaufen, dann aber richtig teuer (für meinen Geschmack).
Das HM-MOD-RPI-PCB bekommst Du dagegen fertig glötet recht günstig bei e**y-Kleinanzeigen, einfach mal "Homematic Funkmodul" eingeben ;)
Zitat von: MadMax-FHEM am 02 Dezember 2020, 18:36:49
Hä?
Das ist doch Unfug!
"Irgendetwas" muss doch mit den Homematic IP Geräten "funken"!!?
Und ich glaube nicht, dass IOBroker das Homematic IP-Protokoll entschlüsselt hätte (und keiner wüsste das) und somit KEINE CCUx für Homematic IP bräuchte...
Aber wie geschrieben, selbst dann: "WER" funkt denn dann mit den Geräten?
Gut es gibt noch den Accesspoint.
Aber auch das ist (glaube ich) mittlerweile möglich den mit fhem zu nutzen...
Hab zumindest sowas im "Ohr" ;)
Gruß, Joachim
Die haben mittlerweile einen Adapter dafür. Was nicht geht sind die Profile. Was ich pers. schade finde. Gerade der Profilwechsel per Smart Home ist der Reiz.
Wie du lesen kannst: Accesspoint! Das ist das Funkmodul...
Und wie geschrieben gibt es wohl (mittlerweile) auch die Möglichkeit den Accesspoint direkt in fhem bzw. in einer virtuellenCCU zu nutzen...
Zumindest wird dran gearbeitet...
Und auch so ein Homematic Accesspoint muss gekauft werden (sofern man den nicht einfach in einem Bundle mitgekauft hat)...
Ich habe auch nicht geschaut, ob das bei ioBroker auch eine cloudfreie Anbindung ist...
Weil der Accesspoint norm. eben mit dem Clouddienst von eq3 betrieben wird (werden muss)...
...außer man flasht ihn um...
Gruß, Joachim
Hier läuft der HMIP-Hab. Kein Access-Point, aber wie schon geschrieben, es fehlt die Profilfunktion und in FHEM wird für jeden übertragenen Status ein eigenes Dummy angelegt. Das macht die Sache nicht wirklich attraktiv.
Zitat von: dieda am 02 Dezember 2020, 20:06:09
Hier läuft der HMIP-Hab. Kein Access-Point, aber wie schon geschrieben, es fehlt die Profilfunktion und in FHEM wird für jeden übertragenen Status ein eigenes Dummy angelegt. Das macht die Sache nicht wirklich attraktiv.
D.h. Cloud-Anbindung...
Naja: wer das haben will...
EDIT: ließe sich bestimmt auch in fhem integrieren (oder gibt es u.U. sogar schon). Aber ist eher nicht so beliebt... Und wenn die Cloud mal nicht geht oder das Inet nicht will ist wohl "essig"...
EDIT: aber führt wohl (langsam) in die "falsche" Richtung...
Gruß, Joachim
Zitat von: MadMax-FHEM am 02 Dezember 2020, 20:08:29
D.h. Cloud-Anbindung...
Naja: wer das haben will...
EDIT: ließe sich bestimmt auch in fhem integrieren (oder gibt es u.U. sogar schon). Aber ist eher nicht so beliebt... Und wenn die Cloud mal nicht geht oder das Inet nicht will ist wohl "essig"...
Hm, ich hab zwei HmIP-HAP laufen und keiner macht Cloud. Die kann man inzwischen im Prinzip als HmIP-Lan-GW betreiben (drei Stück an einer CCU, glaube ich).
IoBroker macht aber, nach Überfliegen der Integration, aber einen REST-Request gegen die Homematic Cloud. Also IoBroker ohne Cloud geht nicht, HmIP-HAP ohne Cloud an CCU3 geht sehr wohl.
Zitat von: Christoph Morrison am 02 Dezember 2020, 20:11:36
Hm, ich hab zwei HmIP-HAP laufen und keiner macht Cloud. Die kann man inzwischen im Prinzip als HmIP-Lan-GW betreiben (drei Stück an einer CCU, glaube ich).
Das meinte ich ja :)
Hab grad mal gegoogelt: ist nun der Accesspoint was anderes als der HmIP-HAP? Irgendwie kommr ich immer auf den Accesspoint ;)
Gruß, Joachim
Beachte noch meinen Edit.
HmIP-HAP = Kabelgebundener HmIP Access Point
HmIP-WLAN-HAP = Wifi HmIP Access Point
Zitat von: Christoph Morrison am 02 Dezember 2020, 20:16:16
Beachte noch meinen Edit.
HmIP-HAP = Kabelgebundener HmIP Access Point
HmIP-WLAN-HAP = Wifi HmIP Access Point
DANKE! :)
Hi,
Zitat von: Horti am 02 Dezember 2020, 19:26:47
Bzgl. HB-RF-USB und Konsorten:
Es gibt von Alex Reinert mittlerweile 3 Platinen, die dazu dienen, die beiden HM-GPIO-Module von GPIO zu entkoppeln und damit auch auf anderen Hardware-Architekturen über USB oder Ethernet zu nutzen (was aber die RPI-Derivaten nicht ausschließt):
- HB-RF-USB
- HB-RF-USB-2
- HB-RF-ETH
Von einem anderen Entwickler (stan23) stammt eine weitere Platine: HB-MOD-UART-USB, die HB-RF-USB nur auf das kleine Funkmodul reduziert. Die Platinen sind teilweise richtig schwer zu löten, gibt es aber auch bestückt zu kaufen, dann aber richtig teuer (für meinen Geschmack).
Ich wünschte, es gäbe eine Möglichkeit die Platinen günstiger unters Volk zu bringen, aber dank der guten Lobbyarbeit ist es in Deutschland nicht möglich, Hardware günstig in Kleinserien zu vertreiben wg. CE, WEEE und Co.
Viele Grüße
Alex
Hi,
Zitat von: dieda am 02 Dezember 2020, 18:28:49
Nunja, man braucht eigentlich gar kein HM-Adapter, weder USB noch GPIO wenn man den Umweg über iobroker geht. Der dortige Adapter macht die Hautparbeit und man muss es nur noch mit FHEM verknüpfen: https://forum.fhem.de/index.php/topic,98067.msg1027029.html
Die HmIP Unterstützung von ioBroker setzt auf das REST Interface der HmIP Cloud Lösung auf. Man braucht bei sich dafür einen HmIP Access Point für den eigentlichen Funk und ist auf die Funktionsfähigkeit der eQ-3 Server und eine funktionierende Internet Anbindung angewiesen. Mir persönlich wäre das zu unsicher.
Viele Grüße
Alex
Zitat von: Christoph Morrison am 02 Dezember 2020, 20:11:36
Hm, ich hab zwei HmIP-HAP laufen und keiner macht Cloud. Die kann man inzwischen im Prinzip als HmIP-Lan-GW betreiben (drei Stück an einer CCU, glaube ich).
IoBroker macht aber, nach Überfliegen der Integration, aber einen REST-Request gegen die Homematic Cloud. Also IoBroker ohne Cloud geht nicht, HmIP-HAP ohne Cloud an CCU3 geht sehr wohl.
Dann mal her damit. Wie hast du das umgesetzt?
Uff, die kryptischen Bezeichnungen der Platinen machen es irgendwie nicht gerade einfach, den Überblick zu behalten...
Also, wenn ich das richtig überblicke:
- HmIP-RFUSB - Bausatz, offiziell von HM, eher mäßige Funkleistung und stiefmütterliche Pflege
- HM-MOD-RPI-UART - übliches Funkmodul
- HM-MOD-RPI-PCB - übliches Funkmodul mit GPIO-Adapter
- HM-OCCU-SDK - ist das die ELV-Bezeichnung für HM-MOD-RPI-PCB oder was eigenes?
- RPI-RF-MOD - GPIO-Platine mit besserer Funkleistung, Wired-Support und weiterem "Tuning"
- HB-RF-USB-2 - "Sockel" für HM-MOD-RPI-PCB oder RPI-RF-MOD mit USB-Anschluss
- HB-RF-USB - ältere Variante von HB-RF-USB? (Google lieferte mir nur noch ...-2-Treffer...)
- HB-RF-ETH - Quasi eine günstige Alternative zu einem Extra-Raspi mit Ethernet-Anschluss (wobei aber die CCU-Software noch irgendwo anders laufen muss)
- HM-LGW-O-TW-W-EU - die teure offizielle Variante von HB-RF-ETH + RPI-RF-MOD, und nur für Homematic ohne "IP"
- und dann scheint es noch eine Art HM-MOD-RPI-UART mit USB-Anschluss zu geben? Oder ist das HM-MOD-RPI-UART mit HB-RF-USB(-2)?
Und bei der Software:
- piVCCU - Container/VM(?), also einfache Einrichtung, aber etwas größerer Ressourcenverbrauch und etwas weniger Einstellmöglichkeiten
- debmatic - "klassisches" Programm, daher auch leichter portierbar (x86) und konfigurierbar, aber wenn's blöd läuft Dependency-Problemchen?
- RasperryMatic - Komplettes System, wenn man die CCU auf 'nem eigenen Raspi laufen lassen will. Oder zumindest so gedacht, vermutlich kann man die Repositories prinzipiell auch anders nutzen...
Ist piVCCU eigentlich "debmatic im Container" oder sind das (noch?) komplett getrennte Entwicklungen?
So wie ich das sehe, ist es dann für mich tatsächlich wohl die eleganteste Variante, den alten Raspi 3 mit einem der beiden GPIO-Aufsätzen zu nutzen. Damit kann ich das Funkmodul wie beim ETH frei platzieren und habe komplett getrennte Hardware für die CCU, also keine Konflikte mit anderen Programmen (Ports, Repository-Abhängigkeiten) und keine Probleme mit der Auslastung. Software-mäßig würde ich dafür zu debmatic neigen.
Hätte ich den alten Raspi nicht rumfliegen, würde ich vermutlich zum USB-Adapter neigen.
Zitat von: Mort am 03 Dezember 2020, 09:32:05
- HM-MOD-RPI-UART - übliches Funkmodul
- HM-MOD-RPI-PCB - übliches Funkmodul mit GPIO-Adapter
- HM-OCCU-SDK - ist das die ELV-Bezeichnung für HM-MOD-RPI-PCB oder was eigenes?
- HM-LGW-O-TW-W-EU - die teure offizielle Variante von HB-RF-ETH + RPI-RF-MOD, und nur für Homematic ohne "IP"
HM-OCCU-SDK ist die Software der CCU von eq3 https://github.com/eq-3/occu
HM-MOD-RPI-PCB das ist aus meiner Sicht das eigentliche, erste separate Modul als Bausatz was man nicht zwingend komplett zusammenbauen muss und divers anders adaptieren kann. (Wiki (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi))
HM-LGW-O-TW-W-EU da hieß es immer: das ist das gleiche Funkmodul vom HM-MOD-RPI-PCB mit LAN Anschluss. Warum das nicht für IP geht ist eigentlich komisch, aber ist eben so.
Wenn man auf HM IP setzen will sollte man aus meiner Sicht zum jetzigen Zeitpunkt das Teil nehmen: RPI-RF-MOD und auf eine Pi3xx stecken.
Meine 2 Pfenge - wie man so schön sagt :)
Otto
Zitat von: Otto123 am 03 Dezember 2020, 09:57:03
HM-OCCU-SDK ist die Software der CCU von eq3 https://github.com/eq-3/occu
Ah, OK. Mir ist das nur bei den Kleinanzeigen aufgefallen. Scheibar hat ELV das HM-MOD-RPI-PCB früher unter dem Namen vertrieben. Wohl eher als "Funkmodul für diese Software" gemeint, aber auf den Verpackungs-Fotos wirkt das eher wie der Produktname.
ZitatHM-LGW-O-TW-W-EU da hieß es immer: das ist das gleiche Funkmodul vom HM-MOD-RPI-PCB mit LAN Anschluss. Warum das nicht für IP geht ist eigentlich komisch, aber ist eben so.
Auch interessant. Vermutlich geht's da eher ums Zielgruppen-Targeting. IP für die Masse, Homematic für die "Luxus-Variante".
ZitatWenn man auf HM IP setzen will sollte man aus meiner Sicht zum jetzigen Zeitpunkt das Teil nehmen: RPI-RF-MOD und auf eine Pi3xx stecken.
Hm, für den Alltagseinsatz sehe ich nicht so wahnsinnig viel Vorteil vom RPI-RF-MOD ggü. dem HM-MOD-RPI-PCB. Bei größeren Häusern könnte vielleicht noch die Reichweite interessant sein, aber für meine Wohnung sollte es selbst ein HM-MOD-RPI-PCB im Schrank schaffen. ;)
die CCU war eigentlich closed, dann hat man offenbar gemerkt, dass man Entwickler dafür vorhalten müsste und hat es open gemacht. Das HM-LGW-O-TW-W-EU kam zeitgleich mit der CCU2 als Ersatz für den alten HM-CFG-LAN. Ich bilde mir ein, kurz danach hat man das HM-MOD-RPI-PCB und die OCCU Software als Bastelpaket heraus gebracht.
RPI-RF-MOD - die Differenz sind 20€ - Du investierst am Ende "Unsummen" in die restliche Technik. ;) und Du hast damit einen Hardware Uhr am Pi, das ist auch ein Vorteil.
ZitatRPI-RF-MOD - die Differenz sind 20€ - Du investierst am Ende "Unsummen" in die restliche Technik. ;) und Du hast damit einen Hardware Uhr am Pi, das ist auch ein Vorteil.
meine debmatic hat zb erhebliche startprobleme, wenn sie nach einem reboot des pi nicht ins internet kommt. vermutlich, um die uhrzeit zu bekommen.
ich spekuliere, mit RPI-RF-MOD wäre das nicht der fall.
Zitat von: Mort am 03 Dezember 2020, 10:17:11
Hm, für den Alltagseinsatz sehe ich nicht so wahnsinnig viel Vorteil vom RPI-RF-MOD ggü. dem HM-MOD-RPI-PCB. Bei größeren Häusern könnte vielleicht noch die Reichweite interessant sein, aber für meine Wohnung sollte es selbst ein HM-MOD-RPI-PCB im Schrank schaffen. ;)
Also wenn ich es richtig verstanden habe, ist der HM-MOD-RPI-PCB nicht fuer HM-IP, und somit ungeeignet, wenn der Threadtitel stimmt!Und wenn man sich schon wegen €20,- einmacht, dann sollte man von HM-IP die Finger lassen, da jagt eine Mark die andere!
Gruss Christoph
Edith: nach Hinweis durch andere User! https://forum.fhem.de/index.php/topic,116375.msg1107053.html#msg1107053
Ich mache einfach mal eine Liste:
- HmIP-RFUSB
- HmIP-HAP
- CCU3
- HmIP-WLAN-HAP
- RPI-RF-MOD
- HM-MOD-RPI-PCB
Und wer glaubt, dass das einfach zu finden ist, der hat die Rechnung ohne ELV gemacht! Ist in drei Kategorien zu finden!
Gruss Christoph
Edith: HM-MOD-RPI-PCB hinzugefuegt, nach Hinweis durch anderen User:https://forum.fhem.de/index.php/topic,116375.msg1107053.html#msg1107053
Zitat von: pc1246 am 03 Dezember 2020, 15:33:46
Also wenn ich es richtig verstanden habe, ist der HM-MOD-RPI-PCB nicht fuer HM-IP, und somit ungeeignet, wenn der Threadtitl stimmt!
Das würde ich nicht unterschreiben.
Ich meine: mit einem PI und diesem Modul hat man von Anfang an eine CCU2 - und die kann doch HM IP
Hier wird das auch bestätigt: https://forum.fhem.de/index.php/topic,83795.msg760552.html#msg760552
oder stimmt das nicht? Ich kann es nicht definitiv sagen und spekuliere nur. Ich bleibe bei meiner Empfehlung ;)
Gruß Otto
Vielleicht findet sich jemand, der das Zeug auch nutzt, und stellt den aktuellen Stand der Dinge mal (ganz nach Gusto) im Wiki/wiki-tauglich/anpinn-tauglich zusammen?
(Es nervt, wenn hier alle Woche einer aufschlägt, weil irgendein Discounter grade einen Restposten erstanden hat und das unbedingt unter die Leute werfen will, und man dann immer wieder von Adam nach Eva kommt - oder gar, wenn's grade keine solche Aktion gibt - erst mal die Frage erörtert werden muss, warum denn jetzt der Selbstbau-CUL kein geeignetes Interface für HM-IP ist ::) ...)
Hier ist ja grade die komplette Übersicht und auch die Fachkompetenz vorhanden ;) .
Just my2ct...
Zitat von: pc1246 am 03 Dezember 2020, 15:33:46
Also wenn ich es richtig verstanden habe, ist der HM-MOD-RPI-PCB nicht fuer HM-IP, und somit ungeeignet, wenn der Threadtitl stimmt!
Das hast du falsch verstanden :)
Zitat von: Beta-User am 03 Dezember 2020, 15:59:39
Vielleicht findet sich jemand, der das Zeug auch nutzt, und stellt den aktuellen Stand der Dinge mal (ganz nach Gusto) im Wiki/wiki-tauglich/anpinn-tauglich zusammen?
...
Hier ist ja grade die komplette Übersicht und auch die Fachkompetenz vorhanden ;) .
Gerade was die Funkmodule angeht, gibt es hier (https://github.com/jens-maus/RaspberryMatic/wiki/Einleitung#vorraussetzungen) eine gute Übersicht (Punkt 2), die auch aktuell gehalten wird. FHEM-Wiki schön und gut, aber wer soll das aktuell halten?
Zitat von: Horti am 03 Dezember 2020, 17:10:29
Gerade was die Funkmodule angeht, gibt es hier (https://github.com/jens-maus/RaspberryMatic/wiki/Einleitung#vorraussetzungen) eine gute Übersicht (Punkt 2), die auch aktuell gehalten wird. FHEM-Wiki schön und gut, aber wer soll das aktuell halten?
Aktuell halten muß ja nicht heißen, das abzutippen. Eventuell reicht auch ein "schlichter" angepinnter Beitrag, in dem auf alles relevante verlinkt ist (im Prinzip würde es auch fast dieser Thread tun...). Es geht ja nur darum, dass man nicht immer und immer wieder dasselbe schreiben muss, sondern einfach ein kurzes "rtfm" + den Link von sich geben kann.
Etwas "ausführlicher bräuchten m.E. eigentlich nur die "FHEM-Spezifika" zu sein (die 100-fach gestellte Frage: "geht das parallel...? Und brauche ich dazu einen "mächtigen Pi"?!? Und mein CUL, was ist mit dem...?")
das hat doch keinen sinn.
wer liest schon einen dreiseitigen thread. ;)
und dann wird trotzdem gefragt, ob der accesspoint nun endlich standalone funktioniert.
Zitat von: frank am 03 Dezember 2020, 17:35:19
das hat doch keinen sinn.
wer liest schon einen dreiseitigen thread. ;)
und dann wird trotzdem gefragt, ob der accesspoint nun endlich standalone funktioniert.
Ob es drei Seiten sind, hängt von den Forumseinstellungen ab ;D .
Und ja, vermutlich kann man heute einen Wiki-Artikel veröffentlichen, in dem klar zu lesen ist, dass ein standalone AP NICHT geht (was btw. gar nicht stimmt, irgendwer hatte irgendwo hier ein script... ::) ), den von überall her verlinken und es kommt trotzdem morgen einer auf die Idee, zu fragen, ob das denn jetzt wirklich noch Stand der Dinge ist...
(Aber jetzt bin ich hier wirklich weg, HM-IP ist einfach nicht meine Baustelle und wird es auch nicht ;D ).
Moin
So habe meine Posts angepasst. Danke Horti!
Ein link im wiki genau dorthin waere meines Erachtens die Loesung!
Irgendwie bin ich sehr erstaunt. Aber erstmal egal, gehoert hier auch nicht hin!
Gruss Christoph
Zitat von: MadMax-FHEM am 02 Dezember 2020, 15:33:21
Und nicht die hier:
https://de.elv.com/elv-komplettbausatz-funk-modulplatine-fuer-raspberry-pi-3-b-rpi-rf-mod-fuer-homematic-und-homematic-ip-152941
(da ist es in der Tat [verm.] nur ein Kondensator)
Nein, das ist nicht nur ein Kondensator, sondern:
- Vielfach verbesserte Systemperformance ggü. der Homematic Zentrale CCU2*
Einfachste Inbetriebnahme – einsatzfertiges HM-OCCU-Image**
Unterstützung von Homematic und Homematic IP (jeweils Wired und Funk)
Stark verbesserte Funk-Reichweite durch neueste Transceiver-Generation (im Vergleich zum Vorgängermodul HM-MOD-RPI-PCB)
Echtzeituhr mit Goldcap-Back-up und 2 Tagen Gangreserve für autarke Zeitbasis auch bei Strom- oder Internet-Ausfall
Anzeige des Systemzustands über eine RGB-LED
Tasten zum Starten des Rettungssystems
Abmessungen (B x H x T): 52 x 87 x 19 mm
Exakt passendes Schutzgehäuse für Wandmontage (optional)
Für die Stromversorgung empfehlen wir ausdrücklich das unter Zubehör gelistete Steckernetzteil mit 5V/2,5A
Bitte nicht nur das erste Bild ansehen, sondern auch...
Grüße Jörg
@JoWiemann: Bitte nicht einfach aus dem Zusammenhang reißen!
Es ging um's LÖTEN!
Da hatte ich mich vertan (leider: "falsches" Modul "klein" gegen "groß" ;) ) und genau DAS hiermit korrigiert...
Gruß, Joachim
P.S.: und das mit der besseren Funk-Qualität wurde hier auch schon angezweifelt und auf einen Homematic-Thread verwiesen (wenn ich das richtig im Kopf habe)...
S. Vorschlag (https://forum.fhem.de/index.php/topic,116424.0.html).
Korrekturen/weitere Punkte nehme ich gerne entgegen, sofern sie nicht zu weit von eigentlichem Thema führen :)
Sehr geil!
Zitat von: Horti am 03 Dezember 2020, 19:38:01
[...] das gerne ins Wiki übernehmen
Die betreffenden Änderungen (etwas anders, da es eine allg. Seite "HomeMatic IP" schon gab) sind über diese Seite zu sehen.
https://wiki.fhem.de/wiki/Spezial:Letzte_%C3%84nderungen
Wäre nett, wenn da noch der eine oder andere HMCCU-Nutzer drübersehen könnte, insgesamt sind die HM-IP-Einträge im Wiki nach meinem Eindruck eher spärlich verlinkt.
Zitat von: dieda am 03 Dezember 2020, 01:19:20
Dann mal her damit. Wie hast du das umgesetzt?
Was genau möchtest du jetzt haben? Ich hab zwei HmIP-HAP-B (die Silvercrest-gebrandete Version) und drei HM-LAN-GW an einer CCU3 Charly, also Bausatz aus RPI3b+ und RPI-RF-MOD, laufen. Persepektivisch werde ich die RPI-RF-MOD ersatzlos streichen und nur noch über die HmIP-HAP/LAN-GW funken, denn dann kann ich den Raspberry durch eine Virtualisierung ersetzen (denke es wird Proxmox).
Angekoppelt sind 203 Hm/HmIP-Geräte (wobei noch etwa 20 auf ihren Einsatz warten).
Hi,
Zitat von: Christoph Morrison am 04 Dezember 2020, 09:37:22
Persepektivisch werde ich die RPI-RF-MOD ersatzlos streichen und nur noch über die HmIP-HAP/LAN-GW funken, denn dann kann ich den Raspberry durch eine Virtualisierung ersetzen (denke es wird Proxmox).
Wird so nicht funktionieren, für die Anbindung der HmIP-HAP brauchst du zwingend ein RPI-RF-MOD, weil die Kryptofunktionen von HmIP komplett darin ablaufen. Die HmIP-HAP werden nur als "dumme" Antennen verwendet.
Viele Grüße
Alex
Hab jetzt einen Teil ins Wiki übertragen, Details siehe:
https://wiki.fhem.de/wiki/Spezial:Letzte_%C3%84nderungen
Das sieht schon mal sehr gut aus. Vlt. könnte man auch auf die verschiedenen Docker dazu packen. Gibt ja doch so einige.
Interessant ist vielleicht noch für den einen oder anderen: Eine CCU3 ist nichts anderes als ein Raspi mit Funkmodul in einem einigermaßen schicken Gehäuse.
Moin,
LED auf RPI-RF-MOD an Raspi mit debmatic (4 x installiert) leuchtet zunächst blau.
Ich starte WEBUI, melde mich an,
dann starte ich Gerät anlernen.
Im Moment, wo sich das Gerät ( hier ein magnetischer TFK ) meldet blitzt der Kringel auf und sofort danach fängt die LED über dem blauen Dauerleuchten gelb ( eigentlich rot-grün ) schnell zu Blinken an.
Glaubt man der Bauanleitung, dann soll das fehlender Netzkontakt sein. Aber der RasPi kann die ganze Welt anpingen und auch Updates holen.
Hat jemand eine Idee am 13ten für mich ?
@Ralph
2 Fragen:
Was ist mit Netzkontakt gemeint?
Welche spannunsversorgung nutzt du?
Grüße Christoph
Zitat von: pc1246 am 13 Januar 2021, 19:39:20
Was ist mit Netzkontakt gemeint?
O-Ton: Keine Verbindung zum Netzwerk bzw. zum Router
Zitat von: pc1246 am 13 Januar 2021, 19:39:20
Welche spannunsversorgung nutzt du?
Steckernetzgerät 5V 3A direkt oder
Steckernetzgerät 5V 3A - in HAT MiniUSV - an RasPi
beides probiert
Hi,
Zitat von: Ralph am 13 Januar 2021, 15:07:16
Im Moment, wo sich das Gerät ( hier ein magnetischer TFK ) meldet blitzt der Kringel auf und sofort danach fängt die LED über dem blauen Dauerleuchten gelb ( eigentlich rot-grün ) schnell zu Blinken an.
Meinst du damit, dass das blaue Leuchten aufhört und danach nur noch gelb geblinkt wird oder meinst du damit, dass im Wechsel blau und gelb blinken? Was meinst du mit schnell blinken für eine Frequenz?
Ich tippe nämlich ehrlich gesagt darauf, dass es ein blau/gelbes Blinken mit ca. 1 sec ist und dann wäre es eine Service Meldung, welche durch ein unvollständiges Anlernen auftreten kann, wenn der HMServer den KeyServer von eQ-3 nicht korrekt erreichen kann oder der Keyserver mal wieder Schluckauf hat. Dann müsste es gehen, dass du mittels manueller SGTIN/Key anlernst.
Viele Grüße
Alex
Moin,
wie ich schon schrieb: Blau leuchtet ruhig weiter, darüber blinkt es gelb im 1 sek-Takt.
Das mit dem Anlernfehler könnte schon sein. Internet ist auch erreichbar.
Mir war nicht klar, dass bei eQ-3 ein Server beteiligt ist, der Schluckauf haben könnte. Ich wollte es doch extra lokal haben.
Das hätte mir der Hotliner ja auch sagen können.
Wegen drohender Versäumnis der Widerrufszeit habe ich es heute morgen schon zurückgeschickt.
Aber wenn das tatsächlich an der Antwortzeit dieses Servers liegen sollte, dann werde ich später nochmal einen Versuch mit
der USB-Platine von Alex Reinert und dem Modul versuchen. Die USB-Platine deshalb, weil das Modul nahezu alle GPIOs klaut, die ich brauche.
Danke für die Antworten.
Hi,
Zitat von: Ralph am 14 Januar 2021, 08:49:07
wie ich schon schrieb: Blau leuchtet ruhig weiter, darüber blinkt es gelb im 1 sek-Takt.
das ist bei nur einer RGB LED physikalisch unmöglich, wenn Blau dauerhaft leuchtet und gelb (= rot und grün) blinkend dazu kommt, dann würde es weiß blinken, weil dann alle drei Farben gleichzeitig leuchten.
Zitat von: Ralph am 14 Januar 2021, 08:49:07
Das mit dem Anlernfehler könnte schon sein. Internet ist auch erreichbar.
Mir war nicht klar, dass bei eQ-3 ein Server beteiligt ist, der Schluckauf haben könnte. Ich wollte es doch extra lokal haben.
Das hätte mir der Hotliner ja auch sagen können.
Es ist ein Wunder, dass sie überhaupt mit dir telefoniert haben, meistens wiegeln die leider sofort ab, wenn man debmatic, piVCCU oder RaspberryMatic nur ansatzweise erwähnt. Und leider haben sie im First Level nur sehr eingeschränkt Ahnung von den technischen Details, die bei einer CCU Lösung unter der Haube stecken.
Für die gilt einfach CCU = Lokale Lösung, AccessPoint = Cloud Lösung. Das bei der CCU für den Anlernvorgang mit Internet-Zugang und beim Wechsel des Funkmoduls auch deren Keyserver genutzt wird, ist ihnen leider nicht klar. Glücklicherweise wird das aber nur für diese beiden Vorgänge benötigt und zumindest für den initialen Anlernvorgang gibt es ja den Workaround über die manuelle Eingabe von SGTIN und Key, so dass die Angabe, dass es lokal läuft ja auch fast stimmt.
Viele Grüße
Alex
OK, das mit dem Farbenspiel ist bei mir als Starkbrillenträger nicht immer so eindeutig. Sieh es mir bitte nach.
Ich hatte leider vergessen zu erwähnen, dass es mit Key und SGTIN auch nicht gefruchtet hat.
Ich habe es mindestens über einen Zeitraum von 2 Stunden ständig probiert, weil ich zwar sowas geahnt, aber eben nicht gewusst habe.
Insofern bin ich für die Aufklärung dankbar.
Ketzerische Frage: bist du sicher, dass du die richtige Anlernvariante gestartet hast?
Als ich mit einer CCU angefangen hatte, wollte ich ein Bidcos Gerät über HmIP anlernen, was natürlich nicht funktioniert hat.
Mir ist erst später aufgefallen, dass beide Bereiche ihr eigenes Anlernen haben.
Zitat von: jhohmann am 14 Januar 2021, 17:52:15
Ketzerische Frage: bist du sicher, dass du die richtige Anlernvariante gestartet hast?
Danke, aber Nein, keine Sorge, habe schon bei einem Freund mit einer originalen CCU3 vieles gelernt.
Will selbst aber bei FHEM beiben, da ich auch noch FS20 und alle Vor- und Nachläufer habe.
Hi,
ich habe nun seit mehreren Jahren Fhem mit u.a. Homematic Komponenten im Einsatz. Verschiedene Komponenten in Docker Containern (Fhem, HA-Bridge, zigbee2mqtt). Nun habe ich diverse HomematicIP Komponenten gesehen die ich gerne nutzen würde ( Hörman Garagentor Aktor, HMIP Sirene...). Ich habe einige Thread und die Anleitungen von Jens Maus gelesen und verstanden, dass ich einen zusätzlichen Container mit RaspberryMatic einrichten muss um HMIP zu nutzen.
Was mir nun nicht ganz klar ist ist die Sache wie eine optimale Kombination in der Nutzung von HomeMatic und HMIP aussieht.
1. Wenn ich nur einen Funkadapter habe verwende ich den für RaspberryMatic und verwaltet alle HM Komponenten darüber und ich schalte alles von Fhem aus ?
2. Alles bleibt wie jetzt nur ein 2. Adapter mit RaspberryMatic für die HMIP Komponenten und verwalte und schalte mit Fhem den Rest ?
3. oder ??? Vorschläge
Was meinen die Profis dazu, was hat sich bewährt ? Auch unter Geschwindigkeits- und Usabilty Aspekten...
VG,
Andreas
Zitat von: essera am 01 Februar 2021, 23:00:22
1. Wenn ich nur einen Funkadapter habe verwende ich den für RaspberryMatic und verwaltet alle HM Komponenten darüber und ich schalte alles von Fhem aus ?
2. Alles bleibt wie jetzt nur ein 2. Adapter mit RaspberryMatic für die HMIP Komponenten und verwalte und schalte mit Fhem den Rest ?
Über diese Frage habe ich auch lange gegrübelt und grüble noch. Endgültig habe ich da noch nicht entschieden, zumal ich außer der HM-Welt noch Älteres betreibe.
Klar ist:
Für HmIP musst Du etwas Zusätliches haben, der bisherige kleine Chip reicht nun nicht mehr. Entweder diesen tauschen gegen die größere Platine oder eine andere Hardware dafür. ich habe mich für einen USB-Stich entschieden (derzeit).
Außerdem brauchst Du noch Software, die HmIP bedient. Bei mir ist es debmatic geworden.
Ich - andere mögen es anders tun - bediene jetzt meine einigen weigen HmIP-Teile über den WebGUI von debmatic anlernmäßig und dann betrieblich mit FHEM.
Die HM-(ohne IP)Komponenten bediene ich nach wie vor über den keinen HM-Chip.
Grund: mit HM und deren Outputs und Readings bin ich einigermaßen vertraut, mit den Readings der HmIP-FHEM-Adaption fremdle ich noch sehr, zumal es selten dieselben sind und sich teilweise anders verhalten.
Aber wie schon gesagt: meine persönliche Meinung.
Hallo zusammen!
Da in letzter Zeit bei mir Homematic Rauchmelder gestorben sind, habe ich mich auf die Suche nach Ersatz gemacht. Recht schnell bin ich darüber gestolpert, dass wohl die ganzen Homematic nicht IP Geräte scheinbar am aussterben sind, zumindest sieht es sehr sehr mau aus mit Verfügbarkeiten.
Okay, muss ich mich wohl doch langsam mal mit Homematic IP beschäftigen....
Mir stellten sich dann mehrere Fragen:
- Mit welcher Hardware bekomme ich den Zugriff auf die Homematic IP Komponenten?
Soweit habe ich verstanden, dass ich mir z.B. einen Raspberry zusammenschustern kann mit passendem Modul. Da kann ich dann die frei verfügbare CCU Software installieren und insgesamt verhält sich das Gerät dann so wie die CCU, die von ELV vertrieben werden. - Was passiert, wenn die CCU mal kaputt geht? Muss ich dann alle Geräte neu anlernen?
Soweit ich recherchiert habe, reicht es wohl, ein Backup der CCU zu haben. Das kann ich dann auf einer beliebig neuen CCU einspielen und die sollte nach etwas Wartezeit und Internet-Verbindung wohl die HM-IP Geräte wieder erreichbar machen. - Wie kann ich die HM-IP Geräte dann in FHEM nutzen?
Also soweit gibt es wenn ich es richtig verstanden habe, ein Modul mit dem ich die CCU via RPC Schnittstelle verbinden kann. Wenn ich es richtig verstanden habe, sind die Readings wohl anders. Aber das ist denke ich auch nur eine Gewohnheitssache vermute ich mal.
Was ich mich jetzt frage, ihr mir helfen könntet (und vielleicht auch denen, die meinen Post später mal lesen):
- Welche Hardware-Kombination würde sich denn anbieten? Das Komplettset von ELV (https://de.elv.com/elv-bausatz-smart-home-zentrale-charly-starter-set-schwarzes-gehaeuse-250297) ist aktuell nicht verfügbar. Was würde sich denn alternativ für jemanden wie mich empfehlen, der mit dem Lötkolben nicht so wirklich geübt ist? Da ich mit Linux und Virtualisierung recht fit bin, wäre auch eine Variante wo ich z.B. die CCU in Docker laufen lassen, sehr interessant (und reduziert die Hardware, die permanent bei mir laufen muss und Strom schluckt), also vermutlich etwas wie ein USB-Stick?
- Gibt es irgendwelche gravierenden Nachteile bei der Anbindung einer CCU gegenüber meiner jetzigen Variante (Busware CUL868 USB-Stick)? Delays? Weniger Möglichkeiten?
- Wenn ich auf eine CCU umsteige, würde ich vermutlich auch die Homematic-Alt Hardware auf die CCU konsolidieren, damit alles zusammen läuft und kein Wildwuchs entsteht. Würde ich damit irgendwas aufgeben? Außer die Möglichkeit, eine VCCU nutzen zu können?
Ich kann nur von mir sprechen...
Es gibt verschiedene Möglichkeit neben einer gekauften CCU eine auf einer Raspi oder Proxmox oder Docker zu betreiben. Da hast du div. Möglichkeiten.
FHEM hat im Wiki dazu einiges geschrieben.
Rundumsorglos ist Raspberrymatic. Eine SD-Karte geschrieben, USB-Dongle oder Karte aufgesteckt auf den Raspi, eingeschaltet und los geht's. Der Anleitung im WIKI folgen und die Geräte werden rübergeholt.
Ist alles eingerichtet, dann ein Backup anlegen. Raucht die SD-Karte ab, Raspberrymatic neu draufziehen und das Backup einspielen.
Ich habe mir meinen USD-Dongle im pinken Laden mit dem T gekauft https://www.smarthome.de/geraete/smarthome-funkstick-fuer-homematic-ip-weiss . Er macht hier alles was er soll. Einige haben hier aufgeschrieen, meinte, dass einiges nicht geht. Das konnte ich nicht bestätigen. Aber auch das Steckmodul ist einfach zu montieren.
Hier ist eine kurze Zusammenfassung über aktuell verfügbare Funkmodule, speziell im Hinblick auf virtualisierte CCU, s. auch https://homematic-forum.de/forum/viewtopic.php?f=65&t=71219&p=692945&hilit=HB+RF+ETH#p692945 (https://homematic-forum.de/forum/viewtopic.php?f=65&t=71219&p=692945&hilit=HB+RF+ETH#p692945):
ZitatVereinfacht gesagt braucht jede Zentrale die mit HmIP arbeiten soll ein Funkmodul.
Die aktuell optimalste Option wäre das RPI-RF-MOD.
Das HM-MOD-RPI-PCB geht auch, hiermit funktioniert aber kein IP-Wired und kein Advanced-Routing.
Möglicherweise reicht demnächst auch ein HmIP-RFUSB, hier ist noch offen was dann alles damit geht.
Die beiden Funkmodule kannst du auf 3 verschiedene Arten anschließen.
GPIO bei Raspberry, Tinker etc
USB bei allen mittels HB-RF-USB-2
LAN bei allen mittels HB-RF-ETH
Die LAN Option ist hier die flexibelste Variante, die Zentrale kann im Keller hocken und das Funkmodul irgendwo Zentral im Haus.
HmIP-RFUSB würde ich aber nicht bei der Telekom kaufen, denn die verkaufen eine "TK"-Variante, die zwar (im Moment) funktioniert, aber da gab es schon Gerüchte, dass es nicht immer so bleiben muss, denn eq-3 und Telekom sind sich nicht immer einig. Aber auch ansonsten wird dieses Funkmodul eher stiefmütterlich behandelt von eq-3. Dazu kommt, dass es nur HmIP kann, nicht aber Homematic BidCos / Classic / alt.
Ich würde mich eher auf die beiden anderen konzentrieren. Das große, RPI-RF-MOD, wenn man mit einem Funkmodul nicht auskommt und zur HmIP-Reichweitenverlängerung HAPs einsetzen will oder wenn man HmIP-Wired nutzen will. Ist beides nicht der Fall, ist man mit dem HM-MOD-RPI-PCB bestens bedient. Bezüglich Einbindung über Ethernet oder USB verhalten sich beide gleich. Für HM-MOD-RPI-PCB gibt es außerdem noch HB-MOD-UART-USB (https://github.com/stan23/myPCBs/tree/master/HB-MOD-UART-USB), damit lässt es sich als kompakter USB-Stick verpacken und über ein USB-Verlängerungskabel unauffällig absetzen, das nutze ich nun seit einiger Zeit mit einem 1m-Verlängerungskabel.
Hi,
für den HmIP-RFUSB (ohne TK, also der Bausatz von elv) gibt es eine neue Firmware, mit welcher es auch möglich werden wird, den vollumfänglich mit BidCos und HmIP zu nutzen und so wie es sich aktuell darstellt, wird es mit dem sogar möglich sein, auch den HAP oder DRAP anzubinden, Funktionsumfang wird also vergleichbar sein mit dem RPI-RF-MOD.
Ich bin noch an der Anpassung der notwendigen Kernel Module und der ganzen Einbindung, aber ich bin recht zuversichtlich, dass ich einen entsprechenden Support in debmatic und piVCCU noch vor Weihnachten veröffentlichen kann.
Der HmIP-RFUSB-TK (also Telekom Fertiggerät) kann leider nicht mit der Firmware bestückt werden, der wird also weiterhin nur HmIP können und ich würde mich nicht drauf verlassen, dass er dauerhaft mit dem Stack von eQ-3 lauffähig bleiben wird.
Viele Grüße
Alex
Das ist ja eine gute Nachricht!
Ist denn sowas Ähnliches auch für HM-MOD-RPI-PCB geplant? Denn BidCos bekommt HmIP-RFUSB vermutlich nicht beigebracht, oder?
Hi,
Zitat von: Horti am 09 Dezember 2021, 12:57:00
Ist denn sowas Ähnliches auch für HM-MOD-RPI-PCB geplant? Denn BidCos bekommt HmIP-RFUSB vermutlich nicht beigebracht, oder?
Zitat von: deimos am 09 Dezember 2021, 11:48:36
für den HmIP-RFUSB (ohne TK, also der Bausatz von elv) gibt es eine neue Firmware, mit welcher es auch möglich werden wird, den vollumfänglich mit BidCos und HmIP zu nutzen [...]
Ich bezweifle aber, dass es eine neue Firmware für das HM-MOD-RPI-PCB geben wird und die DualCoPro Firmware für den war wohl auch eher ein Versehen.
Viele Grüße
Alex
Also wenn ich dich richtig verstehe @deimos, ist wohl der Stick von ELV (https://de.elv.com/elv-homematic-ip-arr-bausatz-rf-usb-stick-fuer-alternative-steuerungsplattformen-hmip-rfusb-fuer-smart-home-hausautomation-152306) dann wohl eine gute Wahl. Preislich vertretbar kann ich mir auch mal einen als Fallback bei Seite legen und die Hardware, auf dem ich die CCU laufen lasse, ist dann ja eh beliebig so lange ich einen USB-Anschluss habe.
Kann der Stick dann HM und HM-IP sprechen oder jeweils nur eines von beidem?
Hi,
der Stick wird dann gleichzeitig BidCos (= HM) und HmIP können. Verglichen mit dem RPI-RF-MOD ist er deutlich günstiger bei vergleichbarem Funktionsumfang (Wenn man mal vom Fehlen der LED, dem Taster und der RTC absieht).
Mit debmatic bist du dann auch relativ frei in der Hardwarewahl.
Was ich aber noch nicht abschließend beurteilen kann, ist die Sende- und Empfangsqualität im Vergleich zu den anderen verfügbaren Funkmodulen.
Im Zweifel würde ich noch in den USB-EF1 investieren, bei der Entwicklung der HB-RF-USB und HB-RF-USB-2 habe ich gemerkt, dass ein LC Filter sich sehr positiv auf die Sende- und Empfangsqualität auswirkt und dementsprechend bei den beiden Platinen einen vorgesehen. Beim HmIP-RFUSB gibt es diesen nicht und mit dem USB-EF1 kann man diesen einfach nachrüsten.
Viele Grüße
Alex
Na dann bestelle ich mir mal USB-EF1 und HmIP-RFUSB und warte darauf, dass ich es das in Betrieb nehmen kann :-)
USB-Stick hat auch den Vorteil, dass ich den mit Verlängerungskabel oder USB-Hub woanders hin verlagern kann.
Gibt es denn mittlerweile schon Bestrebungen das HM-IP- Protokoll ohne Debmatic usw. nutzen zu können - also so wie HM Classic?
Das muss sich doch auch reengineeren lassen oder Mister Redeker könnte erkannt haben, dass er durch Offenlefung des Protokolls noch viel mehr verkaufen könnte... ;) Ich hab hier schon ein paar HMIP- Sachen liegen, aber das mit der Debmatic oder zusätzlicher CCU kotzt mich total an.
Gruß
Frank
@fiedel: es gab hier vor 1 oder 2 Jahren schon mal einen Nutzer, der das HMIP Protokoll mal eben reverse engineeren wollte. Habe nie wieder etwas davon gehört. Aber feel free ...
Es braucht auch kein separates Gerät. Man kann durchaus FHEM und die CCU Software auf dem gleichen Gerät betreiben. Man muss dabei nur einige Dinge bei der Startreihenfolge beachten.
Ich glaube nicht, dass EQ3 das Protokoll bzw. die Verschlüsselung offenlegen wird. Schließlich sind die Schnittstellen der CCU offen und dokumentiert und werden von vielen Smarthome Lösungen seit Jahren genutzt.
Zitat von: prodigy7 am 09 Dezember 2021, 20:00:02
Na dann bestelle ich mir mal USB-EF1 und HmIP-RFUSB und warte darauf, dass ich es das in Betrieb nehmen kann :-)
USB-Stick hat auch den Vorteil, dass ich den mit Verlängerungskabel oder USB-Hub woanders hin verlagern kann.
Moin
hast du schon Erfahrungen mit dem Stick sammeln können??
Gruß Ingo
Zitat von: Oldsurfer am 29 Dezember 2021, 18:58:03
hast du schon Erfahrungen mit dem Stick sammeln können??
Ne, liegt bei mir noch ungenutzt rum. Muss ich mich die Tage mal darum kümmern!
HmIP-RFUSB wäre beim Neueinstieg also mittlerweile der empfehlenswerte Weg (CCU soll über debmatic in der Proxmox VM auf einem NUC laufen)?
Im neuen Haus, welches wir gerade renovieren, gibts es bisher eine Fußbodenheizung welche keine Ventile hat, sondern fest über Drehregler eingestellt über die Zeitsteuerung der Heizung heizt.
Würde nun gern die Homematic IP 12fach Fußbodenheizungs-Steuerung mit den motorisierten Ventilen einbauen, habe bisher aber keinerlei Homematic.
Vorerst ist sonst nichts an Homematic geplant, wenn doch wird es wahrscheinlich bei HmIP bleiben.
Hallo,
Reicht für Homematic IP auch ein raspberry pi 2 ? Der ist ja quadcore 900mhz aber 32bit gegenüber dem 64Bit quadcore 1200mhz pi 3. bei mir sollen maximal 8 Thermostate gesteuert werden. Sollten wirklich später wesentlich mehr Geräte betrieben werden und der pi 2 an seine Grenzen kommen könnte ich immer noch aufrüsten. Aber dennoch habe ich nicht gefunden ob der pi 2 überhaupt tauglich ist.
Gruß
J
Hi,
ist offiziell unterstützt https://github.com/alexreinert/piVCCU/
Gruß Otto
Danke schon mal, ich hatte mit raspberrymatic geliebäugelt.
Da muss ich noch mal nachforschen.
https://github.com/jens-maus/RaspberryMatic/wiki/Einleitung
ZitatVerbesserte Hardwareintegration
Lauffähig auf allen RaspberryPi und ASUS Tinkerboard Single-Board-Computer Modellen
Ich habe RaspberryMatic unter Docker installiert. Dort sieht man, es wird im Kern auf piVCCU Module zurück gegriffen. ;)
Hallo,
Raspberrymatic läuft bei mir in einer VM unter Proxmox. Mit Fhem über HMCCU verbunden. Läuft schon lange stressfrei!
Gruß
Jürgen K.
Zitat von: stratege-0815 am 26 März 2022, 07:44:57
Reicht für Homematic IP auch ein raspberry pi 2 ?
@Jürgen - Proxmox läuft bei Dir auf einem Pi2 ? :o Oder was willst Du mit Deiner Antwort zur aktuellen Frage beitragen? ::) :-X
Zitat von: stratege-0815 am 26 März 2022, 10:29:45
Danke schon mal, ich hatte mit raspberrymatic geliebäugelt.
Da muss ich noch mal nachforschen.
Ich hatte kürzlich RaspberryMatic testweise auf einem RPi 2 installiert. Ich kann zwar nicht wirklich was zur Performance sagen, aber die Bedienung im Browser war zumindest nicht langsamer als bei einer CCU2 und meine paar Testgeräte ließen sich ohne Probleme anlernen und bedienen.
Danke euch allen für das feedback, es hält mich ja nichts davon ab erstmal mit dem pi2 zu starten
For what it's worth, ich habe RaspberryMatic auf einem RPi Model B (also dem "ersten" Modell) laufen und steuere damit 5 HmIP-BROLL. Die Weboberfläche ist nicht so flott, aber die benutzt man, wenn das mal eingerichtet ist ja nicht besonders häufig.
Sonst läuft alles perfekt. Geht also, wenn man nicht viele Geräte hat, sogar mit "weniger" als dem RPi 2 ...
Ich erinnere an meinen post RPCState error Antwort an 48 : Das stellte sich heraus, dass mein Raspberry Pi Model B Plus Rev 1.2 nicht funktionierte.
Zitat: Supported Single Board Computer
Raspberry Pi 2B/3B/3B+/4B running Raspberry Pi OS Buster or Bullseye
Nur als Hinweis das unter 2B nichts geht
Hallo zusammen, ich hoffe ich bin hier richtig.
als Schnittstelle verwende ich seit einigen Jahren meine selbstgebaute Zwischensteckdose, bestehend aus 5V Netzteil, HM-MOD-UART + USR-TCP232-T und einem HM-MOD-PRI-PCB.
FHEM läuft auf einem Raspberry Pi 3 Model B
Ich verwende überwiegend Homematic Komponente und würde gerne auch Homematic IP verwenden. Ich denke das sollte mit meinen vorhanden Gerätschaften möglich sein. Ich glaube aber ich muß noch piVCCU installieren.
ABER beim Versuch einer manuellen Installation von piVCCU scheitere ich schon bei der ersten Eingabe aus dieser Anleitung: https://github.com/alexreinert/piVCCU/blob/master/docs/setup/raspberrypi.md
pi@RasPi-FHEM:~ $ wget -q -O - https://www.pivccu.de/piVCCU/public.key | sudo apt-key add -
gpg: no valid OpenPGP data found.
pi@RasPi-FHEM:~ $
Ist das eine falsche Anleitung oder was mache ich falsch ?? Kann mir da bitte jemand weiterhelfen.
Besten Dank
was ergibt cat /etc/os-release
Siehe auch https://github.com/alexreinert/piVCCU/issues/419
Allerdings kannst Du den IO entweder für CUL_HM in FHEM ODER für die piVCCU verwenden.
Ob dieses Konstrukt mit LAN Anschluss überhaupt mit piVCCU funktionieren kann, kann ich auch nicht sagen. Ich wäre skeptisch ...
pi@RasPi-FHEM:~ $ cat /etc/os-release ergiubt....
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
ich hätte noch einen HM-MOD-PRI-PCB zum aufstecken auf den RasPi.... bringt mich das weiter ??
Für Deinen Versuch mit piVCCU bringt Dich das extra Moduls sicher weiter.
siehe auch: https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Es könnte Sein Deine ca-... ist alt, versuch mal:
sudo apt-get update
sudo apt-get install ca-certificates
Ansonsten was liefert der Befehl?
wget -q -O - https://www.pivccu.de/piVCCU/public.key
pi@RasPi-FHEM:~ $ wget -q -O - https://www.pivccu.de/piVCCU/public.key
pi@RasPi-FHEM:~ $
liefert nichts, nur das prompt kommt zurück.
pi@RasPi-FHEM:~ $ sudo apt-get install ca-certificates
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
ca-certificates ist schon die neueste Version (20200601~deb9u2).
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
gyp libhttp-parser2.8 libjs-inherits libjs-node-uuid libuv1-dev node-abbrev
node-ansi node-ansi-color-table node-archy node-async node-balanced-match
node-block-stream node-brace-expansion node-builtin-modules
node-combined-stream node-concat-map node-cookie-jar node-delayed-stream
node-forever-agent node-form-data node-fs.realpath node-fstream
node-fstream-ignore node-github-url-from-git node-glob node-graceful-fs
node-gyp node-hosted-git-info node-inflight node-inherits node-ini
node-is-builtin-module node-isexe node-json-stringify-safe node-lockfile
node-lru-cache node-mime node-minimatch node-mkdirp node-mute-stream
node-node-uuid node-nopt node-normalize-package-data node-npmlog node-once
node-osenv node-path-is-absolute node-pseudomap node-qs node-read
node-read-package-json node-request node-retry node-rimraf node-semver
node-sha node-slide node-spdx-correct node-spdx-expression-parse
node-spdx-license-ids node-tar node-tunnel-agent node-underscore
node-validate-npm-package-license node-which node-wrappy node-yallist
nodejs-doc
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 313 nicht aktualisiert.
pi@RasPi-FHEM:~ $
und ohne -q?
wget -O - https://www.pivccu.de/piVCCU/public.key
pi@RasPi-FHEM:~ $ wget -O - https://www.pivccu.de/piVCCU/public.key
--2022-05-18 19:52:14-- https://www.pivccu.de/piVCCU/public.key
Auflösen des Hostnamens »www.pivccu.de (www.pivccu.de)« ... 65.108.197.112, 2a01:4f9:1a:9956:7::8
Verbindungsaufbau zu www.pivccu.de (www.pivccu.de)|65.108.197.112|:443 ... verbunden.
FEHLER: Dem Zertifikat von »www.pivccu.de« wird nicht vertraut.
FEHLER: Das Zertifikat von »www.pivccu.de« ist abgelaufen.
naja ich glaube offiziell ist debian stretch nächsten Monat EOL - aber wie gesagt Deine ca-certificates sind alt und offenbar geht kein update?
Ist der Kernel überhaupt unterstützt? https://github.com/alexreinert/piVCCU/
uname -a
Linux RasPi-FHEM 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l inux
piVCCU is a project to install the original Homematic CCU3 firmware inside a virtualized container (lxc) on ARM based single board computers.
ist das bei mir nicht der Fall ?
Hi,
wenn du bereits am Download des Keys scheiterst, dürfte das sehr wahrscheinlich daran liegen, dass dein System mit Stretch nicht mehr mit den aktuellen Root Zertifikaten von Let's Encrypt klarkommt.
Ruf den wget Befehl mal ohne den Parameter "-q" (quiet) auf, dann dürfte da eine entsprechende Fehlermeldung kommen.
Du kannst versuchen das zu fixen mit:
sudo atp update
sudo apt upgrade
sudo apt install libgnutls-openssl27 libgnutls30
sudo apt install --reinstall ca-certificates
An sich solltest du aber deinen Pi aktualisieren, stretch ist einfach komplett out of service und dementsprechend habe ich das nicht mehr im Testplan von piVCCU drin.
Viele Grüße
Alex
Zitat von: ms_steini am 19 Mai 2022, 00:02:10
Linux RasPi-FHEM 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l inux
piVCCU is a project to install the original Homematic CCU3 firmware inside a virtualized container (lxc) on ARM based single board computers.
ist das bei mir nicht der Fall ?
Mir ging es um
ZitatAt least kernel 4.14
Aber wie Alex auch schon sagt, alles was Du da jetzt tust ist maximal "Schminke"
OK, verstanden.... was wäre denn der sinnvollste Weg das vernünftig in Ordnung, bzw. auf einen aktuellen Stand zu bringen.
Ich habe über 50 Homematic, div. Shellys, Sonof, Alexa, TelegramBot, PushOver, MQTT usw. am laufen.... und möchte natürlich nicht ganz von vorne beginnen und alles neu machen.
Hi,
Zitat von: ms_steini am 19 Mai 2022, 11:08:33
OK, verstanden.... was wäre denn der sinnvollste Weg das vernünftig in Ordnung, bzw. auf einen aktuellen Stand zu bringen.
System runterfahren, vollständiges Backup der SD Karte machen.
Wieder hochfahren, dann von stretch auf buster upgraden, ausgiebig testen.
System runterfahren, weiteres vollständiges Backup der SD Karte machen.
Wieder hochfahren, dann von buster auf bullseye upgraden, ausgiebig testen.
Anleitung für die einzelnen Upgrades gibt es bei Google zu hauf.
Viele Grüße
Alex
Vielen Dank, werde ich so in den nächsten Tagen mal angehen.....
Aber was soll ich sagen, ich habe solange jetzt daran rumgefummelt und konnte piVCCU instalieren.... WOW, und habe auch schon erfolgreich über das WebUi einen HmIP-MOD-RC8 angemeldet und eingerichtet.
Jetzt muss ich das nur noch in FHEM kriegen....
Also Alex seinen Weg kann man machen - würde ich aber nicht ...
Backup von FHEM machen.
Wenn Du keine Doku über Dein System hast ::)
Neue SD, neues Image, FHEM von debian.fhem.de installieren.
apt install apt-file libperl-prereqscanner-notquitelite-perl
das neue leere FHEM starten
define installer Installer
attr installer installerMode developer
Die fhem.cfg bereithalten und mit get installer checkPrereqs /Pfad/fhem.cfg wird die fhem.cfg überprüft.
Fehlende Module nachinstallieren.
altes Backup mit restore einspielen.
Schauen ob alles läuft. Im schlimmsten Fall erstmal wieder die alte SD rein und weiter drüber nachdenken. Geht alles in allem viel schneller als die Arie von A nach B nach C - die auch versteckt schief gehen kann und dann doch später in "alles neu" enden kann.
Alles gut dokumentieren, fürs nächste mal!!!
Das Update verdrängen ist wie bei Beinbruch nicht zum Arzt gehen :)
Otto123, das hört sich gut an, und da ich hier noch ein paar Raspberrys rumfliegen habe kann ich mein laufendes System unberührt lassen bis das neue 100% läuft.
so werde ich das machen...
Besten Dank
Du kannst das neue System gerne damit einrichten https://github.com/heinz-otto/raspberry
Letzte wget Zeile - drei Scripts - da bist Du mit wenigen Schritten fertig. Am Anfang legst Du die alte fhem.cfg hier bereit /home/pi/fhem.cfg
@Otto123, danke, schaue ich mir an....
jetzt hänge ich beim starten vom RPC Server "Start of RPC server failed"
2022.05.19 13:43:39 1: HMCCU [piVCCU_ccu3] Delayed I/O device initialization
2022.05.19 13:43:39 2: HMCCU [piVCCU_ccu3] Deleting old CCU configuration data
2022.05.19 13:43:39 1: HMCCU [piVCCU_ccu3] Found no interfaces on CCU
2022.05.19 13:43:39 1: HMCCU [piVCCU_ccu3] No RPC interfaces found on CCU 192.168.xxx.xxx
2022.05.19 13:44:32 2: HMCCU [piVCCU_ccu3] RPC server start: 0 started, 0 already running, 0 failed to start
2022.05.19 13:44:32 1: HMCCU [piVCCU_ccu3] HMCCU: piVCCU_ccu3 Start of RPC server failed
Den Wiki Artikel hast Du gelesen? Schau Dir mal den Abschnitt Firewall und CCU Anmeldung an.
Scheint so zu sein, als könnte FHEM nicht richtig auf die CCU zugreifen
ja ich denke ich habe alles gelesen....
Firewall alles auf Vollzugriff, Ports offen, und Authentifizierung abgewählt.
Habe auch schon einige Kommentare hier im Forum gelesen, die genau darauf hindeuten.... aber alles was dort vorgeschlagen wird habe ich versucht, ohne Erfolg.
ich hab's geschafft... nach unzähligen Recherchen und lesen von Forenbeiträgen hab ich es endlich geschafft einen HmIP-MOD-RC8 mit seinen 8 Kanälen in FHEM zu integrieren.
Ich bin happy und doch ziemlich erledigt nach dem ganzen lesen.... vermutlich ist es einfacher den Koran zu lesen und zu verstehen ;D
Zitat von: ms_steini am 19 Mai 2022, 20:35:37
ich hab's geschafft... nach unzähligen Recherchen und lesen von Forenbeiträgen hab ich es endlich geschafft einen HmIP-MOD-RC8 mit seinen 8 Kanälen in FHEM zu integrieren.
Ich bin happy und doch ziemlich erledigt nach dem ganzen lesen.... vermutlich ist es einfacher den Koran zu lesen und zu verstehen ;D
Wenn du Erfahrungen hast, magst du die vielleicht im Wiki dokumentieren? Stehe aktuell vor der gleichen Herausforderung