Hallo!
Ich arbeite mit einem Raspberry und
der piVCCU (https://github.com/alexreinert/piVCCU).
Und ich habe es auf dieser Basis hinbekommen, erste kleine
Skripte in der CCU3-Oberfläche zu testen.
Der nächste Schritt wäre, eine Web-Seite anzulegen,
mit der die Skripte aufgerufen werden könnten.
Also eine Art Oberfläche/Framekwork, das CCU3-Skripte
aufrufen (und idealerweise auch Einstellmöglichkeiten hat:
typische Anwendung wäre, eine Gruppe von Thermostaten
auf einen in der Oberfläche definierten Wert zu stellen).
Gibt es dafür ein Tutorial? Hat jemand das schon probiert
und kann ein Framework/Tool dafür empfehlen, das auf
FHEM aufsetzt (oder vielleicht sogar direkt mit der
CCU3 korrespondiert)?
Die Frage wäre dabei auch, ob die Skriptsprache, die
CCU3 anbietet, auch in FHEM integriert werden kann?
Das machst du einfach übers HMCCU-Modul (https://wiki.fhem.de/wiki/HMCCU)
set <dein_hmccu_device> hmscript <dein_ccu_script>
Aber viel einfacher ist es deine von der CCU in FHEM rein geholten Homematic-Geräte direkt im FHEM anzutriggern. Baust dir ein paar Dummies mit den Schaltern oder Slidern oder Dropdowns oder was auch immer, dann ein Notify, was die gewünschten Aktionen ausführt.
Ryker
Ah, das klingt einfach. Danke!
Beim Ausprobieren des Skriptes
hat sich anscheinend noch ein Problem gezeigt:
"HMCCU: d_ccu Start of RPC server failed"
Ich versuche, die CCU3 als Gerät mit FHEM anzusprechen
(also keinen Stick oder ein HM-MOD-RPI-PCB, sondern die CCU3-Box).
Ich dachte, die hätte einen RPC-Server.
Wenn ich das Skript aus de Dokumentation aufrufe mit:
set d_ccu hmscript /opt/fhem/sysvars.scr
passiert erstmal nichts. Vielleicht hat es mit dem RPC-Server ja zu tun.
Du hast ein bisschen in dem Link von Ryker gelesen?
https://wiki.fhem.de/wiki/HMCCU#RPC_Server_konfigurieren_und_starten
Ja, habe ich mir angeschaut.
Beim Blickin die Logdatei bin ich noch auf ein Problem gestoßen:
Zitat
CUL: Can't open /dev/ttyS0: Permission denied
Dann habe ich die Rechte händisch geändert und neu gestartet.
mir ist nicht klar, wofür die serielle Schnittstelle gebraucht wird,
da ich ja eigentlich die externe CCU3-Box als HMCCU definiert habe).
Die Fehlermeldung ist jetzt weg, allerdings eine andere noch da:
Zitat
2021.12.28 08:38:10 1: HMCCU [d_ccu] CCU port 8181 is reachable
2021.12.28 08:38:10 1: HMCCU [d_ccu] Initialized version 5.0 213491649
2021.12.28 08:38:10 1: HMCCU [d_ccu] Initializing device
2021.12.28 08:38:10 2: HMCCU [d_ccu] Deleting old CCU configuration data
2021.12.28 08:38:10 1: HMCCU [d_ccu] Found no interfaces on CCU
2021.12.28 08:38:10 1: HMCCU [d_ccu] No RPC interfaces found on CCU 192.168.178.46
In der Anleitung steht:
Zitat
Im nächsten Schritt wird der RPC-Server konfiguriert und gestartet. Zunächst werden mit dem Attribut rpcinterfaces die Schnittstellen bzw. Ports festgelegt, für die sich der RPC-Server bei der CCU registrieren soll. Das Attribut zeigt in einer Auswahlliste die möglichen Schnittstellen an
Bei mir zeigt das Attribut keine Auswahlliste an, sondern nur ein Eingabefeld.
Die HMCCU schreibt:
Zitat
CCUNum 1
Clients :HMCCUDEV:HMCCUCHN:HMCCURPCPROC:
DEF 192.168.178.46
FUUID 61bf8d65-f33f-1edd-a58b-b04e88b7a173800b
NAME d_ccu
NOTIFYDEV global
NR 14
NTFY_ORDER 50-d_ccu
RPCState inactive
STATE inactive/Error
TYPE HMCCU
ccuip 192.168.178.46
ccustate active
ccutype CCU2/3
config 5.0
host 192.168.178.46
prot http
version 5.0 213491649
Moin,
dann hat dein Modul HMCCU keine richtige Verbindung zur CCU.
Du hast die Firewall der CCU entsprechend "frei" konfiguriert?
Wenn HMCCU die CCU "lesen" kann, wird auch die Auswahlbox gefüllt.
Gruß Otto
/dev/ttyS0 hat mit HMCCU nichts zu tun .
In der CCU musst du eigentlich nur in der Firewall die API Zugriffe erlauben, indem du dort "eingeschränkt" oder "vollzugriff" einstellst. Wenn du auch noch CUxD dort laufen hast, dann musst du auch die Firewall Richtline auf "Ports offen" einstellen.
Wenn dann der HMCCU RPC funktioniert, dann kannst du dir auch mit "get d_ccu createDev" deine Homematic- Geräte im FHEM anlegen und braucht dann die CCU nur noch als IO-Device.
Ryker
Zitat von: fgam am 28 Dezember 2021, 09:47:06
Beim Blickin die Logdatei bin ich noch auf ein Problem gestoßen:
Ich würde
attr initialUsbCheck disable 1 setzen und dann save machen, kann sein dann ist der Fehler verschwunden (falls er beim Systemstart auftritt). Klingt mir zumindest so.
Rechte händisch ohne wirklichen Grund ändern ist da eher kontraproduktiv (aber vielleicht auch egal)
Ansonsten wie Ryker sagt: andere Baustelle.
ich hatte bei API Vollzugriff eingestellt, mit eingeschränkt kam es genau zu dem Verhalten (wenn ich mich richtig erinnere)
Zitat
ich hatte bei API Vollzugriff eingestellt, mit eingeschränkt kam es genau zu dem Verhalten (wenn ich mich richtig erinnere)
Das verstehe ich nicht: Was bedeutet API in diesem Zusammenhang, und wie/wo stelle ich den Vollzugriff ein?
Danke für den disable-Befehl, das probiere ich.
Bei den Ports hatte ich 8181 eingestellt.
Vorher gab es einen Fehlermeldung
Zitat
HMCCU [d_ccu] CCU port 8181 is not reachable
Die war danach weg.
Ich bin allerdings nicht sicher, ob ich weitere Ports freigeben muss.
Ist 8083 auch erforderlich?
Oder weitere IP-Adressen?
Zitat von: fgam am 28 Dezember 2021, 11:34:50
Das verstehe ich nicht: Was bedeutet API in diesem Zusammenhang, und wie/wo stelle ich den Vollzugriff ein?
Steht doch hier? https://wiki.fhem.de/wiki/HMCCU#CCU_Firewall_Einstellungen
Zitat
andernfalls müssen die notwendigen Ports im Feld "Port-Freigabe" explizit angegeben werden
8181 hatte ich ja schon angegeben,
8083 habe ich auch noch hinzugefügt.
Die IP der FHEM habe ich auch hinzugefügt.
Könnte sonst noch was fehlen?
Wie finde ich denn noch heraus, welches die notwendigen Ports sind?
Eine Fehlermeldung kommt ja nicht mehr.
Ich habe "Ports offen" bei den CCU3-Firewall-Einstellungen gesetzt (schon von Anfang an).
Das heißt, wenn ich es richtig lese, dass ich gar keine Ports explizit angeben muss.
Insofern sollte das ja schon funktionieren.
Logfile schreibt aber:
2021.12.28 12:18:13 1: HMCCU [d_ccu] HMCCU: d_ccu Start of RPC server failed
Habe gerade nohcmal CCU3 und Raspberry komplett neu gestartet:
Problem besteht weiter. RPC server failed.
Es liegt also nicht an den Freigaben.
Mal schauen ob es nach Silvester besser wird :'( Anstatt einem 4. Verweis aufs Wiki mal ein Zitat
ZitatCCU Firewall Einstellungen
Ab CCU Firmware 2.27.7 sind auf der CCU über das WebGUI folgende Einstellungen vorzunehmen:
Menü "Einstellungen > Systemsteuerung" aufrufen
Button "Firewall konfigurieren" anklicken
Bei "Firewall-Richtlinie" den Eintrag "Ports offen" auswählen, andernfalls müssen die notwendigen Ports im Feld "Port-Freigabe" explizit angegeben werden
Die Rechte für "HomeMatic XML-RPC API" und "Remote HomeMatic-Script API" auf "Vollzugriff" setzen.
Man kann die Rechte auf "Eingeschränkter Zugriff" belassen, muss dann aber im Feld "IP-Adressen für eingeschränkten Zugriff" die IP des FHEM-Servers oder das komplette Subnetz in Subnet-Notation angeben.
Wenn der Zugriff von FHEM auf die CCU ohne Anmeldung erfolgen soll, muss zusätzlich in der Systemsteuerung unter "Sicherheit" die Option "Authentifizierung" deaktiviert werden. Alternativ kann im I/O Device (HMCCU) mit dem Befehl set authentication Benutzername und Passwort der CCU angegeben werden.
Nach einem grundlegenden Erfolgserlebnis kannst Du doch gerne alles soweit zuziehen wie Du denkst - also so würde ich meine Zeit verbringen ;D
Danke, aber auf dieses Zitat habe ich mich vorher auch schon bezogen.
Die Ports stehen auf offen,
>>Die Rechte für "HomeMatic XML-RPC API" und "Remote HomeMatic-Script API" auf "Vollzugriff" setzen.
das ist auch schon passiert.
Alles leider ohne Erfolgserlebnis.
Du hast bisher immer nur von Ports geredet.
Wenn Du jetzt den API Zugriff geschafft hast, hast Du den Zugriff von FHEM aus neu gemacht? DEF neu gesetzt z.B?
Hinweis: wenn Du die CCU und FHEM zusammenstartest wird das uU. nichts. Die CCU braucht eine Weile und muss laufen bevor FHEM zugreift.
Ansonsten sind meine Ideen am Ende. Ich habe das bisher auch nur einmal aufgesetzt und das war ohne Probleme:
piVCCU, Firewall auf relaxed
APi auf Vollzugriff
FHEM d_ccu definiert
rpcinterfaces eingetragen
set d_ccu on
fertig - RPC Server läuft.
Ich habe die CCU gelöscht und nochmal neu definiert. Das hat leider nicht geholfen.
Eine andere Sache ist vielleicht interessant:
ich habe die auf dem Raspberry-System integrierte CCU definiert
und die Ports und Vollzugriffe analog erstellt.
Damit läuft dort RPC und es liest die Geräte (ich habe probeweise
2 Thermostate dieser CCU zugeordnet).
Es scheint also ein spezifisches Problem der Kommunikation mit der ELV-Smarthome-Zentrale
zu sein.
Moin,
irgendwie blick ich jetzt auch nicht ganz durch. Du hast im ersten Post doch von piVCCU geschrieben. Irgendwann tauchte die Bemerkung auf ich habe ne elv CCU3.
Was hast Du denn nun genau? Meines Wissens ist die Zentrale von eq3 auch bloß ein Pi mit einer Platine und einem speziellen Systemimage?
Und ich dachte immer die CCU innen drin ist quasi auch immer die gleiche Software, lediglich die Einbindung ins System ist eine andere. Aber die werden doch auf der eq3 Zentrale keine zweite Firewall aktiv haben.
Hast Du diese Zentrale anders am Netzwerk angebunden? Ist das Problem Dein Netzwerkadmin? ;D
Gruß Otto
Ich kann nachvollizeihen, dass das hier unklar ist.
Zur Klärung:
ich hatte ursorünglich eine Homematic CCU3
https://de.elv.com/smart-home-zentrale-ccu3-inklusive-aio-creator-neo-lizenz-ccu-plugin-151965?fs=3346203468
in Betrieb genommen. Die hatte aber Probleme, alle Thermostate anzusprechen.
Da ich sowieso fhem betreiben will, habe ich dann (unahbhängig von der CCU3!) einen HFUSB-Stick genommen,
diesen in einen Raspberry Pi gesteckt und dort erst Raspberry Bullseye, OS dann piVCCU installiert.
Dann habe ich einen Teil der Thermostate, die auf der ursprünglcihen CCU3 angelernt waren, dort abgemeldet,
und auf den Raspberry Pi mit dem HFUSB-Stick umgelerrnt. Die Kommunikation der Therrmostate
mit dem Raspberry Pi über dei dort integrierte CCU3-Oberfläche funktioniert auch problemlos
(wie ich geschrieben habe, ja auch die Ansteuerung der Thermostate über Skripte, die ich direkt
über die CCU-Oberfläche starte, die der Raspberry mit der piCCU anbietet).
Nachdem ich nun den Stick mit dem Raspberry in Betrieb nehmen konnte, wollte ich im zweiten Schritt gucken,
ob ich in gleicher Weise auch die Homematic CCU3-Zentrale als HMCCU unter fhem definieren kann.
Und damit gibt es nun die hier beschrieben Probleme, dass der RPC server nicht funktioniert.
Es wäre schön, wenn fhem auch mit der Zentrale zusammenarbeiten könnten, weil die auch
alte Homematic-Geräte verwalten könnten, und der Stick leider nicht.
Bei dem System, was ich gerade also mit zwei CCUs betreibe, kann ich theoretisch also mit
define d_ccu HMCCU 192.168.178.55
(Homeematic CCU)
und
define d_ccu HMCCU 192.168.178.56
(Raspberry piVCCU mit HFUSB-Stick)
zwischen den CCUs umschalten.
Und die zweite Variante (piVCCU-System) erkennt einen RPC server,
die erstere (CCU3-Zentrale) nicht.
Was für eine FHEM-Installation hast Du? Eventuell ein Container (Docker)?
Ist bei der CCU3 diese API Anmeldung aktiv?
ZitatWenn der Zugriff von FHEM auf die CCU ohne Anmeldung erfolgen soll, muss zusätzlich in der Systemsteuerung unter "Sicherheit" die Option "Authentifizierung" deaktiviert werden. Alternativ kann im I/O Device (HMCCU) mit dem Befehl set authentication Benutzername und Passwort der CCU angegeben werden.
Das ist nicht die normale Web Anmeldung - also ev. ist es der gleiche Account aber es gibt wohl einmal die Anmeldung an der Admin Oberfläche und dazu noch die Anmeldung an der API. Bei der piVCCU ist zweiteres per default nicht aktiv.
Vielleicht ist auch die Firewall freigeschaltet auf der CCU, aber die Authentifizierung noch aktiviert.
Stimmt, die Authentifizierung war noch aktiviert
(auf beiden CCUs!).
Deaktivieren hat aber leider den RPC-Servcer-Status nicht verändert.
In der Logdatei stehen nach Neustart neue Einträge:
Zitat
http://192.168.178.46:9292/groups
2021.12.29 15:23:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] CB2001178052178046 NewDevice received 64 device and channel specifications
2021.12.29 15:23:05 2: HMCCURPCPROC [d_rpc178046HmIP_RF] CB2010178052178046 NewDevice received 178 device and channel specifications
2021.12.29 15:23:14 1: HMCCURPCPROC [d_rpc178046VirtualDevices] RPC server CB9292178052178046 running
2021.12.29 15:23:14 1: HMCCU [d_ccu] All RPC servers running
2021.12.29 15:23:14 2: HMCCU [d_ccu] Found no devices to update
2021.12.29 15:23:14 2: HMCCU [d_ccu] RPC device for interface BidCos-RF: d_rpc178046BidCos_RF
2021.12.29 15:23:14 2: HMCCU [d_ccu] RPC device for interface HmIP-RF: d_rpc178046HmIP_RF
2021.12.29 15:23:14 2: HMCCU [d_ccu] RPC device for interface VirtualDevices: d_rpc178046VirtualDevices
2021.12.29 15:23:14 1: HMCCU [d_ccu] RPC server already running
2021.12.29 15:23:14 1: HMCCU [d_ccu] All RPC servers error
2021.12.29 15:23:14 1: HMCCU [d_ccu] HMCCU: d_ccu Start of RPC server failed
2021.12.29 15:33:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] Received no events from interface CB2001178052178046 for 600 seconds
2021.12.29 15:43:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] Received no events from interface CB2001178052178046 for 600 seconds
2021.12.29 15:53:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] Received no events from interface CB2001178052178046 for 600 seconds
2021.12.29 16:03:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] Received no events from interface CB2001178052178046 for 600 seconds
2021.12.29 16:13:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] Received no events from interface CB2001178052178046 for 600 seconds
2021.12.29 16:23:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] Received no events from interface CB2001178052178046 for 600 seconds
2021.12.29 16:33:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] Received no events from interface CB2001178052178046 for 600 seconds
2021.12.29 16:43:04 2: HMCCURPCPROC [d_rpc178046BidCos_RF] Received no events from interface CB2001178052178046 for 600 seconds
Hi,
ich denke eventuell reden wir bez. der Authentifizierung aneinander vorbei.
Kannst Du bitte bei der CCU3 (gern auch bei beiden) prüfen:
Einstellungen / Systemsteuerung / Sicherheit / Authentifizierung - ist dort ein Haken bei Authentifizierung aktiv ? Siehe auch Bild im Anhang
bei meinem Raspberrymatic (piVCCU) ist dort per default kein Haken!
Wenn meine Vermutung stimmt - welche Anmeldung meintest Du?
Gruß Otto
Danke, dass Du nochmal nachfragst:
der Punkt ist wirklich interessant.
Ich habe genau dort:
Einstellungen / Systemsteuerung / Sicherheit / Authentifizierung
die Haken entfernt (nach der Frage dazu von zap).
Und tatsächlich sind die Haken, wenn ich die Seite erneut aufrufe, weg.
Allerdings verlangen beiden CCUs TROTZDEM, dass ich mich
einlogge, wenn ich einfach die IP im Browser aufrufe.
Nur eine Erklärung, warum eine CCU mit fhem arbeitet, und die andere nicht,
ist es eigentlich noch nicht, weil beide CCUs weiterhin ein Login verlangen.
Der Haken bei der Authentifizierung bezieht sich nur auf die API (steht auch so in der Erklärung dahinter).
Die Anmeldung an der CCU Webseite benötigt weiterhin Benutzername / Passwort.
Die Reihenfolge der Meldungen beim Starten der RPC Server ist irgendwie seltsam. Warte mal auf das nächste Update. Da habe ich die Meldungen etwas eindeutiger gestaltet.
Kommt in den nächsten Tagen.
O.k., warte ich gern ab. Danke auch schonmal für die vielen hilfreichen Tipps.
Ich hätte noch eine Frage, fasse aber vielleicht mal kurz zusammen, was sich
bisher ergeben hat:
-> mit dem RaspberryPi plus RFUSB-Stick plus piVCCU lässt sich ein reines HomematicIP-System betreiben
und über fhem damit komfortable Skripte aufrufen.
-> das Ziel, die CCU3-ZEntrale von Homematic einzubinden (um auch alte Homematic-Funk-Komponennten einzubinden),
wurde bisher noch nicht erreicht, weil der RPC server der Zentrale noch irgendein Problem hat.
Vielleicht kann das noch geläst werden.
Meine Frage:
es gibt ja noch eine dritte Hardware-Option, den HM-MOD-RPI-PCB.
Wenn der sich dem RaspberryPi ähnlich verhält wie der RFUSB, dann könnte ich statt
dem Stick auf dem Raspberry die HM-MOD-RPI-PCB verbauen und meine alten Komponenten
dann auch einbinden.
Wäre das vielleicht die einfachste und stabilste Lösung?
Moin,
ich wollte das vor allem mal im Detail aufschreiben, weil ich denke, dass es dem Einsteiger (wie mir) nicht 100% klar ist wenn man einfach den Begriff nennt.
Ich habe keine Stelle gefunden das Login an der Weboberfläche abzuschalten. Man kann eine automatische Anmeldung konfigurieren ... (noch nicht probiert)
Mir ist auch nicht klar, ob man einen Benutzer extra für die API definieren kann. Die Benutzerverwaltung kennt Admin Benutzer und Gast, wer kann was?
Das WebUI Handbuch sagt:
ZitatEintrag ,,Berechtigungsstufe"
• Wählen Sie zwischen den verschiedenen Berechtigungsstufen:
◦ Administrator Das Benutzerkonto erhält vollständige Konfigurations- und Bedienrechte.
◦ Benutzer Das Benutzerkonto erhält vollständige Bedienrechte, aber nur eingeschränkte
Konfigurationsrechte.
◦ Gast Das Benutzerkonto erhält nur Bedienrechte auf für entsprechend zugeordnete
Favoritenseiten.
Sehr weich beschrieben. Hab noch nicht mit diesen Berechtigungstufen experimentiert.
Na mal schauen was das mit der "original eq3 Hardware CCU3" noch wird. Hat die hier sonst keiner mit HMCCU am arbeiten?
Zitates gibt ja noch eine dritte Hardware-Option, den HM-MOD-RPI-PCB.
Wenn der sich dem RaspberryPi ähnlich verhält wie der RFUSB, dann könnte ich statt
dem Stick auf dem Raspberry die HM-MOD-RPI-PCB verbauen und meine alten Komponenten
dann auch einbinden.
Das funktioniert so, habe ich die letzten Tage für einen Kumpel in Betrieb genommen. HM classic und HM IP angelernt :)
Die CCU als Raspberrymatic im Docker Container.
Gruß Otto
ZitatDas funktioniert so, habe ich die letzten Tage für einen Kumpel in Betrieb genommen. HM classic und HM IP angelernt
Ah. super! Ich werde das also probieren.
Es ist ja ohnehin ein Vorteil, wenn ich nicht zwei Geräte (Raspberry und separate CCU3-Zentrale)
betreiben und mit Strom versorgen muss.
Wobei FHEM und CCU3 auf einem kleinen Pi ... das wäre mir dann persönlich zu unsicher. Würde es lieber trennen .....
@Otto123
Ich habe 2 CCUs im Einsatz:
1x original EQ3 CCU3
1x Charly Bausatz von ELV
Beide sind Hardware technisch identisch, beide sind nichts anderes als ein RaspPi. Auf der 1. CCU habe ich die original Firmware, auf der 2. Rasperrymatic. Ist aber beliebig austauschbar. FHEM mit draufpacken wird schwierig, da das Linux darunter root Builds sind. Man muss also erstmal Perl from Scratch neu übersetzen und kommt dabei vermutlich in die Dependency Hölle.
Ich würde zumindest auf einem Raspi schon aus Performance Gründen FHEM und CCU trennen (2 Geräte). Ich habe mein FHEM gerade auf einen Intel Miniserver mit AMD Ryzen CPU und 32 GB RAM umgezogen. Kein Vegleich zu vorher, das rennt!
Auf der Maschine laufen noch ioBroker, MySQL, Grafana, Apache und Mosquitto. Die Kiste langweilt sich immer noch.
Ok habe es als offenes Bild gesehen. Danke für die Info
Ich habe jetzt mittlerweile eine HM-MOD-PRI-PCB.
Und habe auch eine Anleitung für die Installation der Karte mit fhem gefunden:
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Es ist zwar fast ein eigenes Thema wert, aber bevor ich mit
der Instalaltion anfange, frage ich es lieber gleich nochmal hier (es passt
ja schon zur CCU und dem Skript-Thema):
wenn ich die Karte direkt in fhem integrieren kann,
brauche ich dann überhaupt die piVCCU bzw. CCU3?
Oder hat sich das Thema CCU dann schon erlledigt und ich könnte meine
Homematic- und HomematicIP-Geräte dann auch direkt in fhem anlernen?
O.k., hier steht es schon:
Zitat
Mit dieser Platine in Verbindung mit dem FHEM-Modul HMUARTLGW ist nur der Betrieb von BidCoS-Geräten möglich. Zur Einbindung von Geräten, die HM-IP verwenden, ist derzeit (Stand Juni 2018) noch zwingend eine (ggf. virtualisierte) CCU2 oder neuer erforderlich.
Frohes neues Jahr!
Hier zum Jahresstart der aktualisierte fhem-CCU-Status in Kurzform:
Zitat
RPCState running
STATE running/OK
:)
Hier die einzelnen Schritte:
1. neues RaspberryPI-System aufgesetzt:
(https://www.raspberrypi.com/news/raspberry-pi-os-debian-bullseye/)
2. darauf piVCCU installiert:
(https://github.com/alexreinert/piVCCU/)
3. Ausprobiert ob das Anlernen von Geräten klappt
(die IP-Adresse der CCU-Oberfläche mit dem Befehl sudo pivccu-info ermittelt)
4. Netzwerkeinstellungen in der CCU3-Oberfläche vorgenommen
4. fhem installiert
https://fhem.de/#Documentation
5. update in fhem durchlassen lassen (das war wichtig, vorher hat der
Befehl "set d_ccu on" wieder rpc-Server-Fehler gegeben !)
6. dann HMCCU in fhem installiert:
https://wiki.fhem.de/wiki/HMCCU
So, jetzt kann ich die Geräte anlernen und Skripte aufrufen.
Vielen Dank für die vielen Antworten und infos!