Homematic und Homematic IP am Raspberry

[MCh76]

vielen Dank euch beiden! Die Aussage von Alex ist natürlich überzeugend... pivccu ist nun direkt installiert.

nach der fehlerfreien installation und einem an sich positiven resultat in der pivccu-info war noch folgendes nötig:

damit sich docker umgebung und pivccu container auf einem gemeinsamen host vertragen musste ich noch im host:

Code Auswählen Erweitern

sudo nano /etc/piVCCU3/lxc.config ausrufen und dann den parameter

Code Auswählen Erweitern

lxc.network.link = br0 setzen

anschließend reboot und noch im host:

Code Auswählen Erweitern


sudo iptables -F FORWARD
sudo iptables -P FORWARD ACCEPT


das hatte meine recherche in diversen homematic foren ergeben (Alex war auch hier mal wieder die Schlüsselfigur).
die iptables befehle müssen wohl nach jedem neustart erneut durchgeführt werden, hier bietet sich wohl ein automatisches skript an..?

[Wernieman]

Natürlich .. die Frage ist nur, wo genau ...

Hast Du eine Firewall lauen?

[MCh76]

Natürlich .. die Frage ist nur, wo genau ...

Hast Du eine Firewall lauen?

nein keine firewall

[Wernieman]

Dann verstehe ich die Notwendigkeit Deiner iptables Befehle nicht .... (Vor allem das -F)

Auch kein UFW oder Ähnliches?

[deimos]

Hi,

das ist irgendein Quark von Docker, die hauen da diverse iptables Befehle raus, aber achten nicht drauf, dass die nur ihre eigene Bridge betreffen sollten.

Viele Grüße
Alex

[Wernieman]

Stimmt auch wieder .... hast Du Dich schon mal  mit Alternativen Docker-Software beschäftigt?

[deimos]

Hi,

ich glaube, du verwechselst hier grade die Personen in der Diskussion. Ich persönlich halte von Docker auf produktiven Systemen nicht viel, da kann ich für mich zu wenig Vorteile entdecken und setze da lieber auf andere Systeme, welche auf dem Blickwinkel Operations optimiert sind. Ich sehe Docker nur als interessante Technik während der Entwicklung an.

Viele Grüße
Alex

[Wernieman]

Beruflich: Docker aus der Entwicklung auch produktiv zu nutzen, also die GLEICHEN Container, setzt sich mittlerweile durch. Sehe da aktuell den großen Vorteil ....
Privat: Da sehe ich "aktuell" noch wenig Vorteile ...

[MCh76]

also ich habe jetzt folgenden positives ergebnis für meinen umzug von FHEM auf Docker und das Zusammenspiel mit piVCCU erzielen können. evtl. hilft es ja jemand.

- in der /etc/rc.local folgende Zeilen ergänzt damit die pivccu CCU3 im "normalen" heimnetz erreichbar ist (gleicher Adressbereich wie bspw. FHEM)
iptables -F FORWARD
iptables -P FORWARD ACCEPT

- im HMCCU device das attribut rpcserveraddr auf die IP Adresse von FHEM gesetzt (für den Callback der CCU)

- bei der Definition der HMCCU den parameter delayedinit=180 gesetzt --> ansonsten konnten die RPC server zum Zeitpunkt des Starts von FHEM nicht gestartet werden, da wohl die CCU noch nicht komplett bereit war. die harte verzögerung ist zwar nicht optimal, kann ich aber verschmerzen.



 

[NoKi]

[gelöst] => siehe https://forum.fhem.de/index.php?topic=77047.135
Hallo,
leider muss ich nochmal um Hilfe bitten. Mir gelingt es nicht, 2 Funkmodule HM-MOD-RF-PCB parallel an einem Raspi zu nutzen (eines an GPIO, ein anderes über USB). Ich habe auch nirgends einen Hinweis gefunden, dass das nicht möglich sein sollte.
Ziel:
Ich möchte HM und HM-IP-Geräte in einer gemeinsamen Instanz fhem nutzen. Dabei möchte ich

