Ich habe mal einen batteriebetriebenen Betriebsstundenzähler für einen Kolbenmotor auseinandergenommen, der einen Reedkontakt als Auslöser zum Zählen verwendet hat. Da war weit und breit kein Magnet. War das eine andere Bauform?
Beiträge von RockNLol
-
-
Hallo,
ich habe mittlerweile 4 Shelly Blu DoorWindow bei Amazon gekauft. Abgesehen davon, dass 2Stk DoA waren, war bei 3/4 Shellys und beiden Ersatzshellys für die Kaputten die mitgelieferte Batterie leer.
Die Batterie ist im Auslieferungszustand ja schon eingebaut. Heißt das nicht, dass dann während dem gesamten Transport bei jeder kleinen Erschütterung der Reed-Kontakt auslöst und der Shelly sendet? Würde zumindest erklären warum die alle leer sind.
Hat das Problem noch jemand? Liegt das an Amazon?
Ich freue mich auf eine sachliche Diskussion.
LG
R'N'L
-
Na gut, Einschaltstrom ist was anderes, ist aber schon komisch, dass 2 Geräte aus der Pro Serie so unterschiedlich reagieren, ohne dass eine Empfindlichkeit angegeben ist. Ich will den Geschirrspüler auf dem Shelly Pro 2PM lassen, weil ich ihn da separat absichern kann. Für einen 4PM mit Sicherung nach jedem Ausgang habe ich keinen Platz im Sicherungskasten.
Amazon ist zum Glück sehr kulant und schickt mir nochmal einen neuen Pro 2PM. Ich hoffe auf eine andere Charge nachdem das schon ein Monat her ist.
-
Wenn ichs am Shelly Pro 4PM direkt daneben anstöpsle, den ich fürs Licht verwende, dann sehe ich ein Maximum von 2083W und der Geschirrspüler läuft das ganze Programm ohne overcurrent durch.
-
hi,
ich habe einen Shelly Pro 2PM verbaut, der meinen Geschirrspüler und meine Waschmaschine schalten und überwachen soll. Schalten funktioniert schon mal, aber wenn der Geschirrspüler loslegt, zieht er rund 2kW, wobei der Shelly plötzlich 28A anzeigt und der Überstromschutz den Ausgang ausschaltet. Waschmaschine habe ich noch nicht getestet, aber ich vermute, dass da dasselbe passieren wird. Natürlich ist eine 16A Sicherung vor jeden Eingang geschaltet, ich nehme also an der Shelly misst hier einfach Mist. Die Firmware ist aktuell, was kann ich denn da noch machen? Muss ich das Ding austauschen?
LG
R'N'L
-
Danke, dass du dich weiterhin an meiner Problemlösung beteiligst.
Hier mal ein Netzwerkplan, sollten weitere Details nötig sein, kann ich das gerne ergänzen:Mit "Pseudofixe IPs" habe ich die Vergabe von IPs via DHCP mit Reservierung einzelner IPs für gewisse MAC-Adressen gemeint. Dies übernimmt OPNsense. Die UniFi-Geräte wissen darüber bescheid, im UniFi-Controller ist die DHCP-Funktionalität deaktiviert. Ich glaube gar nicht, dass die UniFi-APs als DHCP-Server fungieren können, dafür braucht es glaube ich einen UniFi-Controller oder eine UniFi Dreammachine. An Standort 1 gibt es nicht einmal einen UniFi-Controller, der sitzt am Standort 2.
Pihole läuft in meinem Setup nicht auf einem pi, sondern als container virtualisiert auf dem Proxmox Server. Pihole befindet sich im VLAN10 mit den ganzen anderen Servern und VMs.
Die Modems sind beide im Bridge-Modus und haben damit keine Firewallfunktion. Vom VPN-Traffic bekommen die Modems ja auch gar nix mit, der wird ja schon von OPNsense verpackt und verschlüsselt.
Das interne routing übernimmt an beiden Standorten OPNsense. Alle Switches sind VLAN-aware. Der große TP-Link TL-SG1016DE an Standort 1 ist Layer 2 und "smart"-managed, der USW-24-Pro an Standort 2 könnte theoretisch Layer 3, ist aber nur als Layer 2 konfiguriert und übernimmt somit kein Routing.
Ein Firewall- oder Routing-Problem klingt für mich unwahrscheinlich, wenn, wie wir gestern herausgefunden haben, die Shellies auf Port 80 sehr wohl auf die REST-API antworten. Auch sehe ich die Pakete des Verbindungsaufbaus in der Firewall von OPNsense.
Seven of Nine's Vermutung von Browser oder sonstiger Konfiguration halte ich für wahrscheinlicher und in die Richtung werde ich nun diagnostizieren.
-
Seid mir nicht böse, aber was ändert pihole an einer Verbindung mit einem Shelly? Ich gebe direkt die IP vom Shelly ein, der DNS Server hat da nichts mitzureden. Umgehen des piholes ändert ja auch nichts, und auf Standort 1 mit einem exakt gleich konfigurierten pihole funktioniert es.
Ich danke euch für eure Beiträge, ihr habt mir sehr geholfen.
Trotzdem möchte ich noch ein Wort zur Forenkultur hier verlieren:
Was glaubt ihr, wer sich einen Shelly kauft und sich damit ein Smarthome zusammenbastelt? Glaubt ihr das sind nur Leute die sich die Fritzbox vom Provider hinstellen?
Ich beschäftige mich in meiner Freizeit mit allen möglichen technischen Disziplinen, "Jack of all trades, master of none" triffts wohl ganz gut. Ich lerne mit allen verfügbaren Mitteln das, was mich interessiert und da gehört Netzwerktechnik dazu. Ich kann nicht nur weil ich ein paar Shellies verwenden will ein Informatikstudium abschließen. Mein gesamtes Netzwerk habe ich mir über Jahre hinweg mit Anleitungen aus dem Internet zusammengebaut und für meine Zwecke funktioniert es sehr gut.
Ich habe von Anfang an geschrieben, dass mein Setup im Vergleich zu Ottonormalverbraucher sehr komplex ist, das war kein Geheimnis. Dass ihr mir nicht mit eurer magischen Glaskugel helfen könnt ist mir auch klar.
Ein Forum lebt davon gemeinsam Lösungen zu Problemen zu finden und diese Lösungen festzuhalten.
Informationslose Beleidigungen tragen weder zur Lösung bei, noch sind sie es Wert sie festzuhalten. Das können andere Foren besser.
-
Ich verwende pihole um auf DNS-Ebene Werbung zu blockieren. Ansonsten habe ich nicht nur mit meinem Standardbrowser Firefox, sondern auch Edge und Chrome getestet. In Firefox verwende ich zwar ublock origin als Werbeblocker, dieser war zum Testen aber deaktiviert. In Chrome und Edge ist keinerlei addon/werbeblocker installiert.
Testweise habe ich jetzt mal meinen DNS-Server auf 1.1.1.1 geändert und somit das pihole überbrückt. Das hilft aber leider auch nicht.
Außerdem verwende ich pihole auf beiden Standorten und in Standort 1 funktioniert es ja.
-
Ohh! Auf der REST-API bekomm ich sofort einen Output!
Und jetzt?
-
Was ist jetzt mit TRV ging es nicht die ganze Zeit um nen Plus?
Sowohl um einen Plus als auch mehrere TRVs. Ein alter 2.5 im selben Netz macht keine Probleme
Das ist grundsätzlich die erste Amtshandlung, die man macht
...aber auch die aufwändigste
ok, kannst du das mal mit cURL testen? wenn nmap und telnet auf Port 80 klappen bzw. antworten dann müsste es auch mit dem cURL gehen. Dann könnte das ein einfaches Browser-Problem deines Rechners sein.
[...]
cURL reagiert ähnlich wie der browser und wartet vergeblich auf eine Antwort, sowohl bei Plus als auch TRV. Der 2.5 gibt mit curl entsprechend auch Daten zurück.
OK, hab jetzt eine Weile die Live-Logs der Firewall auf beiden in die Verbindung involvierten Routern beobachtet. Nichts als grüne Balken...
-
Ahh das erklärt den teilweise 1500ms ping auf die TRVs.
Mein VPN-Netzwerk ist halt ein always-on Site-to-Site-VPN und keine Client-Server-Verbindung. Einzelne Clients sollten so vom VPN gar nichts mitbekommen. Liegt eine angeforderte IP außerhalb des eigenen Subnets, wird der Router konsultiert, der dann entsprechend der IP weiter routet. Liegt die angeforderte IP beim anderen Standort, gehts über den VPN-Tunnel anstatt ins Internet. Routing-Tabellen für Site-to-Site-VPNs werden von opnsense im Hintergrund angelegt, die habe ich nicht selbst erstellt, sie funktionieren aber. Egal ob SMB auf einen Server am anderen Standort, ein Videostream der Überwachungskamera oder eine Intranetseite. Routing und VPN funktionieren.
Ich weiß jetzt nicht, wie das tracert aussehen soll, von meinem PC in Standort 2 auf einen Shelly TRV an Standort 1 sieht es aber so aus:
Code>tracert 10.0.3.200 1 <1 ms <1 ms <1 ms <Router Standort 2> [192.168.0.1] 2 * * * Zeitüberschreitung der Anforderung. <---- Hier sollte sich wahrscheinlich der andere Router melden? Sieht aber auch bei tracert auf eindeutig funktionierende Geräte so aus. 3 2120 ms 15 ms 15 ms 10.0.3.200 <--- IP vom Shelly TRV
Mit NMAP und telnet reagiert der Shelly TRV auf port 80.
Firewall-Logs muss ich erst schauen.
-
Wieso sollte das überhaupt etwas mit DHCP zu tun haben? Die Shellies haben alle ihre IP abgefragt, erhalten, tragen sie mit stolz und sind darunter erreichbar ich erreiche sie nur nicht über VPN.
-
Am betroffenen Standort 1 sind 3 UniFi AP 6 Lite im Einsatz, wobei sowohl der funktionierende Shelly 2.5 als auch der nicht funktionierende Shelly Plus 1PM mit demselben Access Point verbunden sind. Unwahrscheinlich, dass hier das Problem liegt.
Die IP bekommen die Shellies über DHCP pseudostatisch zugewiesen. Wie gesagt, Ping funktioniert, Webinterface auch, solange ich im selben Netzwerk bin, daher schließe ich ein DHCP-Problem mal aus.
Von Standort 1 auf Standort 1 funktioniert alles ganz normal. Auch vom Client-VLAN ins IoT-VLAN ist kein Problem.
Von Standort 2 auf Standort 1 geht eben nur Ping, aber das Webinterface geht nicht auf.
Derzeit ist zu Testzwecken von Standort 2 auf Standort 1 ins IoT-Netz alles erlaubt. Port 80 ist also auch nicht blockiert. Das funktioniert ja auch offensichtlich, da der Shelly 2.5 ganz normal funktioniert.
Aber gut, die ursprüngliche Frage nach einer Firewall in den neuen Shellies ist geklärt, dann muss es wohl irgendwo an meinen VPN- oder Firewalleinstellungen liegen. Da muss ich wohl selber suchen.
-
Ich behaupte mal das ist so, das erklärt aber das Verhalten des Shellies nicht. Darum frage ich in einem Forum nach.
-
Mit falscher Subnetzmaske oder fehlerhaftem Routing würden weder Ping noch der Zugriff auf das Webinterface des alten Shellys funktionieren, oder sehe ich das falsch?
-
Sehr merkwürdig, dass das alte Webinterface am IP-Nachbarn des Shelly 2.5 ganz normal funktioniert. Ich sehe auch absolut keine Firewall-Regel, die das blockieren könnte.
Der einzige Unterschied zwischen lokalem und VPN-Zugriff ist die komplett andere IP-Range von 192.168.X.X im VPN-Netz im Gegensatz zu 10.0.1.X lokal.
-
Hi,
ich habe ein relativ komplexes Heimnetzwerk, in dem mehrere Häuser über VPN miteinander verbunden sind. An jedem Standort steht ein kleiner Server mit einer opnsense-Firewall als Router, die die VLANs und VPN-Verbindungen handeln.
An einem der Standorte habe ich nun einen Shelly Plus 1PM sowie einige Shelly TRVs verbaut. Alle Shellies und andere Smarthome-Geräte sind in ihrem eigenen VLAN und somit in ihrem eigenen Subnet mit eigener IP-Range.
Ausschließlich mit den Shellies mit dem neuen Webinterface, also Shelly Plus und Shelly TRV, habe ich aber das Problem, dass ich das Webinterface nur vor Ort erreiche. Von einem anderen Standort über VPN geht das nicht, ein simpler Ping wird aber beantwortet.
Bspw:
A) Standort 1 Shelly IoT-WLAN: 10.0.3.1/24
B) Standort 1 Client-WLAN: 10.0.1.1/24
C) Standort 2 Client-WLAN: 192.168.0.1/24
ping B -> A
ping C -> A
Shelly WebIF B -> A
Shelly WebIF C -> A
Ein alter Shelly 2.5 mit dem alten Webinterface im selben WLAN eine IP-Adresse daneben ist sowohl über Ping als auch Webinterface aus allen Netzen erreichbar.
Daher also meine Frage:
Haben die neuen Shellies soetwas wie eine Firewall implementiert, die IPs aus einem gänzlich anderen Subnet blockieren? Woran kann das sonst noch scheitern?
Beste Grüße
RockNLol
-
Alles klar, viele Dank. Dann werde ich wohl damit leben müssen.
-
Hi,
nach einem Feldtest mit 4 Shelly TRV's habe ich beschlossen, die Geräte im ganzen Haus zu verbauen. Am Black Friday habe ich zugeschlagen und 10 weitere Shelly TRVs bestellt. Diese sind nun da, sehen aber anders aus, als die, die ich schon habe. Die Farbe der beiden Buttons ist nun ein mMn. hässliches Grau und nicht mehr weiß. Das Grau passt nichteinmal zum silbernen Rahmen.
Sind alle neuen Shelly TRVs so, oder habe ich eine Charge erwischt, wo ihnen das Weiß ausgegangen ist?
-
Hi!
Ich hab einen Shelly 2.5 in einer Steckerleiste für meinen PC montiert. Steckdosen 1-6 hängen auf Relais 1, 7-12 auf Relais 2. Die erste Gruppe versorgt Verbraucher, die permanent Strom brauchen, die zweite Gruppe ist für Verbraucher, die ich nur brauche, wenn ich vor dem PC sitze. Ich nehme so bspw. meine Monitore vom Netz, wenn ich nicht am PC bin, mein PC kann aber weiter arbeiten/rendern/rechnen etc. Relais 1 ist eigentlich permanent an und wird nur zum Stromverbrauch messen verwendet.Mir ist es jetzt schon zwei mal passiert, dass der Shelly beide Relais einfach für eine Sekunde ausgeschaltet hat, was natürlich meinen PC zum Absturz gebracht hat. Die Temperatur ist laut MQTT zwischen 65 und 70°C, was ich schon recht hoch finde, temperature_status ist aber "Normal" und overtemperature = 0.
Kann ich irgendwie herausfinden, warum der Shelly das macht? Die Info wie man Relais 1 bedient ist nicht in openhab hinterlegt, mit dem ich Relais 2 steuere. Auch habe ich keine Regeln zum schalten programmiert, die einen Fehler haben könnten. Daher würde ich das mal ausschließen.
beste Grüße
RockNLol