Ich habe über die Feiertage Zeit gehabt und eine Lösung gefunden: Voraussetzungen: QNAP 251+ mit 16GB Ram, QTS v4.4.1.1146, Docker v17.09.1, Adapter 1 mit DHCP an FritzBox, Adapter 2 mit fixer IP am Intranet Zunächst alle Reste der vorherigen Versuche entfernen, also in der ContainerStation die Container stoppen, löschen und die Images entfernen. Zur Sicherheit noch in der Kommandozeile „docker system prune“ ausführen, das entfernt alle inaktiven Container und Netzwerke. Mit der FileStation die angelegten Verzeichnisse löschen. Jetzt müsste alles blank sein. Ich benutze gerne die Kommandozeile, um Docker Kommandos auszuführen. Das ist für mich übersichtlicher beim Probieren/Dokumentieren. Trotzdem installiere ich auch immer den Portainer, weil man da bequem alles anschauen kann, ähnlich wie auch in der ContainerStation. Ich wollte den ioBroker über beide Netzwerke erreichen bzw. aus beiden Informationen lesen. Da dies mit dem Aufruf „--network host“, im Gegensatz zum Portainer s.u., nicht klappt (ioBroker wird nicht richtig installiert, warum auch immer), habe ich einen anderen Weg gefunden. Ich lege zunächst im Docker 2 Netzwerke an, dazu benutze ich den QNAP Treiber qnet, siehe: https://qnap-dev.github.io/container-station-api/qnet.html# Netzwerke anlegen: docker network create -d qnet --ipam-driver=qnet --ipam-opt=iface=eth0 dhcp-fritzbox Erzeugt ein Netzwerk Typ qnet mit dem QNAP Treiber qnet und dem Namen dhcp-fritzbox (am QNAP Adapter1 = FritzBox). Dadurch wird in der QNAP automatisch auch ein virtueller Switch erzeugt. docker network create -d qnet --ipam-driver=qnet --ipam-opt=iface=eth1 --subnet=192.168.1.0/24 --gateway=192.168.1.1 static-intranet Erzeugt ein Netzwerk Typ qnet mit dem QNAP Treiber qnet und dem Namen static-intranet (am QNAP Adapter2 = Intranet) Option -d steht hier nicht wie beim run Befehl für detach sondern für --driver, also hier der qnet Treiber (alternativ z.B. auch bridge, macvlan u.a.). Option --ipam-driver weist den IP adress manager zu, hier auch vom qnet. Option --ipam-opt weist spezielle Treiber Parameter zu, hier soll das Interface eth0 benutzt werden (entspricht dem QNAP Adapter1, der ja auf DHCP steht). Option --subnet weist die Subnet-Maske zu 192.168.1.0/24 bedeutet IP Range von 192.168.1.1 bis 192.168.1.254, Maske 255.255.255.0 Option--gateway weist das Gateway zu Am Ende steht der Name des Netzwerks In der QNAP Systemsteuerung, Netzwerk- und virtueller Switch, Übersicht sieht das dann so aus (Namen der virtuellen Switche angepasst, WAN-IP entfernt): [image: 1577969141676-2fb07b24-fb2d-49e0-a18f-7a1912acdc9e-image.png] Im Portainer später dann so (Ownership ist mir noch unklar): [image: 1577969177707-b5b8949c-8ceb-4dc6-b106-1b1467126cde-image.png] Portainer installieren: docker pull portainer/portainer (holt das Portainer Image vom DockerHub, ist aber nicht unbedingt nötig, der docker run würde es auch holen, wenn noch nicht lokal vorhanden) docker run -d -p 9999:9000 --name portainer --network host -v /var/run/docker.sock:/var/run/docker.sock -v /share/Container/Docker/portainer_data:/data portainer/portainer Obwohl der Port 9999 benutzt werden soll, ist der Portainer nur unter Port 9000 ereichbar (liegt ev. am network host ?), kann aber wegen network host sowohl über http://192.168.178.151:9000 wie auch http://192.168.1.151:9000 aufgerufen werden. ioBroker installieren: docker pull buanet/iobroker docker run -d --name ioBroker --network dhcp-fritzbox --restart always -e TZ="Europe/Berlin" -p 8081:8081 -p 8082:8082 -p 8083:8083 -p 8084:8084 -v /share/Container/Docker/ioBroker:/opt/iobroker -v /share/Container/Docker/ioBroker_transfer:/opt/transfer -v /share/Container/Backup/Docker/ioBroker:/opt/iobroker/backups buanet/iobroker Container stoppen, das zweite Netzwerk anhängen mit einer IP, den ioBroker Container neu starten. docker network connect --ip 192.168.1.152 static-intranet ioBroker Man könnte wohl auch den Container erst mit create anlegen und später starten (docker start -d ioBroker) docker create --name ioBroker --network dhcp-fritzbox --restart always -e TZ="Europe/Berlin" -p 8081:8081 -p 8082:8082 -p 8083:8083 -p 8084:8084 -v /share/Container/Docker/ioBroker:/opt/iobroker -v /share/Container/Docker/ioBroker_transfer:/opt/transfer -v /share/Container/Backup/Docker/ioBroker:/opt/iobroker/backups buanet/iobroker In der QNAP Systemsteuerung, Netzwerk- und virtueller Switch, Übersicht sieht das dann so aus (Namen der virtuellen Switche angepasst, WAN-IP entfernt): [image: 1577969371046-ab37b273-d247-4772-868a-950f62aae586-image.png] ioBroker kann jetzt sowohl mit dem FritzBox Subnet als auch mit dem Intranet Subnet kommunizieren. Das funktioniert soweit erst mal für mich und ich kann weiter probieren. Vielleicht habt Ihr ja trotzdem noch weitere Tipps. Und noch ein frohes, neues Jahr an alle!

