Beiträge von Seven of Nine

Hi Karl,
leider noch nicht.. ich muss mir erstmal eine SD-Card mit blankem Raspian installieren, da ich ehrlich gesagt keine Ahnung mehr hab, ob die ganzen Tools, die dafür notwendig sind (curl, gpg) auf dem Pi dann schon vorinstalliert sind..
Wirklich viele Schritte dürften es nicht sein, aber die müssen alle in der Shell ausgeführt werden..
Welche Raspian Version nutzt du denn aktuell? Buster? dann würde ich mir die SD-Card direkt passend betanken.

Zitat von WilliWinzig

ch wollte über den Shelly HT den Shelly 1 per Szene ansteuern, damit er einen Stellmotor für die Fußbodenheizung ein-/ausschaltet.

das geht mit Firmware 1.9 (kommt in Kürze) auch ohne Cloud, direkt über Actions im Shelly..
so sieht es dann aus:

Ist das bei anderen Einstellungen auch? würde mich nicht wundern bei der Anzahl Shellys (laut deiner Signatur) und deiner FritzBox..

Die FB 7490 ist eine SingleUser-Mimo Box, d.h. alle 2.4.Ghz Clients werden nacheinander abgearbeitet.. Die dürfte zumindest auf dem 2.4Ghz Band komplett überlastet sein..

Zitat von hardl

uch das Einrichten des Esptool auf meinem Macbook scheint nicht so einfach zu sein.

da kann ich nicht wirklich was zu sagen, nutze selbst Linux (oder gelegentlich mal Windows)..
Unter Linux war es ein einfaches pip install esptool

Endpunkte werden in der Regel einmalig direkt am Motor eingestellt, wenn man ihn einbaut:
[media]https://www.youtube.com/watch?v=3nJRI4KwiCk[/media]

wenn es ein paar Stunden geht und dann nicht mehr, mögliche denkbare Urachen:
1) eine Komponente "stürzt ab" und macht nicht mehr, was sie eigentlich sollte.
2) Ein Netzwerk-Gerät blockiert Traffic, den es eigentlich nicht blockieren sollte..

Mit Protokoll meinte ich eher sowas wie HTTP, CoAp, MQTT und dergleichen, also Teilbestandteile vom TCP/IP. Zudem müsste man wissen, ob es sich dabei um TCP oder UDP-Daten handelt, da diese unterschiedlich von den entsprechenden Netzwerk-Komponenten behandelt werden.
Das kann man vermutlich mit Wireshark mitlesen und auch analysieren, ist allerdings nicht einfach zu bedienen...

Schreibt eine oder mehrere der beteiligten Komponenten Logfiles, die du überprüfen könnstest? Eventuell hast du ja da entsprechende Fehlermeldungen?!?

Zitat von waterchill

Ich habe zwar IPTV aber es läuft genauso gut wie wenn alle IGMP an sind wie wenn auch aus sind.

Wenn es beim TV-Gucken nicht ruckelt lass es aus, wenn es ruckelt schalte es ein..

solange alle beteiligten Komponenten damit korrekt umgehen hat es keinen "negativen" Einfluß auf die Coap-Nachrichten der Shellys..

Was bei deinen Logitech Pop Schaltern das Problem ist? Gute Frage aber das kann ich leider auch nicht sagen, da ich die Geräte und deren Kommunikationswege nicht kenne..

Wenn du mir sagen kannst, wer mit wem über welches PRotokoll in deiner Kette redet, kann ich dir eventuell sagen, wo es problematisch werden könnte..

PS: Ich bin bekennender Apple-Hater, soll heißen sowas kommt mir nicht ins Haus

Zitat

Eine Aktion im Batterie-Modus dauert bei mir immer 8-9s

Wie ich hier gelesen habe sollte das in 3-5s erledigt sein

