Shelly2 IP Schaltaktor

Begonnen von Prof. Dr. Peter Henning, 08 September 2018, 16:31:30

Vorheriges Thema - Nächstes Thema

sledge

Zitat von: Prof. Dr. Peter Henning am 09 November 2018, 15:56:07
Seriennummer = ID des Shelly-Devices, 6-Stellig. Ich denke, die ersten 4 Stellen reichen.

LG

pah

Ok, also die letzten 6 Stellen der MAC. Fein.

Hier meine beiden:

Shelly 2 (ohne fiepen):  32B83B
Shelly 2 (mit fiepen): 32BBDE

VG Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

sledge

Für alle, die ggf nicht auf Facebook im Shelly-Supportforum unterwegs sind:

1. Shelly mit Fiepen werden anstandslos umgetauscht - wie schon dkreutz hier schrieb. Den Fehler hat man identifiziert, soll nicht mehr vorkommen. Löbliche Praxis in jedem Fall
2. Mir wurde erläutert, dass das Fiepen nach einzwei Wochen "verschwände". Das Risiko gehe ich jetzt mal ein.

Testweise habe ich meinen akustisch wahrnehmbaren Shelly im "freien Aufbau" in einer Unterputzdose versteckt und in einen ungefähr passenden Pappkarton gelegt.

Resultat: Keine Geräusche mehr ab 0,5m Abstand. Somit werde ich das Teil in jedem Fall in der Garage verwenden können. Und bis der Elektriker kommt, ist noch ein bisschen ;-) Vielleicht ist er bis dahin ja sogar ganz ruhig.

VG Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

I bims Alice im WLan

Ich bitte vielmals um Entschuldigung dass ich mich an der Diskussion hier im Forum beteiligt habe und versucht habe meine Erfahrungen mit gerade so einer Markenzeitschaltuhr einfach nur mitzuteilen und zu posten. Wirklich sehr toller Umgangston hier. Sollte sich mein Beitrag wie ein Eintrag eines konkurrierenden Herstellers lesen dann müsste sich jetzt aber ein anderer User ganz ganz schnell an die Nase fassen und aufhören den Shelly hier wie Falschgeld anzupreisen und versuchen Diesem einen Nonplusultrastatus zu verpassen. So gut sind die Teile auch nun wieder nicht. Nach dem Vorfall mit der Markenschalter hab ich diese vier Schalter vor etwa 2 Jahren bewusst gegen die RZA 200 von ELV ausgetauscht da dort die Relais ausgangsseitig so verschaltet sind dass es nie vorkommen kann das beide Ausgänge gleichzeitig an Netzspannung liegen. Da diese Geräte aber nicht smartfähig sind suche ich gerade eine Alternative. Da aber der Shelly_2 für mich im jetzigen Aufbau in Punkto Sicherheit ein Rückschritt wäre habe ich geschrieben dass ich den Shelly und das Modul im jetzigen Zustand so nicht gebrauchen kann. Ich weiß allerdings aus einem Email-Verkehr heraus auch dass ein anderer User im Moment dran ist dieses Hardwareproblem zu lösen. Denn dann sieht das wieder ganz anders aus und deswegen auch die Wiederholung der angehängten Frage in Schrägschrift aus der Antwort*336 die damals nicht beantwortet wurde und immer noch offen im Raum steht. Denn ich möchte schon gerne wissen wo meine Rollladen dann stehen. Denn nur für die Endpunkte brauche ich es dann nicht smart zu machen und kann es lassen wie es ist oder muss eine andere Alternative suchen.

PS: Aber es gibt hier schon tolle Spassvögel die sich bezüglich Schaltverhalten von Modulen anmaßen eine Entwarnung geben zu können weil sie denken sie hätten das Teil nun 375mal ohne Probleme und Fehlverhalten hin und her geschaltet und könnten gewährleisten dass das nun bei allen anderen Modulen genauso ist. Mein Markenschalter hat mindesten genauso oft fehlerfrei geschaltet aber einmal dann doch nicht. Und es ist noch gar nicht so lange her da hatte ich ein Relais das hat 10 bis 15 mal sauber geschaltet aber beim 11 oder 16 mal bleib das Licht halt an. Erst ein kleiner Schlag mit der Schraubendreher auf das Relais brachte dies dann wieder zu Abfallen. Das ist das was ich meinte. Hat mit der Schalthäufigkeit rein überhaupt nichts zu tun.

Netter Gruß

I bims

Prof. Dr. Peter Henning

Nochmal zum Thema Passwort, denn ich habe oben nicht geschrieben, wie der Aufruf der REST-Befehle geschehen muss. Ganz einfach
http://<username>:<passwort>@<ip-adresse>/...

