Hauptmenü

Modul 96_SIP

Begonnen von Wzut, 19 Februar 2017, 19:10:09

Vorheriges Thema - Nächstes Thema

plin

Hast Du Docker mit NATing eingerichtet???

Schick doch mal ip addr und ip route von innerhalb des Containers und vom Host.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Homalix99

IP-addr (HOST):

root@RPI-Docker:/pi-hole-docker# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:ea:33:42 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.20/24 brd 192.168.3.255 scope global dynamic noprefixroute eth0
       valid_lft 812716sec preferred_lft 704716sec
    inet6 2003:f6:f722:e700:d9b3:4da:978:afa7/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6958sec preferred_lft 1071sec
    inet6 fe80::5638:6cc2:c7e8:aa26/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether dc:a6:32:ea:33:43 brd ff:ff:ff:ff:ff:ff
4: br-2e1cc9ea428a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:72:03:ad:f4 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-2e1cc9ea428a
       valid_lft forever preferred_lft forever
    inet6 fe80::42:72ff:fe03:adf4/64 scope link
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:e4:02:11:72 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
6: br-9f222dfd7a06: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:3c:0b:15:ae brd ff:ff:ff:ff:ff:ff
    inet 172.20.0.1/16 brd 172.20.255.255 scope global br-9f222dfd7a06
       valid_lft forever preferred_lft forever
    inet6 fe80::42:3cff:fe0b:15ae/64 scope link
       valid_lft forever preferred_lft forever
7: br-29f0a168d3f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:f2:22:19:c3 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-29f0a168d3f3
       valid_lft forever preferred_lft forever
    inet6 fe80::42:f2ff:fe22:19c3/64 scope link
       valid_lft forever preferred_lft forever
9: vethf03cefd@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
    link/ether 22:9b:c4:dc:b5:4c brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet 169.254.41.187/16 brd 169.254.255.255 scope global noprefixroute vethf03cefd
       valid_lft forever preferred_lft forever
    inet6 fe80::e36:c2fe:b1c4:bc62/64 scope link
       valid_lft forever preferred_lft forever
11: vethab0edfc@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-29f0a168d3f3 state UP group default
    link/ether 92:2a:15:c2:09:37 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet 169.254.195.163/16 brd 169.254.255.255 scope global noprefixroute vethab0edfc
       valid_lft forever preferred_lft forever
    inet6 fe80::af57:3915:267:41e5/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::902a:15ff:fec2:937/64 scope link
       valid_lft forever preferred_lft forever
13: vethb07b911@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-9f222dfd7a06 state UP group default
    link/ether e6:b6:cb:82:42:b8 brd ff:ff:ff:ff:ff:ff link-netnsid 4
    inet 169.254.224.252/16 brd 169.254.255.255 scope global noprefixroute vethb07b911
       valid_lft forever preferred_lft forever
    inet6 fe80::677a:ec8a:b960:97c2/64 scope link
       valid_lft forever preferred_lft forever
15: veth0a0617b@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-29f0a168d3f3 state UP group default
    link/ether 9a:a2:d2:6d:2a:bd brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.79.0/16 brd 169.254.255.255 scope global noprefixroute veth0a0617b
       valid_lft forever preferred_lft forever
    inet6 fe80::e8d6:7e76:1717:d8f2/64 scope link
       valid_lft forever preferred_lft forever
17: vetha5ea5e2@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
    link/ether 26:65:0f:aa:5c:ba brd ff:ff:ff:ff:ff:ff link-netnsid 6
    inet 169.254.3.36/16 brd 169.254.255.255 scope global noprefixroute vetha5ea5e2
       valid_lft forever preferred_lft forever
    inet6 fe80::82d4:8f4a:d2ed:2c99/64 scope link
       valid_lft forever preferred_lft forever
19: veth236be53@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-29f0a168d3f3 state UP group default
    link/ether 2e:b2:73:fa:04:f3 brd ff:ff:ff:ff:ff:ff link-netnsid 7
    inet 169.254.61.226/16 brd 169.254.255.255 scope global noprefixroute veth236be53
       valid_lft forever preferred_lft forever
    inet6 fe80::a714:fbeb:8a42:74c0/64 scope link
       valid_lft forever preferred_lft forever
21: veth33fff10@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
    link/ether 12:47:fb:e0:0d:67 brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet 169.254.188.213/16 brd 169.254.255.255 scope global noprefixroute veth33fff10
       valid_lft forever preferred_lft forever
    inet6 fe80::a131:55f4:1a6e:a9c1/64 scope link
       valid_lft forever preferred_lft forever
23: vethd1294b6@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-29f0a168d3f3 state UP group default
    link/ether ea:be:69:eb:9c:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet 169.254.125.134/16 brd 169.254.255.255 scope global noprefixroute vethd1294b6
       valid_lft forever preferred_lft forever
    inet6 fe80::c61e:daaa:1e35:a42/64 scope link
       valid_lft forever preferred_lft forever