Ja, so die Theorie.. ich hab hier 4 Unifi AccessPoints, bei 3 (alle AP AC-LR, Baujahr Mitte 2019) von denen dauert es 2-3 Sekunden, beim vierten (AP AC-Lite Baujahr Ende 2019) dauert es ~10 Sekunden..

Von welchem Hersteller sind deine deine Netzwerk-Komponenten? Nicht zufällig Unifi, oder?

Schau dir mal das PDF hier ab Seite 17 an, da wird es eigentlich gut erklärt.
https://elib.uni-stuttgart.de/bitstream/1168…/BA_IoT_CDM.pdf

Prinzipiell sollte das Aktivieren von IGMP-Snooping zunächst mal keine Auswirkungen haben, weil es eigentlich dazu gedacht ist bestimmte Multicast-Daten nur an die Empfänger zu leiten, für die die Daten auch bestimmt sind. Dazu werden die Daten-Pakete mit einem IGMP-Header versehen.

Bei CoAp ist es so, dass alle Teilnehmer (Shellys) ihre Daten via multicast udp an die vituelle IP 224.0.1.187 auf Port 5683 schicken.

Meines Wissens senden die Shellys ihre CoAp-Nachrichten aber ohne IGMP-Header, dementsprechend sollte ein Switch/AP/Router die Pakete eigentlich nicht mittels IGMP-Group gruppieren sondern als unbekannte Multicast-Nachrichten einfach weiterleiten.

In der Praxis ist es leider so, dass einige Switche/Router/AP diese bei aktivem Snooping aber trotzdem gruppieren.

Das kann dazu führen, dass andere Geräte im Netz (ioBrkroker, HomeAssistant, OpenHAB) die Nachrichten gar nicht oder erst dann bekommen, wenn sie selbst regelmäßig Coap-Pakete an die 224.0.1.187 schicken. So macht es z.B. HomeAssistant, wenn man im ShellyForHass den IGMP-Fix aktiviert.

Bei anderen Herstellern ist es so, dass die 224.0.1.187 als unbekannte Multicast-Adresse interpretiert wird (was eigentlich auch korrekt ist, solange sie kein CoAp kennen).

Leider ist es bei einigen Netwerk-Komponenten so, dass unbekannte Multicast-Pakete komplett blockiert werden, dementsprechend krieg z.B. der ioBroker-Adapter keine Status-Updates von den Shellys. Ein Beispiel dafür wäre z.B. der TP-Link Switch TL-SG108 V3.

Das würde bei dir z.B. passieren, wenn du diesen Haken auf "Enable" stellst.

Grundsätzlich würde ich IGMP-Snooping deshalb so lange deaktiviert lassen, wie es keine andere Notnwendigkeit (IP-TV) im Netzwerk dafür gibt.

Zitat von Schubbie

Ich glaube, da war etwas mit Sonderzeichen, die man vermeiden sollte, bin mir jedoch nicht sicher.

Exakt, Sonderzeichen, die nicht Bestandteil der URL sein dürfen, müssen entsprechend kodiert werden:
https://www.w3schools.com/tags/ref_urlencode.ASP
Erlaubt sind -, ._~
Nicht erlaubt (und dementsprechend kodiert werden) sind eigentlich alle anderen..
?, /, #, :sind reservierte Zeichen, auch die müssen ebenfalls kodiert werden..
Statt einem Leerzeichen nutzt man %20 usw.

Hast du mal den internen DNS im Router getestet? der sollte eigentlich schneller sein, weil im eigenen LAN erreichbar..
Sind die Shelllys im ioBroker denn dauerhaft erreichbar oder sind sie da auch irgendwann offline? Eventuell lässt du den Broker mal einen Tag aus und guckst, ob sie dann in der Cloud online bleiben..

Hat dein Router irgendwelche Einstellungen zum Thema IGMP oder unknown UDP requests?

Ich denke der wird es genauso tun, allerdings sind de beiliegenden Kabel auf beiden Seiten Female, für den Shelly brauchst du auf der Shelly-Seite Male..