• Die HM-IP-Komponenten über ein Funkmodul HM-MOD-RF-PCB an der HB-RF-USB-2 mit debmatic - HMCCU - fhem betreiben (vielleicht später auch zusätzliche HM-Geräte).
• Die bisher verwendeten HM-Komponenten über ein zweites Funkmodul HM-MOD-RF-PCB an GPIO mit HMUART direkt in fhem betreiben.
  (Hintergrund ist, dass das existierende HM-fhem sehr umfangreich ist, und ich nicht alles Existierende neu in HMCCU anlernen und die Logiken anpassen möchte.)

Bisher funktionieren:

• Das alte HM-fhem System auf Raspi-3B (bullseye) mit HM-MOD-RF-PCB (Firmware 1.4.1) an GPIO (nur HM-Komponenten).
• Ein neues Testsystem auf Raspi-3B (bullseye) mit HM-MOD-RF-PCB (Firmware 2.8.6) an HB-RF-USB-2 mit debmatic - HMCCU - fhem. Sowohl HmIP-Komponenten als auch HM-Komponenten funktionieren in fhem über die HMCCU.

Problem / Frage:
Wenn ich an dem Testsystem jetzt parallel zum HM-MOD-RF-PCB an HB-RF-USB-2 zusätzlich das zweite HM-MOD-RF-PCB an GPIO anschließe, schaffe ich es nicht, das für HMUART in fhem verfügbar zu machen.
Wenn ich den Raspi mit dem zusätzlich auf GPIO gesteckten zweiten Modul starte, wird dieses anscheinend von debmatic verwendet (statt des anderen, auch bisher schon am USB angeschlossenen).
(Außerdem wird dabei die Firmware noch aktualisiert auf die 2.8.6; die musste ich danach für den Einsatz im alten HM-System wieder zurückflashen auf 1.4.1).
Weder funktionieren in dieser Konfiguration die Komponenten in debmatic-CCU, noch HMCCU oder HMUART in fhem. HMUART ist "disconnected", bei HMCCU sind alle rpcInterfaces entfernt.
Wenn ich danach das Funkmodul von GPIO wieder entferne und neu starte funktionieren die Komponenten über HMCCU wieder, die HMUART bleibt "disconnected".
Wie kann ich das System so konfigurieren, dass debmatic (nur) auf das HM-MOD-RF-PCB an der HB-RF-USB-2 zugreift, und HMUART (nur) auf das HM-MOD-RF-PCB an GPIO (oder umgekehrt)?

Ich wäre für jeden Hinweis sehr dankbar.
Viele Grüße  Norbert

Details:
Folgend einige Details, von denen ich hoffe, dass sie helfen können. (Ich kenne mich leider mit den Konfigurationen nicht wirklich aus.)

Beim Starten mit nur dem einem HM-MOD-RF-PCB an der HB-RF-USB-2:
debmatic-info:

Code Auswählen Erweitern

debmatic version: 3.71.12-109
OS:               Raspbian GNU/Linux 11 (bullseye)
Kernel:           6.1.21-v7+ armv7l
Service Status:   Running
Kernel modules:   Available
Raw UART dev:     Available
Rasp.Pi UART:     Assigned to GPIO pins
HMRF Hardware:    HM-MOD-RPI-PCB
 Connected via:   HB-RF-USB-2@usb-3f980000.usb-1.5 (/dev/raw-uart)
 Board serial:    NEQ1331734
 Radio MAC:       0x4F61DD
HMIP Hardware:    HM-MOD-RPI-PCB
 Connected via:   HB-RF-USB-2@usb-3f980000.usb-1.5 (/dev/raw-uart)
 SGTIN:           3014F711A061A7D5699DBA16
 Radio MAC:       0xB172BEdmesg (nur mit einem Funkmodul an USB):