Hallo Kann mir jemand mit dem Aeotec Energy Monitor Gen 5 helfen, eingebunden ist er aber er ändert seine Werte nicht. Hab auch die Config so wie am Bild mal eingetragen also sollte er alle 20sec die Werte ändern macht er aber nicht nur beim aufwecken mit der Taste hinten übermittelt das Gerät die Werte

@uwe72 https://forum.iobroker.net/post/160469

@DennisMenger wenn du den ZIgbee adapter nutzen willst brauchst du einen Stick in irgend einer Form. Wenn du die Lampen / FB am Echo oder am Ikea Gateway anlernen willst dann sollte das auch gehen. Wie gut die mit dem ioBroker direkt spielen weiss ich nicht. Ich nutze beides nicht. A.

ok Danke werde ich versuchen wenn die Lautsprecher da sind.

Ich war ebenfalls auf der Suche nach einer Lösung. Ich konnte die Ursache des Problems etwas eingrenzen. Zunächst scheint die Kommunikation mittels TLS zum Adapter bei mir zu funktionieren. Das hier ist in etwa die Kette an nodejs modulen, die involviert sind iobroker.mqtt -(erzeugt objekt)-> tls -(wird übergeben an)-> mqtt-connection -(nutzt für decodierung...)-> mqtt-packet Das modul mqtt-connection selber ist derived vom Paket duplexify und nutzt intern das node module mqtt-packet für die eigentliche mqtt Verarbeitung. Ab dem Modul "mqtt-connection" passiert allerdings nichts weiter mit der (erfolgreich aufgebauten) tls verbindung. Es werden keine Daten weiter gereicht. Für mich sieht es so aus, als wenn duplexify mit dem tls objekt nicht weiter Arbeiten kann. Nach knapp einen ganzen Tag des erfolglosen Debuggens habe ich die native Unterstützung von TLS über iobroker.mqtt aufgegeben. Stattdessen nutzt ich nun nginx als TLS proxy (basierend auf diesem Tutorial) Hier ist meine nginx config stream { log_format mqtt '$remote_addr [$time_local] $protocol $status $bytes_received ' '$bytes_sent $upstream_addr'; server { listen 8883 ssl; # MQTT secure port ssl_certificate /path/to/certificates/self.crt; ssl_certificate_key /path/to/certificates/self.key; ssl_ciphers HIGH:!aNULL:!MD5; #ssl_session_cache shared:SSL:128m; # 128MB ~= 500k sessions ssl_session_tickets on; ssl_session_timeout 8h; proxy_pass <ip zu iobroker, wo MQTT drauf läuft>:1883; proxy_connect_timeout 1s; access_log /var/log/nginx/mqtt_access.log mqtt; error_log /var/log/nginx/mqtt_error.log info; # nginScript debug logging } } Jetzt verbindet sich mein Tasmota Endgerät über MQTT+TLS verschlüsselt zu meinem iobroker.

@TobStar sagte in Probleme nach Umstellung auf Docker mit HM-RPC: Bin davon ausgegangen das er auf 8081 zurückfunkt So ungefähr dachte ich mir das

Hat soweit funktioniert. Hab die alte Installation vorher hoffentlich richtig deinstalliert. Scheint nun zu laufen, danke!

@joergfrde Da gibt es dann doch ein Remote wake Up!

Ja in VIS ist alles noch da, allerdings überall drehende Kreise. Leider habe ich mich nicht an die richtige Reihenfolge gehalten. Hatte erst den Master gemacht. Habe dann aber über die Beschreibungen die Slaves auch aktualisiert bekommen. Fixer gerade über alle Hosts laufen lassen. Problem ist beseitigt. Ganz herzlichen Dank

@f0rd42 sagte in Zigbee CC231 Reichweite / Kommunikationsprobleme: ABER: derzeit funktioniert es ja halbwegs mit dem Stick ohne externe Antenne. Der mit der externen (hatte zwei, eine 20dB Pigtail und eine Stabantenne mit entsprechendem Kabel) SOLLTE doch eigentlich besser gehen, oder? Das ist so pauschal leider NICHT richtig. Du hast zwar eine höhere Sende/Empfangsleistung, aber wenn die Probleme auf andere Ursachen zurück zu führen sind bringt das alleine nichts. Mehr ist halt nicht immer besser. Ansonsten: zigbee/wLan Kanäle Und: Stick am besten immer mit USB Verlängerung anschliessen. A. Nachtrag: Auch Menschen stören den Funk, alleine durch ihre Anwesenheit :)

an die sonoff darfst du keine 230V an die schalteingänge legen! die shellys sind dafür besser geeignet! hierfür sollte man wissen was du an welchem schalter was für drähte hast, ob vielleicht eine steckdose mit drunter sitzt und von welchem schalter aus es zur lampe geht

@Blechsoldat sagte in Anfänger : Fragen zur "debug output" funktion: Muss ich noch etwas konfigurieren ? Was steht denn in dem abgeschnittenen Teil des Blocks?

@Felsdrache sagte in lgtv - Bei TV EIN jedesmal Freigabeabfrage...: Frohes Neues zusammen. Hat sich in der Richtung was getan ich habe 2 LG Fernseher und bei nerven nach dem Einschalten mit der Verbindungsabfrage. Eine Lösung wäre toll. Nö, kommt immer wieder. Sehr nervig.

@Homoran sagte in Admin: Adapter-Tab lädt sich tot: @Nashra sagte in Admin: Adapter-Tab lädt sich tot: @Homoran könntest Du die Beiträge hierzu dorthin verschieben Wo, bitte, soll ich welche Beiträge hin verschieben? Erledigt, hatte ja einen neuen Thread zu dem Thema angelegt