UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[fastfoot]

@uwe72 said in ioBroker in docker mit MACVLAN:

@dslraser meine IP-Adresse fangen ja alle normalerweise mit 192.168.178.XXX an.

Die vergebene ist 192.168.0.101. Die wird definitiv nicht anderweitig verwendet. vermutlich habe ich da beim Netzwerk auch falsche Sachen eingegeben. Mein Problem ist, ich kenne mich bei Netzwerksachen nicht so aus :-(

   ipam:
      config:
        - subnet: 192.168.0.0/24
          gateway: 192.168.0.1
          ip_range: 192.168.0.101/32
          aux_addresses:
            net-address: 192.168.0.101

dann sollte subnet: 192.168.178.0/24
gateway: 192.168.178.1
ip_range: 192.168.178.101/32
net-address: 192.168.178.101
passen. aux_addresses und net-address brauchst du (glaube ich) nicht, lass es aber drin

[uwe72]

@dslraser @fastfoot Danke Euch!

ioBroker funktioniert nun auf alle Fälle. Richtig klasse, nun auch wieder mit Shelly/Coap und Alexa2 Adapter.

Freue mich riesig :-)

[uwe72]

@dslraser @fastfoot

version: '2.1'

services:
  iobroker:
    restart: always
    image: buanet/iobroker:latest
    container_name: iobroker
    hostname: iobroker
    ports:
      - "8081:8081"
    volumes:
      - ./my-datas/iobroker/iobrokerdata:/opt/iobroker
    networks:
      public:
        ipv4_address: 192.168.178.210

networks:
  public:
    driver: macvlan
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: 192.168.178.0/24
          gateway: 192.168.178.1
          ip_range: 192.168.178.210/32

Das ist nun mein letzter Stand. Wie gesagt ioBroker funktioniert.

Bin nun schon beim nächsten Usecase :-)
Was nun komisch ist, wenn ich wenn ich von NUC aus einen ping auf die IP des iobrokers mache, also oben:

ping 192.168.178.210

dann bekomme ich keine Antwort. Bei allen anderen besetzten IP Adressen funktioniert der Ping.

Hat mir hier jemand noch einen Hinweis dazu? ;-)

Wie gesagt andere IP, z.B. von einem Shelly funktioniert:

[uwe72]

@uwe72 scheint wohl nicht so out-of-the-box zu gehen, dass der Host mit einem Container kommuniziert:

https://blog.wyraz.de/allgemein/docker-container-mit-eigener-statischer-lan-ip-ausfuehren/

[dslraser]

@uwe72 said in ioBroker in docker mit MACVLAN:

@uwe72 scheint wohl nicht so out-of-the-box zu gehen, dass der Host mit einem Container kommuniziert:

https://blog.wyraz.de/allgemein/docker-container-mit-eigener-statischer-lan-ip-ausfuehren/

Aber interessante Infos auf der Seite.

[dslraser]

@uwe72
Ich habe das "Problem" bisher nicht, da meine Syno (wo bei mir ioBroker läuft) zwei Netzwerkanschlüsse hat.

[fastfoot]

@uwe72 said in ioBroker in docker mit MACVLAN:

@uwe72 scheint wohl nicht so out-of-the-box zu gehen, dass der Host mit einem Container kommuniziert:

dabei kann ich dir nicht behilflich sein, da reichen meine Netzwerkkenntnisse nicht aus. Ich nutze eine QNAP, welche macvlan-ähnliche qnet Treiber nutzt, da besteht dieses Problem nicht. Müsste ich mal testen bei Gelegenheit. Ein Problem dabei ist, wenn ich mir die Konfig meiner Netzwerkkarte zerschiesse, dann ist es eine mehr oder weniger aufwändige Prozedur, dies zu resetten, damit ich die NAS überhaupt wieder erreichen kann. Interessant ist es aber allemal

[fastfoot]

@dslraser said in ioBroker in docker mit MACVLAN:

@uwe72
Ich habe das "Problem" bisher nicht, da meine Syno (wo bei mir ioBroker läuft) zwei Netzwerkanschlüsse hat.

Interessant, evtl. ist es dann gar nicht der QNET Treiber auf meiner QNAP, sondern auch die Tatsache dass ich auch zwei NIC habe. Sollte aber nicht mehr relevant sein wenn man sie abstöpselt(!?).

Netzwerken ist auch so ein unendlich weites Thema, war letztens auf einer Seite da habe ich seit Langem mal wieder nur Bahnhof verstanden :grinning:

[uwe72]

@fastfoot @dslraser danke euch beiden dennoch!

[Holzlenkrad]

@uwe72 said in ioBroker in docker mit MACVLAN:

@uwe72 scheint wohl nicht so out-of-the-box zu gehen, dass der Host mit einem Container kommuniziert:

https://blog.wyraz.de/allgemein/docker-container-mit-eigener-statischer-lan-ip-ausfuehren/

Wenn der Host wirklich mit dem Container kommunizieren muss, dann könnte man z.B. dem Container als zweites Interface das ganz normale Docker-Bridge-Interface hinzufügen.

[AutomationNico]

@uwe72 Ich weis, ist schon ein wenig älter die Diskussion, aber ich wollte mal fragen, ob du in deiner Konstellation die VIS mit Online Community Lizenz nutzt. Da hab ich Probleme. Siehe hier: https://forum.iobroker.net/topic/55616/vis-keine-gültige-lizenz-gefunden/10

Gruß Nico

[uwe72]

@automationnico Hi Nico, da kann ich dir leider nichts dazu sagen bzw. dir weiterhelfen. Kann mich an das Thema nicht mehr wirklich erinnern. Da ging es um VIS oder Jarvis. Wir sind zudem hier im MACVLAN Thread? Viele Grüße!

[squier23]

@uwe72 hast du beim Subnet einfach nur die IP-Adresse des Hosts eingegeben? und bei "IP-Adresse" dann aber die Wunsch-IP-Adresse gelassen?

Bei mir hat das alles funktioniert, bis ich den Host (Synology NAS) neu starten musste. Ich komm zwar auf den ioBroker, aber die Shellys können nicht mit ihm kommunizieren...

[uwe72]

@squier23 ich bin beim Thema nicht mehr drin, aber es funktioniert alles :-)

D.h. nutze docker-compose und im iobroker werden auch die shellys erkannt (coap und mittlerweile mit mqtt).

Wie kann ich dir helfen?

OK, einfach mal ins Blaue...

  iobroker:
    restart: always
    image: buanet/iobroker:latest
    container_name: iobroker
    hostname: iobroker
    network_mode: "host"
    volumes:
      - ./my-datas/iobroker/iobrokerdata:/opt/iobroker
      - ./my-datas/nginx:/home/uwe72/export4nginx

[drapo]

@uwe72 so wie das jetzt aussieht läuft dein system nicht mehr auf MACVLAN sondern im Host mode ist das korrekt? Warum bist du weg vom MACVLAN gab es da Probleme?