VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
der Flood ist zuverlässig.. bei mir hat er 2x angeschlagen, beides waren echte Alarm-Meldungen..
Hast du ihn mal in eine kleine Schüssel mit Kranwasser gelegt und überprüft, wie lange er braucht um zu reagieren? Der piept ja auch, von daher sollte das relativ einfach zu prüfen sein..
Wie kann es denn sein, dass der Shelly trotz 96° noch ganz normal funktioniert? Hat Rojer eventuell einen anderen Schwellwert vergeben? ?
ich glaube nicht, dass die Homekit-Version eine Temperatur-Überwachung hat..
Heißt das entweder PC oder Händy?
Nein, das heißt wenn du den Shelly mit MQTT betreibst, dass dann die Cloud nicht genutzt werden kann.
Die Shelly-App funktioniert dann weiterhin, aber eben nur solange du im lokalen Netzwerk bist.. nicht von außerhalb..
Welche Heimatomatisierungslösung nutzt deu denn? ioBroker, OpenHAB und HomeAssistant können mit den Shellys auch über CoAp anstelle von MQTT reden..
CoAp und Cloud laufen parallel..
ja, dein Link zur 2.5er war richtig 
In der App gibt es ab Version 1.9 Favoriten, aber was mich wundert:
wenn du z.B. runter antippst, dann fähr der Shelly runter.. wenn du dann runter nochmal antippst, sollte er stoppen..
Klappt das nicht?
mqtt und Cloud gehen nicht gleichzeitig... entweder Cloud oder mqtt..
SparkyMaster
Kannst du das hier im ersten Beitrag mal korrigieren?
Die Login-Daten sind NICHT von der Cloud sondern von den Shellys, wenn diese über Passwort geschützt sind. Der Adapter arbeitet via CoAp/REST-API und braucht die Zugangsdaten, wenn das Webinterface (und die REST-API) per username/passwort geschützt wurde...
Ist beim Shelly etwas anders:
bei angeschlossenen Tastern muss der Shelly auf "Toggle-Switch stehen:
dann kann man ihn wie folgt steuern:
Button hoch: startet den Motor richting hoch, button hoch erneut drücken stoppt ihn dann wieder.
Gleiches gilt für "runter"..
Die Zeptrion-Taster scheinen eine Mischung aus Schalter/Taster zu sein, da sie ja laut deiner Beschreibung zwischen Short/Long-Press unterscheiden..
Im Modus "Momentary" arbeitet der Shelly so, dass der Motor fährt solange Strom über den SW-Eingang reinkommt, also eigentlich die richtige Einstellung für deine Schalter.
Aber (und ich denke da liegt vermutlich das Problem): deine Zeptrion-Schalter/Taster haben eine eigene Logik ähnlich dem Shelly und prüfen über den Stromverbrauch, ob der Motor sich noch bewegt und schalten ggf. selbstständig ab. Das können Sie aber nicht, weil sie nicht mehr direkt mit dem Motor verbunden sind..
Hab den SourceCode mal auf Github.com gestellt:
https://github.com/shelly-tools/ShellyMicroWeb
Beim 2.5er gibt es die Actions in den Relays, nicht direkt in der Startseite der Weboberfläche. Dafür musst du auf das Zahnrad hinter dem Channel-Namen (im Screenshot hinter Brunnen / Gartenbeleuchtung) klicken..
Der Wifi-Stack im Shelly kommt vom Espressif-SDK, also direkt vom Chiphersteller, und wird damit auch von sämtlichen Tuya, Sonoff und anderen ESP8266-basierten genutzt..
Die Arp-Proxy Funktion im Grandstream hat meines Wissens einen anderen Hintergrund, die wird für Proxy-Funktionen im VPN-Tunnel benötigt, um UDP-Pakete (Broadcast / Multicast) auch über VPN bereitstellen zu können.
Das Caching, was ich meinte, macht wohl der Shelly (mit der aktuellen Firmware) selbst..
Finde gerade den Beitrag auf Facebook von Dimitar nicht mehr..
In der neuen Firmware haben sie das wohl abgeschaltet, weil das bei einigen mehr Probleme als Nutzen brachte..
Bei meinen Shellys macht das keinen Unterschied, außer dass die Einträge im Log für "High Wifi Retries for Shellyxxxx" im Log wohl verschwinden, zumindest bei den Geräten die 1.9RC2 haben..
Funktionell läuft der Shelly1 damit genau wie vorher..
Kannst du mal einen Shelly1 auf Firmware 1.9RC2 Updaten? da ist das Arp-Caching Firmware-seitig abgeklemmt, kann sein das der Grandstream damit Probleme hat..
http://<ip-vom-shelly>/ota?url=http://repo.shelly.cloud/firmware/rc/SHSW-1.zip
ja, dann passt das eigentlich soweit.. im Log sollte etwas mehr stehen, wenn der Aufruf nicht von localhost sondern einem externen Gerät kommt..
Ich schreibe zusätzlich zum Datum die IP-Adresse und den teil am Ende der URL mit, also http://192.168.178.86/licht_an (ist mit der IP von meinem Laptop) erzeugt folgenden Log-Eintrag
2020/11/07 20:55:47 192.168.178.212 - licht_an (ist die IP vom Shelly1 aus dem Screenshot oben)
Wenn da von "Extern" (also einem Shelly) nichts ankommt, dann hast du entweder einen Tippfehler/Dreher in der Action-URL oder es ist die Windows-Firewall, die den Aufruf blockt..
Kannst ja mal probieren, die EXE in einer administrativen Eingabeaufforderung zu starten, spätestens dann sollte die Firewall-Frage eigentlich kommen..
Ich hab aktuell keine Windows-Kiste mehr, auf der ich das testen könnte..
Hast du mal den Grandstream als Fehler in Betracht gezogen?
den IP-Adressen nach zu urteilen hast du eine FritzBox.. mach doch da mal das WLAN an und verbinde ein oder mehrere Shellys damit.. Ich wette das geht einwandfrei..
Hab den Code in Go geschrieben, schubse es morgen mal auf Github.com
Unter Windows sollte, wenn ein lokaler Port geöffnet wird, eine Firewall-Abfrage kommen.. Kam da was?
package main
import (
"fmt"
"log"
"net/http"
"os"
"strings"
"github.com/gorilla/mux"
)
func main() {
r := mux.NewRouter()
r.HandleFunc("/", HomeHandler)
r.HandleFunc("/{key}", LogHandler)
http.Handle("/", r)
http.ListenAndServe(":8080", nil)
}
func HomeHandler(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
fmt.Fprintf(w, "Hello World")
}
func LogHandler(w http.ResponseWriter, r *http.Request) {
vars := mux.Vars(r)
req := getIPAddress(r)
w.WriteHeader(http.StatusOK)
fmt.Fprintf(w, "Key: %v\n", vars["key"])
f, err := os.OpenFile("webserver.log", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
if err != nil {
log.Fatalf("error opening file: %v", err)
}
defer f.Close()
log.SetOutput(f)
log.Printf("%s - %v\n", req, vars["key"])
}
func getIPAddress(r *http.Request) string {
ip := strings.SplitAfter(r.RemoteAddr, ":")
s := strings.TrimSuffix(ip[0], ":")
return s
}
Go ist wesentlich einfacher als Java und gefühlt Faktor 1000 schneller und ressourcenschonender , außerdem lässt sich der Code für fast jedes beliebige Betriebsystem/Architektur (Windows, MAC, Linux, Android...) kompilieren.
Testen kannst du ihn, wenn du auf http://localhost:8080 gehst..
Da sollte dann ein "Hello World" stehen
Hast du einen Windows-PC? dann kannst du das gerne mal testen..
Ist ein Mini-Webserver (einfache EXE, einfach entpacken und doppelklicken)
http://archive.shelly-faq.de/microweb.zip
der lauscht auf Port 8080 und schreibt requests in eine Datei webserver.log
im Shelly trägst du dann unter Actions einfach eine URL ein mit der IP-Adresse deines Windows PC:
http://<ip-vom-PC:8080/door_open
Danach kannst du im Log, wenn die Action ausgelöst wird einen entsprechenden Eintrag sehen..
Ich hab das gerade mal mit einem Shelly1 und "output Switched on" als Action getestet..
Pi und FritzBox sind direkt über LAN-Kabel verbunden oder noch Komponenten dazwischen (DLAN-Adapter, Switch)?
Welchen Kanal im 2.4Ghz nutzt die FRitzBox? (Empfehlen würde ich 1,6 oder 11)
welche Firmware-Version hat sie?
Laut Doc unterstützt der OpenWRT GRE tunneling, damit sollte das klappen denn damit können auch Multicast-Daten (mDNS, CoAp) getunnelt werden.
https://openwrt.org/docs/guide-use…rface_protocols
Das Problem wird sein, dass du das vermutlich nicht von remote einrichten kannst..
So...Hab die Fritte jetzt mal umgestellt ... TV-Optimierung ist aus also ... Keine Shellys im ioBroker bei Lan-Anschluss ...
Neu gestartet hattest du die aber auch, oder?
Ich habe auch gerade einen Shelly verbaut. Es kommt die gleiche Fehlermeldung beim Versuch das Gerät einem Raum hinzuzufügen. Gibt es schon Lösungsansätze?
Hat der Shelly aktuelle Firmware? Die Zuordnung zum Raum kommt ja eigentlich erst, wenn das "Device Include" in das eigenen Wifi bereits funktioniert hat..
im Notfall einfach mittels Webbrowser auf den Shelly gehen und ein Update ausführen..
Falls das mit der Shelly-Cloud nicht verlässlich liefe, käme evtl. noch eine Lokale Auswertung mit Syslog o.ä. in Betracht. Wie ist so etwas einfach zu realisieren? Evtl. Vorschlag mit Raspi4?
Die Cloud ist dafür nicht geeignet, weil das "Log" nur einen Tag abrufbar ist und auch nicht zu 100% zuverlässig arbeitet...
Es gibt mehrere Möglichkeiten für ein lokales Log, irgenein dauerhaft laufender Computer ist notwendig:
1) Logging via Webserver (Apache, NginX, IIS...): Im Door&Window2 einfach die Actions konfigurieren und auf den Webserver zeigen lassen.. da kannst du dann im AccessLog die entsprechenden Events sehen..
2) MQTT-Server installieren, dann im D&W2 das MQTT aktivieren, auch das lässt sich problemlos loggen..
3) Die CoAp-Nachrichten, die der Shelly bei jedem Event per Multicast schickt, loggen.
Ich nutze 1) relativ häufig um im Rahmen des QA-Testings die Funktionalität der Actions zu prüfen. Außerdem lässt es sich von den 3 Varianten am einfachsten realisieren.
