Beiträge von Seven of Nine

Zitat

Was nennst Du freigeben? Wenn Dimitar die Links auf Facebook shared und per PM verschickt, gehe ich erstmal davon aus dass eine Nutzung ok (gestattet) ist.

gestattet ist es sicherlich, sonst hätte er den Link nicht auf Facebook gepostet.. ich bin mir halt nur nicht sicher, ob es allen anderen Benutzern hier bewusst ist, dass es sich dabei um Test-Firmware handelt und die hat sich seit dem Teilen auf Facebook etliche Male verändert. Daher der Hinweis, ist in keinster Weise böse gemeint..

Zitat

Ich finde es eher schade wie ich manchmal den Eindruck habe, das hier mit Infos "hinterm Berg" gehalten wird.

Es gibt natürlich Informationen, die ich und andere hier ausdrücklich nicht weitergeben dürfen, alles andere kommuniziere ich (oder versuche es zumindest) so offen wie möglich..

Oder hattest du bei meine vorherigen Beiträgen zum Thema Unicast, Cors etc. den Eindruck, dass ich euch Infos vorenthalten will?

In eurem Interesse: lasst die Finger von irgendwelchen Versionen, die nicht offiziell freigeben sind .... RC-Versionen sind oft noch fehlerhaft und speziell das test-Repo enthält hin und wieder mal Versionen, die einen Shelly komplett stilllegen können

und ja, der ioBroker und der Motion stehen im Moment auf Kriegsfuß, kommt vom Polling des Brokers (der triggert den alle 10 Sekunden, wenn man es nicht ändert -> das ist ein totaler Akku-Killer).

Stuebi hat aber heute Morgen Änderungen gepusht und das Polling auf stündlich umgestellt.

Ich beantworte mal 1-3 zusammen, weil es ja doch alles irgendwie zusammenhängt..

Ein Shelly unterstüzt aktuell nur einen DNS-Server. Das reicht in 99% aller Fälle auch aus, weil genau ein DNS-Server vorhanden ist, nämlich der Router des Shelly-Besitzers ..

Man könnte mehre DNS-Server im LAN betreiben und einen Loadbalancer (z.B. Citrix Netscaler, HA-Proxy..) davor setzen und damit eine Ausfallsicherheit erzeugen. Die Frage ist halt nur ob es den Aufwand wert ist..

Einen Feature-Request kannst du natürlich einreichen, ich bin mir aber relativ sicher, dass er abgelehnt wird weil

a) so wie ich es gesehen hab unterstützt das Mongoose-OS es nicht, das wäre aber Grundvoraussetzung.

b) Braucht man es eigentlich nicht solange die eigene Infrastruktur einwandfrei läuft.
c) die potentielle Zielgruppe vermutlich deutlich unter 5% liegt.

Zitat von Qara2003

Habe den Shelly Adapter nochmal neu installiert aber auch keine Änderung sichtbar.

welche Versionsnummer hat der Adapter denn?

ist zwar mittlerweile arg offtopic aber wenigstens eine kleine Erläuterung, weil es ja immer wieder mal als Begriff hier im Forum auftaucht.

Docker kann man sich als Abstraktions-Schicht vorstellen. Dabei geht es primär darum, Anwendungen von einem darunter liegenden Betriebssystem zu trennen..

Hier wird quasi ein (fast) nacktes Betriebssystem installiert, darauf dann lediglich der Container-Dienst (Docker oder z.B. containerd) ..

Anwendungen installiert man dann nicht auf dem Betriebssystem sondern "verpackt" sie in ein Container-Image und startet statt der eigentlichen Anwendung einfach den Container.

Hattest du den Schalter während des NightMode getestet?

bzw. kannst du den NightMode mal vollständig deaktivieren? wenn der Shelly keine Uhrzeit synchronisieren kann wird der NightMode möglicherweise dazwischen gefunkt haben..

da steht nämlich Helligkeit 60% und das ist (wenn ich mich richtig erinnere) exakt dazu da, den Schalter auf eine bestimmte Helligkeit zu begrenzen..

Zitat

Hallo Seven of Nine , kann das auch der (ein) Grund sein, warum die FB7490 ab einer bestimmten Anzahl an Shellys sehr langsam wird?