Wer das also sofort einsetzen will, muss einfach im Modul überall in den Aufrufen das http:// durch http://<username>:<passwort>@ ersetzen. Setzt aber voraus, dass alle eingesetzten Shellys dieselbe Kombination haben. Ansonsten: irgendwann werde ich das vielleicht ins Modul einbauen, als Attribut natürlich. Nicht vor Mitte Dezember.

LG

pah

sledge

So,

habe heute meine beiden Shelly_2 in Betrieb genommen - das Fiepen ist nicht mehr wahrnehmbar - Austausch also für mich nicht erforderlich - gut!

Ein Hinweis: Die Auswahl pct100 in der Web-Oberfläche funktioniert (bei mir) nicht - es steht dann dort "open:closed" - kann jedoch keinen der Werte auswählen.

Ein einfaches attr myshelly pct100 closed hat es dann für mich geregelt.

Trivialpatch anbei:

--- 36_Shelly.pm.orig   2018-11-10 15:32:04.490449926 +0100
+++ 36_Shelly.pm        2018-11-10 15:33:00.828696983 +0100
@@ -100,7 +100,7 @@
   #$hash->{NotifyFn} = "Shelly_Notify";
   #$hash->{InitFn}   = "Shelly_Init";

-  $hash->{AttrList}= "verbose model:".join(",",(keys %shelly_models))." mode:relay,roller defchannel maxtime maxpower interval pct100:open:closed ".
+  $hash->{AttrList}= "verbose model:".join(",",(keys %shelly_models))." mode:relay,roller defchannel maxtime maxpower interval pct100:open,closed ".
                      $readingFnAttributes;
}


VG Tom

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Prof. Dr. Peter Henning

Ah, das ist ein Tippfehler, der mir bisher nicht aufgefallen ist, weil ich das Attribut nicht nutze. Wird behoben und eingecheckt.

LG

pah

sledge

Zitat von: Prof. Dr. Peter Henning am 10 November 2018, 17:42:27
Ah, das ist ein Tippfehler, der mir bisher nicht aufgefallen ist, weil ich das Attribut nicht nutze. Wird behoben und eingecheckt.

LG

pah

Von dem Tippfehler war ich ausgegangen :-)

Etwas anderes ist mir noch aufgefallen: Wenn ich via set myshelly pct 30 auf eine bestimmte Höhe fahre, funktioniert das bestens. Allerdings steht danach im Reading "pct" entweder 0 oder 100, aber nicht 30.

Könnte es daran liegen, dass ich das attr "pct100" verwende?

Ich hatte Dich in einem der früheren Posts so verstanden, dass Dein Modul sofern möglich die aktuelle Position speichert.

Ebenso: Bei get myshelly config swap erwartete ich die Ausgabe von true oder false, je nach Einstellung des Shelly. Es kommt jedoch die Fehlermeldung Error: wrong number of parameters

Layer 8 Problem?

Vg Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Prof. Dr. Peter Henning

Das mit dem pct kann ich nicht bestätigen - vielleicht ein Artefakt des o.a. Tippfehlers. Mit den beiden möglichen Werten für das Attribut pct100 "open" oder "closed" funktioniert das korrekt, der Wert von pct ist hinterher 30.


Was sollte denn get config swap bewirken ? Da es kein Reading dazu gibt, wird auch nichts angezeigt. Das Einzige, was man im Modul machen kann ist ein set config swap true oder set config swap false.

LG

pah

sledge

Ad pct)

Folgende Startposition:

myshelly via "set myshelly closed" komplett geschlossen - klappt einwandfrei (myshelly=EZ.EG.RO in diesem Beispiel)

Hier das entsprechende "list myshelly" nach abschluss der Fahrt - interval habe ich aktuell auf 5 sec. eingestellt.
Internals:
   CFGFN     
   DEF        192.168.0.59
   DURATION   0
   INTERVAL   5
   MOVING     0
   NAME       EZ.EG.RO
   NR         407
   STATE      OK
   TCPIP      192.168.0.59:80
   TYPE       Shelly
   READINGS:
     2018-11-10 17:59:24   cloud           disabled
     2018-11-10 17:59:24   config          mode=roller=
     2018-11-06 17:51:13   firmware        v1.3.5
     2018-11-10 18:44:52   last_dir        down
     2018-11-10 17:59:14   network         connected
     2018-11-10 18:44:54   pct             0
     2018-11-10 18:45:35   position        stop
     2018-11-10 18:45:05   power           0
     2018-11-10 18:44:52   state           OK
     2018-11-10 18:44:52   stop_reason     normal
Attributes:
   alias      Esszimmer
   interval   5
   maxtime    40
   mode       roller
   model      shelly2
   room       technik->rollladen


Jetzt ein "set myshelly pct 30" - der Rollladen fährt auf die korrekte Postion - und nach 10 Sekunden nochmal ein list device:

Internals:
   CFGFN     
   CHANGED   
   DEF        192.168.0.59
   DURATION   0
   INTERVAL   5
   MOVING     0
   NAME       EZ.EG.RO
   NR         407
   STATE      OK
   TCPIP      192.168.0.59:80
   TYPE       Shelly
   READINGS:
     2018-11-10 17:59:24   cloud           disabled
     2018-11-10 17:59:24   config          mode=roller=
     2018-11-06 17:51:13   firmware        v1.3.5
     2018-11-10 18:48:13   last_dir        up
     2018-11-10 17:59:14   network         connected
     2018-11-10 18:48:13   pct             100
     2018-11-10 18:48:28   position        stop
     2018-11-10 18:48:28   power           0
     2018-11-10 18:48:13   state           OK
     2018-11-10 18:48:13   stop_reason     normal
Attributes:
   alias      Esszimmer
   interval   5
   maxtime    40
   mode       roller
   model      shelly2
   room       technik->rollladen


Das Reading pct zeigt bei mir nach Abschluss der Fahrt immer nur Werte 0 / 100 - aber nicht die aktuelle Position. Hierzu auch die Beobachtung: Wenn ich von komplett geschlossener Rolllade 45% fahre, taucht in dem Reading zuerst "kurz" 45 auf, wird dann aber mit dem nächsten Update mit 100 überschrieben.

Ad "get config")

Meine Anmerkung bezog sich auf folgenden Text, der bei "get registers" angezeigt wird: Set/Get these registers by calling set/get EZ.EG.RO config <registername> [<channel>] <value>

Dachte daher, man könnte gezielt einzelne Register auch auslesen, nicht nur setzen.

VG Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Prof. Dr. Peter Henning

Das liegt hieran:
Zitatinterval habe ich aktuell auf 5 sec. eingestellt.

Das Modul fordert einen neuen Statu san, währen sich der Rollladen noch bewegt, das führt zu Chaos.

Es macht auch keinen Sinn, alle 5 Sekunden abzufragen - bei mir steht das auf 120 Sekunden. Minimum sollte die Rollladenlaufzeit sein.

LG

pah

sledge

Zitat von: Prof. Dr. Peter Henning am 10 November 2018, 19:11:30

Es macht auch keinen Sinn, alle 5 Sekunden abzufragen - bei mir steht das auf 120 Sekunden. Minimum sollte die Rollladenlaufzeit sein.

LG

pah

Das kurz bemessene Abfrage-Interval war aus Testgründen so gewählt. Ggf ist dieser Umstand einen Hinweis in der Commandref wert?

Aber jetzt passt es bei mir - vielen Dank für die Hilfe und das Modul.

VG Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Prof. Dr. Peter Henning

#476
Da wir derzeit nur noch 9 Löcher spielen, hatte ich gestern etwas Zeit. Anbei eine neue Version 1.5beta1 des Moduls, bei der man einen Benutzernamen als Attribut "shellyuser" setzen kann, und danach per  Set-Befehl ein Passwort vergeben kann. Da es sich um ein sicherheitsrelevantes feature handelt: Bitte erst einmal testen.

Darüber hinaus habe ich inzwischen Kontakt zu den Shelly-Entwicklern. Ich gebe mal kommentarlos die klare Aussage von Dimitar Dimitrov zum Bild aus diesem Post hier wieder: https://forum.fhem.de/index.php/topic,90950.msg850217.html#msg850217

ZitatThe usual mistake - wrong wiring - the user connect Neutral to SW inputs. There is 230V. If you connect neutral - relay is burn immediately.

Macht daraus, was Ihr wollt - ich sehe jedenfalls keinen Grund, irgendwelche Sicherheitsbedenken zu pflegen.

LG

pah

Papa Romeo

#477
Betrifft aber nur den Shelly2, oder ?

Edit:

Ist klar, dass die sich irgendwie herausreden wollen.

Würde dem dann auch zustimmen, wenn ich denn eine Änderung vorgenommen hätte.

Aber hat ja über längere Zeit ohne Probleme funktioniert und mit einem N sollte man eigentlich grundsätzlich nicht schalten.

Einen Schaltplan werden die wohl nicht rausrücken. Denn diese Potentialverhältnisse würden mich schon irgendwie interessieren,  zumal es bei meinem Shelly1 mit dem L als auch mit dem N funktioniert (gerade nochmal getestet).

Ich habe allerdings den Sketch des Malmberg-Clones drauf, wobei die Software aber keine Rolle spielt.

https://forum.fhem.de/index.php/topic,85029.msg831518.html#msg831518


LG

Papa Romeo
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

Papa Romeo

...und eventuell doch verschiedene Hersteller...

links der alte Shelly, rechts der Neue als Ersatz gelieferte.

Beim Neuen fehlt der komplette Bestückungs-Aufdruck auf der Löt- sowie auf der Bestückungsseite.
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

gerhardg

oh, scheinbar hat man die alten Platinen von Olimex.