Beiträge von Seven of Nine

über die REST-API http://ip-vom-Shelly/status

Zitat von MartinK.

Kannst Du einen DLAN Adapter für dieses Vorhaben empfehlen?

Wenn du bisher AVM Komponenten im Einsatz hast und damit zufrieden bist, würde ich auch dabei auf AVM zugreifen..

Es gibt ja so kombinierte Dinger, die über DLAN und Wifi arbeiten: FRITZ!Powerline 1260E

Ich hab hier TP-Link TL-PA8030P und die laufen eigentlich ganz gut.. Nicht vergleichbar mit einem Gigabit-LAN aber besser als nichts.

Bei PowerLine-Produkten solltest man meines Erachtens darauf achten, dass diie Geräte mit MIMO arbeiten. Dann werden nämlich neben dem Außenleiter auch der Neutralleiter und der Schutzleiter als Kommunikationsweg genutzt.

Das bringt a) mehr Geschwindigkeit und hat b) den Vorteil, dass es ach Phasenübergreifend funktioniert.

Die sind zwar vergleichweise teuer, dafür sind die Erfolgsaussichten deutlich höher.

Zitat von MartinK.

hast Du denn auch nur zufällig herausgefunden das beim TP-Link Switch was gefiltert wurde

ja, das war eher Zufall ..

Ich hab hier diverse Netzwerk-Komponenten im Einsatz (Router von AVM, Switche von TP-Link, DLAN-Adapter von TP-Link, AccessPoints von Ubiquiti) und hab mich (bei einer eigenen Software) gewundert, warum ich CoAp-Pakete nur von bestimmten Shellys empfangen kann, nicht aber von allen..

Irgendwann hab ich dann der Reihe nach die Komponenten ausgebaut / überbrückt und festgestellt, dass die TP-Link Switche die CoAp-Nachrichten der Shellys nicht bis zum Client durchlassen.

Da die Switche "unmanaged" sind hat man ja leider keine Möglichkeit zu überprüfen, ob und wie hier das IGMP implementiert wurde.

Es kann gut sein, dass die Switche alles richtig machen solange alle anderen Netzwerk-Komponenten ebenfalls mit IGMP-Snooping konfiguriert wurden.

Als ich das Problem vor einigen Monaten selbst hatte, war auf meinen Ubiqiti AP das IGMP Snooping noch abgeschaltet. Möglicherweise war das auch der Grund warum es bei mir nicht funktioniert hatte und bei Wolfgang funktioniert.

kurz wird schwierig aber ich versuch es mal

notwendiges Hintergrundwissen:
Shellys senden ihre Nachrichten über den eigenen Zustand per CoAp (constrained application protocol), das basiert auf UDP (user datagram protocol).

UDP Kommunikation findet generell entweder per Unicast (an ein einzelnes Gerät), per Broadcast (an alle Geräte im gleichen Netz) oder per Multicast (an eine bestimmte Gruppe von Geräten im Netz) statt.

Um Multicast-Nachrichten gezielt an bestimmte Geräte senden zu können wurde IGMP geschaffen (Internet group management protocol) und über die Jahre auch weiterentwickelt.

Primäres Ziel dabei: Daten sollen nur die Clients bekommen, die damit auch etwas anfangen können.

Je nach IGMP-Version haben die gesendeten Daten entsprechende Kennzeichen (Header), so dass ein Netzwerk-Gerät (Router, Switch, AccessPoint..) sie entsprechend gruppieren und filtern kann.

Die Shellys senden ihre Nachrichten wie weiter oben geschrieben über CoAp. CoAp-Nachrichten nutzen zwar Multicast, haben aber keinen entsprechenden IGMP(v3)-Header.

Das Bespiel:

Der Shelly sendet seine Nachricht an die CoAp-Multicast-Adresse.

Der Switch sieht: Hey, da kommt ein Multicast-Datenpaket, guckt sich das Paket an und stellt fest:

a) es hat keinen IGMP(v3)-Header, also muss es eine andere Art von Multicast sein.

b) CoAp? nie von gehört..

und muss sich jetzt entscheiden zwischen:
- Lass ich es trotzdem durch?
- oder muss ich es blockieren?

Ich hoffe das war halbwegs verständlich

Ob der Netgear-Switch CoAp als Protokoll nun kennt oder eben nicht, hab ich selbst noch nicht getestet. Könnte ich bei Gelegenheit aber nachholen.

Edit: OK, es ging nicht kurz

nicht setzen solltest du den Haken ganz unten:

Zitat von Tinola