27: veth8c35ddb@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
    link/ether 36:60:4f:cd:75:ba brd ff:ff:ff:ff:ff:ff link-netnsid 8
    inet 169.254.142.190/16 brd 169.254.255.255 scope global noprefixroute veth8c35ddb
       valid_lft forever preferred_lft forever
    inet6 fe80::5d71:39c6:949e:1de/64 scope link
       valid_lft forever preferred_lft forever
28: br-a3ed05ad371c: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:03:66:5b:7d brd ff:ff:ff:ff:ff:ff
    inet 172.21.0.1/16 brd 172.21.255.255 scope global br-a3ed05ad371c
       valid_lft forever preferred_lft forever
    inet6 fe80::42:3ff:fe66:5b7d/64 scope link
       valid_lft forever preferred_lft forever
40: veth9e0281d@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2e1cc9ea428a state UP group default
    link/ether 1e:32:99:70:fe:14 brd ff:ff:ff:ff:ff:ff link-netnsid 9
    inet 169.254.49.225/16 brd 169.254.255.255 scope global noprefixroute veth9e0281d
       valid_lft forever preferred_lft forever
    inet6 fe80::1c32:99ff:fe70:fe14/64 scope link
       valid_lft forever preferred_lft forever


ip route (HOST)

root@RPI-Docker:/fhem-docker# ip route
default via 192.168.3.1 dev eth0 proto dhcp src 192.168.3.20 metric 202
169.254.0.0/16 dev vethf03cefd scope link src 169.254.41.187 metric 209
169.254.0.0/16 dev vethab0edfc scope link src 169.254.195.163 metric 211
169.254.0.0/16 dev vethb07b911 scope link src 169.254.224.252 metric 213
169.254.0.0/16 dev veth0a0617b scope link src 169.254.79.0 metric 215
169.254.0.0/16 dev vetha5ea5e2 scope link src 169.254.3.36 metric 217
169.254.0.0/16 dev veth236be53 scope link src 169.254.61.226 metric 219
169.254.0.0/16 dev veth33fff10 scope link src 169.254.188.213 metric 221
169.254.0.0/16 dev vethd1294b6 scope link src 169.254.125.134 metric 223
169.254.0.0/16 dev veth8c35ddb scope link src 169.254.142.190 metric 227
169.254.0.0/16 dev veth9e0281d scope link src 169.254.49.225 metric 240
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-29f0a168d3f3 proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-2e1cc9ea428a proto kernel scope link src 172.19.0.1
172.20.0.0/16 dev br-9f222dfd7a06 proto kernel scope link src 172.20.0.1
172.21.0.0/16 dev br-a3ed05ad371c proto kernel scope link src 172.21.0.1 linkdown
192.168.3.0/24 dev eth0 proto dhcp scope link src 192.168.3.20 metric 202


Die ip cmds sind im Container nicht verfügbar.
Weißt Du wie ich das dazudefinieren kann?
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

Homalix99

IP addr (Fhem Container):

oot@FHEM-Docker:/opt/fhem# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
53: eth0@if54: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:13:00:05 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.19.0.5/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
root@FHEM-Docker:/opt/fhem#


ip route (fhem-Container):

root@FHEM-Docker:/opt/fhem# ip route
default via 172.19.0.1 dev eth0
172.19.0.0/16 dev eth0 proto kernel scope link src 172.19.0.5
root@FHEM-Docker:/opt/fhem#


- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

plin

#1248
Das sieht alles normal aus. Da Daten via RTP übertragen werden sollte die Sender-IP keinen großen Unterschied machen.

Im IP-Phone-Forum hat jemand mit Audio-Problemen die FritzBox neu durchgestartet ...
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Homalix99

Hallo Peter,

ich denke, dass die FB als SIP Server damit schon ein Problem hat.
Ich würde gerne erreichen wollen, dass die Sender-IP die des Containers ist, da die FB von einem Telefon (intern oder extern) mit dem MicroSIP ja tadellos ihren Dienst verrichtet
und die unterschiedlichen IP's ja erstmal der einzige Unterschied sind, warum es nicht funktionieren könnte.
Wie hast Du es geschafft, dass der Versuchsaufbau bei Dir die Sende-IP des Containers ist?
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

plin

Zitat von: Homalix99 am 10 März 2023, 13:32:05
Wie hast Du es geschafft, dass der Versuchsaufbau bei Dir die Sende-IP des Containers ist?

einfach cut&paste. Ich habe mein Test-FHEM mit dem Command-Beispiel aus dem Wiki angelegt
docker run -d -p 7072:7072 -p 8083:8083 -p 5060:5060 -p 5070:5070 -p 2000-2019:2000-2019 fhem/fhem
Dann nur noch die Utils.pm angepasst, SIP und TexttoSpeech installiert/konfiguriert und los ging's.

Ich habe auch kein Docker-Config-File gefunden in dem ich irgendwas vorgebe.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

Ich habe diesen Artikel hier zu Docker und Proxy gefunden: https://deavid.wordpress.com/2019/06/15/how-to-allow-docker-containers-to-see-the-source-ip-address/

Nutzt Du den Container fhem/fhem?
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Homalix99