ob der Coap-Traffic Auswirkungen auf die Weboberfläche der FritzBox hat kann ich nicht beantworten..

Die 7490 ist eine SU-MIMO Box und kann immer nur eine gleichzeitige WLAN-Verbindung verarbeiten, alle anderen Clients landen in einer Warteschlange.. Ich könnte mir vorstellen, dass eher da das Problem der lahmen Weboberfläche begraben liegt aber ist auch nur eine Vermutung.

Zitat von TPau23

wenn ich nix mit ioBroker o.ä. mache und auch sonst nur per App, Cloud oder direktes Webinterface die shellies anspreche, dann deaktiviere ich sowohl CoIoT also auch CORS, korrekt?

exakt richtig, denn weder die App, die Cloud, das Webinterface oder Actions benötigen CoIot (Coap) bzw. CORS..

@Pete0815 im "Auslieferungszustand" (also nach dem Upgrade) ist das Feld leer, sobald es aber erstmals inhaltlich verändert wird muss entweder die Unicast-IP oder eben "mcast" da rein.

Zitat von t0bse

Unicast wird Multicast sowieso komplett ablösen in ein paar Monaten, so hat es Dimitar auf facebook angekündigt.

ja, das ist auch absolut sinnvoll.. bei entsprechend großer Anzahl Shellys (siehe z.B. meine Signatur) ist das "Grundrauschen" durch die Coap-Nachrichten nämlich schon recht heftig..

Der Stromverbrauch wird meines Wissens nur gemessen, wenn der Dimmer2 mit Neutralleiter betrieben wird.. Ich würde also mutmaßen, dass du ihn ohne N betreibst?

Könntest du mal die Ausgabe von http://<ip-vom-shelly>/settings hier posten?

<ip-vom-shelly> durch die IP-Adresse des Dimmer2 ersetzen..

SparkyMaster  t-600

Vielleicht eine blöde Frage, aber wirkt sich das nicht auch auf die Kalibrierung des Dimmers aus, wenn ich nach Kalibrierung mit allen 14 Leuchten (s.o.) plötzlich 11 davon per Shelly1 abschalte? müsste /sollte ich dann nicht jedes Mal neu kalibrieren?

Zitat von Qara2003

Nein, Roaming ist schon klar. Ich bräuchte nähere Informationen zu den Advance Developer Settings, insbesondere zum Thema Unicast und welche Einstellungen dort vorgenommen werden können.

Unicast bezieht sich auf das Coap-Protokoll und wird im Falle von "mcast" (kurz für Multicast) an die 224.0.1.187 auf Port 5683 gesendet.

Alternativ können Shellys aber jetzt auch Unicast-Nachrichten an einen gezielten Empfänger schicken, da wird dann statt mcast (bzw. leer) einfach die IP-Adresse des Coap-Servers (ioBroker, OpenHAB, HomeAssistant..) angegeben, an den du Statusnachrichten schicken willst..

Unicast-Daten werden im Gegensatz zu Multicast-Nachrichten nur an einen Empfänger geschickt, werden aber im Gegensatz zu Muticast auch über Router hinweg transportiert.

Vorteil: der Server, der auf die Coap-Nachrichten lauscht, kann dadurch auch in einem anderen Netzwerk-Segment stehen, z.B. in bzw. hinter einem Bridge-Netzwerk eines Docker-Containers, einem separierten IoT-VLAN oder irgendwo im Internet. Solange das Routing funktioniert ist der Standort dabei egal.

Und wichtig: Solange man keinen Coap-Server hat, der die Nachrichten verarbeiten kann, sollte man das CoIoT-Protokoll komplett deaktivieren. Das reduziert den Netzwerk-Traffic erheblich. Der ist aus Gründen der Rückwärts-Kompatibilität zu ioBroker, OH und Co. zwar per Default aktiv, wird aber oft gar nicht benötigt.

Gleiches gilt übrigens für den CORS-Haken ("Cross-Origin-Ressource-Sharing" ).. Wenn du direkt per Javascript, z.B. mittels .fetch() auf die REST-API vom Shelly zugreifen willst den Haken setzen, ansonsten bleibt er aus ..