Ganz schlimm ist der versuch die Farbe zu wechseln dann kannste die ganze App neustarten weil das geht nur einmal!

das kann ich bestätigen, bitte direkt beim Hersteller melden (hab ich auch schon, aber je mehr Meldungen sie bekommen je dringender wird es behandelt)

Zitat von alsk1

Hat das einen Grund bzw Sinn?

ja, dann zeigt er die "simulierte" Last soweit mir bekannt über Api / Coap / MQTT und App an..

Auf dem Screenshot ist jetzt nichts auffälliges drauf, aber da gibt es reihenweise andere Dinge, die man so einstellen kann, dass die Shellys damit ggf. Probleme kriegen..

wie sieht es denn mit Kanälen aus?

- Feste Kanäle oder Auto? wenn feste, dann welche?
- VHT20 oder VHT40?

- TransmitPower Auto oder Fester Wert? (low, medium, high?

- Wifi AI ist aktiv oder nicht? (Das trennt meines Wissens die Clients und macht jede Nacht einen Scan, um die besten Kanal-Einstellungen zu finden)

Android? IoS? Router/AP?

Bei mir hat es direkt im ersten Versuch geklappt, wird also nicht unbedingt an der Duo GU10 liegen..

Zitat von martin234

Ich schätze dass die Dinger zu warm werden und dann frittiert sind irgendwann.

Ich schätze einfach mal, dass du dein Unifi-Netzwerk (wie so viele) falsch konfiguriert hast und daher Probleme kommen. Beta-Features aktiviert, irgendwelche abstrusen Kanal-Einstellungen etc..

Ich hab aktuell weit über 40 Shellys aktiv und aboslut keine Probleme (4x Unifi AP).

Weder reconnects noch disconnects, sie laufen einfach durch und das schon seit Monaten
Kannst ja gerne mal die Einstellungen vergleichen:

RE: WLAN Zugriffproblem

Zitat von Kash

RAM und eingebundener SD-Speicher hat noch genügend Reserve.

Hast du mal direkt nach dem Neustart des Handys probiert und ggf. bei ein oder zwei grrößeren Apps den Cache gelöscht?

Zitat von Eulhofer

(Topologie will ich das gar nicht nennen ) laufen - völlig ohne Probleme.

Nutzt du ioBroker mit CoAp?

Ich 3 Stück davon und bei mir wurden die CoAp-Daten gefiltert. Nach dem Austausch sofort alles wieder gut.. Da die Dinger ja unmanged sind, keine Chance da etwas zu konfigurieren..

https://www.amazon.de/-/en/TP-Link-T…k/dp/B01EXDG2MO

Messen solltest du eher, ob an der Ader zum SW (vorher vom Shelly trennen) Spannung anliegt, auch wenn der Schalter den Zustand "aus" hat..

https://shelly.cloud/documents/deve…_api_access.pdf
Steht auf Seite 4 ff.

Dein Switch blockiert vermutlich ihm unbekannte UDP-Multicast-Pakete (CoAp)...

hab ebenfalls TP Link Switche mit exakt diesem Verhalten hier und sie deshalb mittlerweile rausgeworfen..

Ich hab mitlerweile diesen Managed Switch anstelle des TP-Link im Einsatz, der funktioniert einwandrei und filtert auch keine CoAp-Daten.

https://www.amazon.de/-/en/Netgear-G…s/dp/B07PDHVZNS

Die Datei runterladen:
http://api.shelly.cloud/firmware/SHSW-25_build.zip

irgendwo in der Homekit-Firmware gibt es ein Feld, wo man per Upload auf die Firmware akualisieren kann. da dann die runtergeladene Firmware auswählen.

das funktioniert aber eigentlich auch mit der Aktuellen Fiirmware.. das mache ich hier an verschiedenen Stellen..

ist auf dem Ziel-Shelly ein Username/ Passwort-Schutz aktiv (gewesen)?

dann muss das in der URL übergeben werden:

http://username:password@192.168....

hast du ggf noch eine aktive Browser sitzung? Das funktioniert bei mir einwandfrei..

bei der URL übergeben (außer bei localhost als Ziel)

http://username:password@192.168....

Technisch ist das wohl machbar, die täglichen Neustarts werden ihn nicht killen.

Insgesamt hört sich das für mich aber nach einer sehr unpraktikablen Lösung an..

Kannst du die Leuchtmittel auschen? (Stichwort ShellyDuo, ShellyDuo GU10) und ggf. einen Shelly1/ IX 3unter den Schalter (eventuell gegen Taster tauschen) bauen?