Beiträge von 87insane

    Ich habe keine Schalter mehr, überall nun Taster. Daher kann ich das so nicht mehr testen.

    Aber ich habe i4 mit Tür/Fensterkontakten. Da klappt es wie es soll.

    Ich habe auch keine 1PM mehr. Nur noch PLUS 1PM. Daher kann ich das auch nicht mal eben zusammen bauen. Da es aber solange her ist, denke ich einfach mal, wurde es behoben.

    Hast du da ein Problem? Du könntest es testen wie ich auch. Mqtt Explorer aufmachen und gleichzeitig mal testen. Nachstellen lässt sich das ja schnell.

    PS: wenn du Hilfe brauchst, einfach nochmal melden.

    Gruß,

    Kai

    Also mittlerweile gibt es aber lauffähige Templates. Einfach aktivieren und Spaß haben. Oder abtippen, wenn diese nicht gefallen.

    Porfus das sind die "alten" Shellys.

    Die neuen werden anders gesteuert.

    Beispiel anhand eines PLUS 1PM. Der sollte identisch sein, wie der Plus Plug S

    Code
    toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}  
    off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}  
    on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true}}  
    on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}  
    off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}  
    in_mode:toggle,flip,detached {fhem("sleep 0.2; get $NAME in_mode"); my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') eq 'flip' ? 'detached':'flip'; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}  
    x_status_update:noArg $DEVICETOPIC/command status_update  
    x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Update","params": {"stage":"stable"}}  
    x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Reboot"}  
    x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}

    In dem Beispiel muss das attr devicetopic den Namen des Shellys beinhalten.

    devicetopic shellyplus1pm-441793953c10

    Der "größere" weg wäre:

    - Eigenen Webserver

    - Cloud/Shelly Adressen sperren

    - OTA Updates via Rest oder mqtt über den o.g. Webserver anstoßen

    - oder die DNS von Shelly auf deinen Webserver umbiegen.

    Du müsstest damit allerdings selber die Updates auf deinen Webserver ablegen oder das durch ein kleines Skript automatisieren.

    Also das ist schon sehr wage und man flasht für gewöhnlich .bin Dateien. Daher würde ich in jedem Fall einen dump ziehen.

    Wie gesagt, gibt es sonst erstmal kein zurück. Ich bekomme immer wieder Anfragen zu dem Thema und finde die Umstellung der Haltung im Support auch schade. Es wird natürlich auf Garantie usw geschoben. Ich selber nutze Tasmota auch gern, allerdings eher bei sonoff und co. Aber jeder mag es anders.

    Hey und guten Morgen.

    Es kann auch einfach sein das du die beiden Daten Kabel einfach tauschen muss. Das zu testen ist nicht schwer und kann nichts zerstören.

    An der Stelle eine kleine Warnung an alle Shelly PLUS Benutzer:

    Es gibt keinen Weg zurück auf die originale Shelly Firmware ohne vorher einen dump der Firmware auf dem Gerät zu machen. Shelly selber gibt die original Firmware nicht raus. Dies machen sie nur bei den gen1 Geräten.

    Info 2: denk daran es befindet sich ein ESP32 in dem Shelly. (richtige Tasmota Version wählen)

    Gruß,

    Kai

    87insane
    2. August 2019 um 17:46

    Hey ich kenne mich mit IP-Symccon nicht aus aber innerhalb von FHEM hatte ich das Problem auch. Vermutlich wird es bei dir ähnlich sein...

    Die GEN1 shellys haben diese Info über andere mqtt Zweige gesendet. Aktuell wird diese Info über den Events/rpc Zweig gesendet. Da musste ich auch erstmal suchen. Wenn du dir das ganze mal mit einem mqtt Explorer ansiehst, wirst du sehen was ich meine. Normal nutze ich den RPC Zweig sehr ungern aber ohne ihn siehst du das sonst nicht mehr.

    Wenn ich irgendwie weitere Infos oder Hilfe leisten kann, meld dich gern nochmal.

    Gruß,

    Kai

    Hey,

    ich würde auf den FHEM internen mqtt2 Server umsteigen und dann einfach das attrTemplate nutzen. Aus denen kannst du dir auch einfach die setList usw raus kopieren. Das würde dann natürlich auch mit mosquito gehen.

    Die aktuellen PLUS Templates sind in meinen Augen eher semi, habe aber bereits im fhem Forum Verbesserungen abgegeben. Sollten also bald auch offiziell zur Verfügung stehen.

    An sich hat sich bei der PLUS Serie einigen geändert im mqtt Bereich. In meinen Augen leider nicht verbessert. Wenn du da noch weiter Hilfe brauchst, meld dich einfach bei mir oder markier mich oder so. Hab selber grad das ganze Haus auf die PLUS Serie umgebaut und stecke in den FHEM Shelly Templates eh mit drin.

    Gruß,

    Kai

    Hey zusammen,

    ich habe zur Zeit ca 70 Shellys im Einsatz. Einer, der eines der Rollos fährt, resettet sich seit neustem von alleine. Er fährt genau einmal das Rollo hoch oder runter und das danach auf Werkseinstellungen. Ich kann mir das nicht erklären. Die Firmware ist die aktuelle und ich habe auch probiert ihn manuell zurück zu setzen. Hat leider nicht geholfen.

    Für mich ist das Verhalten sehr merkwürdig. Ich habe auch mal den factory reset via taster deaktiviert. Half auch nicht.

    Was habe ich eingestellt?

    - Shelly ins WLAN eingebunden

    Rollo kalibrieren geklickt und nach der ersten Fahrt ist er dann wieder weg.

    Hat hier noch jemand eine Idee? Sonst sende ich den ein.

    Gruß,

    Kai

    Nur kurz da Handy:

    FHEM mit eingebauten MQTT2 Server und den vorhandenen Templates ist schon echt gut geworden. Früher war war es definitiv auch mehr aufwand. Ist allerdings nicht mehr so. Ich sehe in fhem den vorteil die Geräte bis ins letzte (wenn geünscht) anpassen zu können.

    An sich läuft das bei einem shelly aber so ab:

    Im shelly mqtt aktivieren, Autocreate in fhem aktivieren. Dann erscheint nach wenigen Sekunden das neue Gerät. Man wählt nun noch das Template aus und fertig ist der Shelly.

    Ich hab hier im Forum einen FAQ Beitrag innerhalb der Rubrik fhem erstellt. Da ist es auch bebildert.

    Am Ende ist das System Geschmackssache.

    Gruß,

    Kai

    Hey zusammen,

    das mqtt innerhalb von shellys sich immer mal ändert bzw die topic Pfade ist mir auch ein Dorn im Auge. Allerdings ist das der Entwicklung bedingt. An sich kannst du jede SW verwenden um zum gewünschten Ziel zu kommen. Du kannst innerhalb der topics im shelly auch direkt gewünschte Namen angeben um dir die aliase zu sparen.

    Ich selber nutze z.B. FHEM zuhause. Meine persönliche Meinung ist, es gibt kein anderes System, welches innerhalb von mqtt so gut und verständlich arbeitet. Die "anderen" machen das zwar über ihre adapter auch mehr oder weniger sind eben nur "schöner" ... Die Frage ist in meinen Augen dein letzliches Ziel. Einzig das bestimmt das System welches du nutzen solltest. Arbeit hast du am ende mit allen :S

    Gruß,

    Kai

    Hey zusammen.

    Am Mac geht das eigentlich genauso wie an einem Windoof Rechner.

    Vermutlich hast du die Verbindung zum shelly nicht hergestellt. Aber das ist nur geraten. An sich läuft das gleich ab. Solltest du Probleme haben mit den anderen, einfach melden.

    Aktuell sanieren wir zwar ein Haus (nicht böse sein wenn ich 2 tage brauche zum antworten) aber das geht schon. Ich selber steh vor einem Riesen Projekt aber zumindest in der Theorie ist das abgeschlossen.

    Gruß,

    Kai

    Hey stefangeiger

    es geht hier um OTA (over the air) flashen. Leider verirren sich hier einige Varianten. Via TTL flashen ist natürlich immer ein weg und der ist auch immer machbar. Allerdings ist es für die meisten interessant, einen shelly ohne Kabel zu flashen. Das geht eben einfacher oder komplizierter, oder garnicht mehr. Je nach Status des Shelly.

    Grundsätzlich sind .bin Dateien und ESP natürlich am einfachsten. Aber nicht jeder hat löt Fähigkeiten oder jumperkabel und und und. Die OTA Varianten sind gerade innerhalb von tasmota sehr groß und auch sauber.

    Gruß,

    Kai

    Die Lösung über Vatiante B) würde mich interessieren. Das Shelly Plug (S) ist jetzt mit Tasmota geflasht.

    Achim

    Moin Achim, die Lösung gebe ich hier nicht raus. Ich bin mit der Haltung des betreibers nicht zu 100% einverstanden. Daher kann ich das gern machen (unentgeltlich natürlich) aber gebe das hier nicht raus.

    Der Flash der recovery bin Datei muss laufen. Wenn der PlugS im richtigen Modus ist, ist der ESP beschreibbar. Das ist bei allen möglichen Geräten mit ESP gleich. Egal ob es ein sonoff oder shelly ist. Meist muss vor bestromung irgendein Button gedrückt und gehalten werden oder gpio0 gegen minus gebrückt werden. Gerne können wir dazu auch nochmal alles durch gehen. An sich ist der Vorgang innerhalb von 10min gemacht (mit auseinander/zusammen bauen).

    Gruß,

    Kai