Das OTA-Update über die Github Links würde ich vorher testen, Hinweg:
http://shellyip/ota?url=http://dl.dasker.eu/firmware/mg2tasmota-Shelly2.zip
Der Rückweg geht (auch wenn es im anderen Github Repo anders steht) hiermit:
https://github.com/yaourdt/tasmota-to-mgos

Probieren würde ich es auf jeden Fall, wenn es nicht klappen sollte kannst du ja immer noch den FTDI bestellen..

der IX3 steuert deine Shelly2.5 über HTTP-Kommandos, da spielt es keinerlei Rolle, ob der mechanisch verriegelt ist oder nicht..

Verriegeln muss nur das Gerät, welches direkt mit dem Motor verbunden ist und das ist der Shelly im Rolladen-Modus.

Zitat von hardl

aber vermutlich ist es billiger und schneller einen FDI zu kaufen oder gibt es da Unterschiede?

ja, hin und Rückporto wären vermutlich teurer als ein FTDI, die Dupont-Kabel brauchst du aber auch noch.. ich hab den hier, der funktioniert einwandfrei:
https://www.amazon.de/AZDelivery-FT2…e/dp/B01N9RZK6I

es gibt wohl noch eine andere Möglicheit, hiermit (temporär) zu Tasmota:
https://github.com/yaourdt/mgos-to-tasmota

anschließend wieder zurück zur Original-Firmware:
https://github.com/yaourdt/tasmota-to-mgos

Geht (angebilich) beides Over-The-Air, also ohne FTDI & Jumper-Kabel.. Ich hab es selbst noch nie ausprobiert, wollte es aber immer mal testen.

Alternativ baust du ihn aus, packst ihn in einen wattierten Umschlag und schickst ihn mir..
Dann flashe ich ihn auf Original-Firmware und schicke ihn zurück...

Die Meldung ist auch grundsätzlich erstmal richtig, da er ja tatsächlich ein Update machen soll.. Der Bootloader sitzt bei beiden Shelly im gleichen Speicherbereich, von daher sollte das anstandslos klappen.. zumal der Geräte-Typ (SHSW-21) ja jetzt ebenfalls identisch ist..

einen FTDI hast du nicht zufällig rumliegen? damit lassen sich Shellys ebenfalls problemlos mit beliebiger Firmware betanken..

mhh, klappt den das Installieren der Shelly-Homekit-Version für den alten 2er?

http://<ip-vom-shelly>/ota?url=http://archive.shelly-faq.de/shelly-homekit-Shelly2.zip

Wenn die (Version 1.7) drauf ist, kann man auf jeden Fall wieder auf die richtige Version zurück..

Timer (Auto on / Auto off) gehen auch ohne Internet, lediglich die Weekly Schedules benötigen die Uhrzeit..

Der Shelly auf dem Bild hat keine Uhzeit, denn er kommt (wegen fehlendem Gateway) nicht an einen NTP-Server . Der Timer läuft trotzdem.

wenn du anschließend die http://<ip-vom-shelly>/ aufrufst, kommt die reguläre Shelly2 Oberfläche oder die Homekit-Version? Das Update dauert eine Weile, also ca 2-3 Minuten warten..
Wichtig ist: Browser-Cache löschen oder die URL mit z.B. SHift+F5 neu laden (Windows)..

Schaltet der auch direkt ein, wenn die Ader von SW nicht angeschlossen ist?

Der Shelly steht von Hause aus in der Einstellung "SWITCH - Operates the Shelly device according to the state of the switch or button connected to the device."

Ohne angeschlossenen SW sollte er also aus bleiben.

Falls er nur mit angeschlossenem SW direkt angeht:
Ist auf der Ader, die an SW angeschlossen wurde, permanent Spannung drauf? Also auch dann, wenn der Schalter im Zustand aus ist?