=> siehe Datei 2023-1210-1610_demsg_response_nur-USB.txt 

Wenn ich mit beiden Funkmodulen starte:
debmatic-info:

Code Auswählen Erweitern

debmatic version: 3.71.12-109
OS:               Raspbian GNU/Linux 11 (bullseye)
Kernel:           6.1.21-v7+ armv7l
Service Status:   Running
Kernel modules:   Available
Raw UART dev:     Available
Rasp.Pi UART:     Assigned to GPIO pins
HMRF Hardware:    HM-MOD-RPI-PCB
 Connected via:   GPIO@3f201000.serial (/dev/raw-uart)
 Board serial:    SEQ1773304
 Radio MAC:       0x752017
HMIP Hardware:    HM-MOD-RPI-PCB
 Connected via:   GPIO@3f201000.serial (/dev/raw-uart)
 SGTIN:           n/a
 Radio MAC:       0x000000dmesg (mit beiden Funkmodulen):
=> siehe Datei 2023-1210-1530_demsg_response_USB-und-GPIO.txt

Weitere Details (sind in beiden Fällen gleich):

detect_radio_module --debug /dev/raw-uart

Code Auswählen Erweitern

/dev/raw-uart could not be openedls -l /dev/ttyAMA0

Code Auswählen Erweitern

ls: Zugriff auf '/dev/ttyAMA0' nicht möglich: Datei oder Verzeichnis nicht gefundenls -l /dev/serial*

Code Auswählen Erweitern

lrwxrwxrwx 1 root root 5 10. Dez 15:30 /dev/serial1 -> ttyS0


[deimos]

Hi,

du darfst das Paket pivccu-modules-raspberrypi nicht installieren, sondern nur das Paket pivccu-modules-dkms. Damit wird das Device Tree Overlay für den GPIO Port nicht installiert und der raw-uart Treiber nur für die HB-RF-USB-2 geladen. Und debmatic nutzt das Funkmodul nur, wenn es per raw-uart erreichbar ist.

Viele Grüße
Alex

[NoKi]

Vielen Dank Alex,
ich hatte das nach dieser Anleitung gemacht => https://github.com/alexreinert/debmatic/blob/master/docs/setup/raspberrypi.md.
Für die Punkte 4 - 6 steht "... kann übersprungen werden, falls kein Funkmodul direkt auf die GPIO Leiste aufgesteckt wird." Wenn ich das jetzt richtig verstehe bedeutet das, diese Punkte dürfen nicht durchgeführt werden, wenn die GPIO-Ports von debmatic nicht verwendet werden sollen. Das heißt alle 3 Punkte muss ich bei der Installation weglassen, dann kann HMUART in fhem auf das auf dem GPIO steckende zweite Funkmodul wieder zugreifen, korrekt?
Ich werde das probieren.
Vielen Dank und viele Grüße
Norbert

[deimos]

Hi,

jein, Schritt 4 darfst du nicht durchführen, Schritt 5 wirst du aber ggf. brauchen.

Viele Grüße
Alex

[NoKi]

Danke Alex,
ich bin jetzt einen Schritt weiter: Schritt 5 hatte ich in der Tat schon von der reinen fhem-Installation so eingestellt.
Wenn ich dann ohne Schritt 4 (und auch ohne Schritt 6) das zweite Funkmodul auf GPIO setze, kann ich mit define HMUARTLGW /dev/ttyAMA0 das Funkmodul in fhem zum Leben erwecken, parallel zu dem über HMCCU!
Merkwürdigerweise kann ich auch ein HM-Device daran anlernen, kann es aber nicht bedienen (MISSING ACKNOWLEDGE).
Hier muss ich weiter forschen. Für jeden Tip bin ich natürlich weiterhin dankbar.

Viele Grüße    Norbert

[deimos]

Hi,

da fällt mir das Stichwort verschlüsselte Übertragung und fehlender/falscher AES Key ein.

Viele Grüße
Alex