Zitat von fe22st

ich habe zum testen einfach mal IOBroker als Docker Umgebung auf meinem Mac gestartet mit dem Port 8081.

das Problem ist der ioBroker im Docker Container..

aktuell senden die Shellys per UDP Coap Multicast-Nachrichten an die IP-Adresse 224.0.1.187 auf Port 5683.. die kommen aber logischerweise im Docker-Container nicht an..

entweder nutzt du MQTT oder wartest auf Firmware 1.10, da kann man Coap-Nachrichten auch per Unicast an eine gezielte IP/Port senden...

dann müsstest du lediglich den Port 5683 vom Container nach "außen" freigeben und im Shelly den ioBroker als Ziel für die Coap-Nachrichten angeben.

Firmware 1.10 ist gerade im QA Test und wird vermutlich in den nächsten Tagen / Wochen ausgerollt.

Das ist doch ein Standard-Gira-UP-Einsatz.. da passen unter Garantie die System 55-Wippen drauf..

Amazon bestätigt es auch indirekt

Wenn du trotzdem noch Bedenken hast:

https://www.gira.de/kontakt und per Mail / Telefon nachfragen..

Aktuelle Firmware (1.0.10) hast du installiert?

Zitat von Yssal

Ich denke du hast, auch der seven, nicht verstanden warum ich Dimmer und shelly 1 zusammen gebraucht habe.

Aus dem Dimmer kommt nur ein Ausgang zu den strahler, d.h. Bei 14 Strahler, werden alle zusammen ein- oder ausgeschaltet / gedimmt.

doch, ich hab das Problem schon verstanden aber es ändert nichts an der Tatssache, dass am Dimmer nur dimmbare Leuchtmittel (explizit für Phasenanschnitt/abschnitt gekennezeichnet) angeschlossen werden dürfen. Erkennt man am Symbol siehe Anlage.

Ein Shelly1 ist jedenfalls kein dimmbares Leuchtmittel.

Im Zweifelsfall (wenn du einzelene Bereiche komplett an/ausschalten oder dimmen willst) müssen dann mehrere Dimmer (statt der Shelly1) verbaut werden, die aber nicht hintereinander verkettet sondern parallel, sprich dann darf kein weiterer ShellyDimmer in den Schalter.

Alternativ könnte man es möglicherweise auch mit Shelly1 + ShellyDuoG10 lösen (komplett ohne Dimmer)..

Wenn du aber bereits 6 Dimmer "zerschossen" hast kann ich dir nur dringend ans Herz legen eine Elektro-Fachkraft zu Rate zu ziehen.

wie du die einzelnen nicht erreichbaren Shellys wieder ins Leben zurückholst müsste man im Einzelfall gucken..

Reset geht bei den meisten über Sicherung raus/rein und dann 5x per Schalter an/aus.. (dann klackert das Relay ein paar Mal)

Die, die sich nicht finden lassen: sind Schalter dran? lassen sie sich darüber noch schalten?

PS: Die Probleme mit den Unifi APs sind seit Firmware Version 1.10RC3 (guckst du zB hier RE: Shelly 2.5 Testfirmware) behoben, eine finale Version davon wird nicht mehr allzu lange auf sich warten lassen..

Eventuell wechselst du also doch zurück auf das Unifi WLAN bevor noch mehr Shellys in einen "undefinierten" Zustand wechseln und du den Überblick verlierst, welcher Shelly welchen Fehler hat..

wenn du Disconnects hast / hattest mach direkt nach dem Update ein http://<shelly-ip/erase_sys_params 

Zitat

frage ich mich ehrlich gesagt, wieso man hier künstlich so ein "AP Roaming" Verfahren einbaut(?)

ganz einfacher Grund:

wenn du jetzt eine AP neu startest, dann verbindet sich der Shelly mit einem weit entfernten AP und bleibt da "kleben".. beim neuen Roaming (gestern erst ausführlich getestet) hüpft er dann nach einiger Zeit von alleine zurück auf den nähergelegenen AP..

AP-Roaming muss mit Firmware 1.10RC3 explizit aktiviert und konfiguriert werden.