Bei mir ist als image fhem/fhem:latest definiert.
Den Artikel habe ich gelesen, kann ich ja demnächst mal ausprobieren.
Ich habe auch noch einen Artikel
https://forum.fhem.de/index.php?topic=114284.0
entdeckt, die arbeiten mit Macvlan.
Damit habe ich ganz zu Beginn mal rumgespielt und nach jedem Docker Start plötzlich n x IP-Adressen in der FB sichtbar (n = Anzahl der Container)
Habs dann bleiben gelassen und brav den Standardweg mit bridge gewählt und bislang ja keinerlei Probleme gehabt.
Und auch gelesen, dass ein "Mischbetrieb" zwischen host und bridged Containern von d.-compose abgelehnt wird.
Werde bei Gelegenheit mal einen Freund kontraktieren, der sich mit Netzwerk  besser auskennt.
VG

Alex
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

plin

Mal schauen wann sich wzut einklinkt. Vielleicht hat der noch eine Idee.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Homalix99

Vielen, vielen Dank erstmal für Deine Unterstützung.
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)

plin

Irgendwie scheint es öfters Probleme mit RTP im Docker Container zu geben https://www.google.com/search?client=firefox-b-d&q=docker+rtp+no+audio

Hast Du die Möglichkeit auf einem freien Rechner einfach mal docker zu installieren (ohne Modifikation ) und dann FHEM mit SIP+TexttoSpeech einzurichten?
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

Wzut

#1256
Zitat von: plin am 11 März 2023, 10:05:40
Mal schauen wann sich wzut einklinkt.
Ich lese immer mit, aber beim Thema Docker habe ich bis heute nicht kapiert wozu man das überhaupt brauch bzw. warum sich Leute so etwas freiwillig antun ->
Zitat von: Homalix99 am 04 März 2023, 18:01:59
Das Modul hat, bevor ich fhem in einen Docker-Container umgezogen habe, einwandfrei funktioniert, inkl. Audio Übertragung.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

plin

FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

rob

Hallo.

Eine Lösung kann ich zwar nicht bieten, aber vielleicht hilft ein Vergleich auch weiter.
Ich hab das mir so ähnlich am Laufen: FHEM ruft mich an, wenn was anliegt. FHEM rennt in Docker. Alles supi. Um SIP kümmert sich bei mir zwar Asterisk, aber das sollte nicht den riesigen Unterschieden machen.

Wenn ich einen Testcontainer starte:
docker run -d -p 8089:8083 --name fhemtest fhem/fhem
und dann die tts + sip Devices anlege, kann ich bereits outbound anrufen lassen. Richtig, obwohl keine Ports 5060 usw. nach außen gemappt sind und es keine statische Route gibt. Im Attribut "sip_ip" steht auch nur, was mir
docker inspect fhemtest
unter "IPAddress" anzeigt --> 172.17.0.2. (In meinem produktiven FHEM läuft der Container in einem Docker-Netz mit Net-Alias, wodurch ich im Attribut "sip_ip" keine IP eintragen muss, sondern nur den alias (bei mir "myfhem"). Ist hier aber nebensächlich  :) )
Inbound calls sind freilich ein anderes Thema. Da reicht obiger Schmalspuraufruf nicht.

Im Post #1246 fällt auf, dass Du mehrere Bridges hast. Docker liegt mit docker0 im Adressbereich 172.17.0.1/16 mit linkdown, trotzdem wird bei Dir alles auf 172.19.0.5 gemünzt.
Im Vergleich bei Dir:

5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:e4:02:11:72 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown


und bei mir (Raspi und PC gleich):

7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:2e:0c:e2:e9 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1


Docker liegt doch eigentlich immer in 172.17.0.0/16. Schaut für mich so aus, als gäbe es einen Knoten in der Netzwerkkonfig. Macht hier ggf. die Bridge den Ärger? Hast Du die Möglichkeit auf einem PC/ Laptop Docker mit obigem Schmalspuraufruf zu starten, wo keine "Netzwerk-Besonderheiten" sind?
Wäre mal interessant, welchen Adressbereich Docker dort bekommt und ob von dort der Anruf klappt.

VG
rob

Homalix99

Hallo an alle!
Erstmal noch vielen Dank für die riesige Unterstützung.
Ich habe das Problem letzendlich gelöst, indem Docker vom Bridge-mode auf ipvlan umgestellt wurde. Jetzt hat fhem und alle weiteren Container eine ip-Adresse aus dem Fritzbox-Bereich (non DHCP-Bereich), damit sind Sende- und Empfangs-Adresse für die RTP-Pakete jetzt gleich und somit leitet die FB die RTP-Pakete richtig weiter.

VG

Alex
- RPI 4 fhem in Docker, 2 x Arduino Uno, HM-GW, HM-Dev. (Fensterkontakte, HK-Thermostate, div. Aktoren), JeeLink,
- GPIOs, HM-LAN, ESPs (MQTT2)
-Überwachung Fenster/Türen/Licht, HK-Thermostatregelung, Rollosteuerung, Überw. Betriebstemperaturen Heizung, Erfassung Gas/Wasser, PV-Anl., Wetter (WS1600)