Wenn du Docker (oder allgemein Linux-Container) verwendest, musst du Port-Mapping machen, damit die Ports von außerhalb des Container-Hosts erreichbar sind.
Beiträge von Hiegeix7
-
-
Besteht netzwerktechnisch ein Unterschied zwischen der alten und neuen Installation? Also könnte z.B. nun eine Firewall dazwischen liegen?
Kannst du vom IO-Broker aus die Shellys anpingen?Kann der IO-Broker den Port 80 der Shellys erreichen?
Können die Shellys aus ihrem Netz den CoIot-Port 5683 des IO-Brokers erreichen?
Zur Info: IO-Broker kenne ich nicht. Ich benutze Home-Assistant.
-
Shellys auch geresettet, hilft leider nicht.
Du meinst, ganz resettet auf Werkseinstellungen, und dann von Null aus angefangen?
Nach dem Reset, und der anschließenden Neukonfiguration der WLAN-Parameter steht die Shelly ja auf DHCP. Kann die Shelly sich dann erfolgreich einbinden, so dass du ihre IP-Adresse erreichst?
Im Unifi-Controller wird ja auch die IP-Adresse angezeigt. Ist das die erwartete? Kannst du die erreichen?
Verwende mal zum Erreichbarkeitstest das Kommando ping, anstatt den Browser. Nicht, dass der Browser-Cache einen Streich spielt.
-
Um dem Ganzen jetzt noch die Krone aufzusetzen habe ich soeben folgenden Test mit einer frischen Shelly Plug S durchgeführt. Als Router und DHCP-Server verwende ich OPNsense und für IOT das VLAN-Subnetz 10.27.200.0/24. WLAN wird von Unifi bereitgestellt:
- frische Shelly wie üblich mit DHCP ins WLAN gebracht: zufällige IP-Adresse: 10.27.200.19
- Home-Assistant meldet: Device gefunden, dort bin ich auf ignorieren gegangen
- in der Shelly-Oberfläche auf http://10.27.200.19 den Device-Name gesetzt auf Wohnzimmer/Ventilator1 (mit /), ansonsten nichts geändert
- im DHCP-Server eine reservierte IP-Adresse sowie einen Hostnamen für diese Shelly gesetzt: Wohnzimmer-Ventilator1 (mit -) 10.27.200.225
- Shelly rebootet und im Browser sowohl auf http://10.27.200.225 als auch auf http://Wohnzimmer-Ventilator1 die Erreichbarkeit verifiziert (die DNS-Auflösung macht mein DHCP-Server)
- in Home-Assistant aktiv die Shelly-Integration für den Hostnamen Wohnzimmer-Ventilator1 (nicht die IP-Adresse) erfolgreich eingerichtet. Dabei schlägt Home-Assistant auch gleich den übermittelten Device-Namen Wohnzimmer/Ventilator1 vor.
- im DHCP-Server die bisherige reservierte IP-Adresse 10.27.200.225 geändert auf 10.27.200.220
- Shelly rebootet und im Browser auf http://10.27.200.220 und http://Wohnzimmer-Ventilator1die Erreichbarkeit verifiziert. (dazu musste ich den Browser restarten, da der die alte IP-Adresse im Cache hatte)
- im Home-Assistant nichts weiter gemacht und die Shelly funktioniert dort trotzdem sofort noch problemlos!
Das heißt mit anderen Worten: Home-Assistant ist die IP-Adresse völlig egal. Das konkrete Device funktioniert mit jeder beliebigen IP-Adresse.
Sehen kann man das hier: In Home-Assistant auf „Device-Info“ für die Shelly gehen. Dort gibt es einen Link „visit Device“. Wenn man die Maus darüberhält, erscheint unten die Zieladresse. Führt man obige Test-Prozedur (reservierte IP-Adresse ändern und rebooten) durch, ändert sich dieser Link sofort auf die neue IP-Adresse ohne weiteres zutun.
-
ABER wo gehört dann die Zeile "background" rein
Du musst in den RAW-Editor:
- "Dashboard Overview"
- im Burgermenü (rechts oben) auf "Edit Dashboard"
- wieder im Burgermenü auf "Raw-Configuration-Editor"
Dort im Editor muss background: auf dieselbe Ebene wie views: – also am besten einfach darübersetzen:
.
-
Ich kann schon gar nicht mehr zählen wieviele Ratsuchende sich ihre Probleme selbst machen, weil sie meinen unbedingt feste (statische) IP-Adressen verwenden zu müssen…
Meine Empfehlung: bleibe bei DHCP und reserviere eine Adresse im DCHP-Server (Router). Problemloser geht es nicht. Und auch sauberer geht es nicht, denn die Liste der Reservierungen ist „die Quelle der Wahrheit“, anstatt alle Informationen quer über das Netzwerk zu verteilen.
An alle Helfer: Bitte bleibt konsequent bei den beiden Begriffen
- „feste (statische) IP-Adresse“, die im Endgerät konfiguriert wird
- und „reservierte IP-Adresse“, die im DHCP-Server konfiguriert wird.
Nagelt bitte auch die Ratsuchenden auf diese beiden Begriffe fest. Ansonsten kommt es immer wieder zu Missverständnissen.
-
-
ich würde gerne wissen, ob der LED-Trafo bei Nutzung mit RGBW2 dimmbar sein muss oder nicht. Beim Shelly Dimmer2 sitzt das Relay ja vor dem Trafo, weshalb der Trafo dimmbar sein muss. Bei der RBW2 sitzt das Relay, soweit ich das gesehen habe, hinter dem Trafo. Somit müsste der Trafo ja eigentlich bei der RGBW2 nicht zwangläufig dimmbar sein, da das dimmen ja erst nach dem Trafo stattfindet. Über Aufklärung bin ich euch sehr dankbar.
Richtig erkannt.
Der TrafoDas Netzteil interessiert der Dimm-Vorgang des RGBW2 überhaupt nicht. -
Dein Router bzw. DHCP Server weiss ja sonst nicht, dass diese Leuchte immer genau diese IP haben möchte
nicht „haben möchte“, sondern „bereits hat“.
Ein Problem ergibt sich daraus nicht sofort, sondern erst, wenn der DHCP-Server diese IP-Adresse trotzdem vergibt. Da die Adressen üblicherweise aufsteigend vergeben werden, kann das schon eine Zeit dauern.
Und auch dann pingen DHCP-Server üblicherweise (keine Ahnung, ob Fritzbox das so macht) die Adresse erst an, bevor sie vergeben wird („Conflict-Detection“)Dirk Labonte: Ich empfehle DHCP mit reservierter IP-Adresse – unabhängig davon, ob hier jetzt ein Adresskonflikt die Ursache ist.
-
Wechselschaltung: Kriegt der Shelly mit ob das Licht an oder aus ist?
Ja, denn vorher schaltete der Schalter, bzw. die Wechselschaltung das Licht direkt; nachher schaltet der Schalter stattdessen die Shelly, welche dann im Nachgang das Licht schaltet.
Die Shelly ist das Relais, also quasi der eingeschobene Mittelsmann. -
-
Was mir da noch aufgefallen ist: der Sensor wurde beim Router einmal als WLAN und einmal als LAN angezeigt.
Wie gesagt, nicht viel Ahnung, aber kann das daran leihen das er dann über meinen AP der per LAN am Router hängt im Netz war?
Ja, auf jeden Fall. Der Telekom-Router weiß ja nichts von dem zweiten Accesspoint.
Der zweite Accesspoint spielt jetzt aber keine Rolle mehr, oder? -
Hoffe das passt so.
Ja, das ist gut. Für mich sieht alles fehlerfrei aus.
-
kkirchhoff: Du musst schon ein bisschen mitarbeiten. Es ist ineffizient, wenn man herumraten muss. Zeige doch bitte Screenshots von der Shelly (IP-Adresse und CoIot), sowie von deinem Accesspoint/DHCP-Server (DHCP-Bereich, aktuell im WLAN registrierte Clients), eventuell dazu vorher die Shelly Door/Window 2 aufwecken.
-
(batterie / accu betriebene shellys sollten immer per fester IP (reservierung im router ist nicht gemeint) betrieben werden.
Für diese Pauschalaussage hast du bestimmt eine Begründung, oder nicht?
Ich habe eine Shelly Door/Window 2 im Keller, und die läuft zuverlässig und verzögerungsfrei per DHCP. Und vom Keller hoch muss sie sogar noch per D-Lan zum Home-Assistant.Meine beiden Door Window 2 waren eine ganze Zeit lang nicht verfügbar. Das habe ich gelöst indem ich die CoIot Adresse auf die neue HA angepasst habe aber jetzt habe ich das Problem, das die Status Änderungen der Shellys nur sehr unzuverlässig in HA ankommen.
Jetzt hätte ich zunächst gesagt „zeige doch mal diese Änderung (Screenshot)“, allerdings bedeutet „unzuverlässig“ ja nicht „gar nicht“. Daher kann es daran eigentlich nicht liegen.
Hat sich für die Sensoren bezüglich WLAN-Verfügbarkeit etwas geändert?
-
Ich habe das Skript etwas generischer gestaltet, so dass man nicht nur zwischen zwei sondern mehreren Werten weiterschalten kann:
Code
Alles anzeigenalias: Light toggle between mode: single variables: turn: toggle vals: - 8 - 192 sequence: - data: brightness: | {% set cnt = vals | count %} {% if cnt == 0 %} {% set vals = [8, 181] %} {% elif cnt == 1 %} {% set vals = [0] + vals %} {% endif %} {% set vals = vals | unique | sort %} {% set thresh = 2 %} {% set current = state_attr(entity_id, 'brightness') or 0 %} {% if turn | string == 'on' %} {{ vals[-1] }} {% elif turn | string == 'off' %} {{ vals[0] }} {% elif turn | string == 'toggle' %} {% if current <= vals[0] %} {{ vals[1] }} {% elif vals[-1] <= current %} {{ vals[0] }} {% else %} {% for i in range(0, (vals | count) - 1) %} {% set mean = (vals[i] + vals[i+1])/2 %} {% if vals[i] <= current and current < mean %} {{ vals[i+1] }} {% elif mean <= current and current < vals[i+1] %} {% if i+2 < cnt %} {{ vals[i+2] }} {% else %} {{ vals[0] }} {% endif %} {% endif %} {% endfor %} {% endif %} {% endif %} entity_id: "{{ entity_id }}" service: light.turn_on
Aufgerufen wird es folgendermaßen:
Codesequence: - service: script.light_toggle_between data: entity_id: light.schlafzimmer_led1 vals: - 8 - 192
Bei vals können nun auch mehr als zwei Werte eingetragen werden.
-
-
Mach mal nen reboot des Shellys!
In zwei Jahren mit 4 Stück Shelly RGBW2 hatte ich das Phänomen insgesamt 2×. Jetzt ist es allerdings schon länger nicht mehr aufgetreten.
Reboot hatte jeweils geholfen: Weboberfläche per IP-Adresse im Browser, Settings, Reboot Device -
Fenster-offen-funktion
Ich bin mittlerweile soweit, dass ich behaupte: Eine Fenster-offen-Funktion kann bei keinem Heizungsthermostat (egal, ob Shelly oder nicht) zufriedenstellend funktionieren. Warum?
1. Es muss ein ausreichend starker Temperaturabfall festgestellt werden, was naturgemäß mit einiger Verzögerung erfolgt. Ist die Außentemperatur nicht besonders niedrig, dann kann diese Verzögerung auch mal länger sein – auch so lange, dass man das Fenster längst wieder geschlossen hat. Der Temperaturabfall kann auch so langsam sein, dass er vom Thermostat überhaupt nicht erkannt wird.
2. Das Gegenstück – die Fenster-zu-Funktion – gibt es überhaupt nicht. Stattdessen geht der Thermostat einfach davon aus, dass nach einer gewissen Zeit das Fenster wieder geschlossen ist, und öffnet dann das Ventil auch wieder – selbst wenn das Fenster sperrangelweit geöffnet ist.
Meine persönliche Schlussfolgerung: Ohne Fensterkontakte ist das nicht praktikabel, und man lässt die Heizung dann also entweder einfach weiterlaufen, oder regelt manuell herunter.
Meine persönliche Lösung: Home-Assistant überwacht Zigbee-Fensterkontakte, und regelt nach 10 Sekunden „offen“ die entsprechenden Zigbee-Thermostate herunter. Sobald die Fenster wieder geschlossen sind, lasse ich eine einstellbare Zeit verstreichen, und die Thermostate regeln wieder hoch.
-
Das wichtigste in Kurzform:
- alle Shellys jetzt (in deinem alten Zuhause) ins WLAN einbinden, und später im neuen Zuhause SSID und Passwort identisch setzen
- auf DHCP lassen!
- jeder Shelly in der Weboberfläche auf der IP-Adresse einen aussagekräftigen Devicename geben
Falls du SSID und Passwort nicht identisch haben willst, dann schnapp dir irgendeinen alten Accesspoint /Router aus der Restekiste, und benutze den zur Einrichtung.
Später im neuen Zuhause mit dem neuen Accesspoint/Router kannst du im Browser einfach alle IP-Adressen abklappern.