Support-Thread Modul 36_Shelly.pm

[bene80]

Hallo Bernhard,

mein letztes Update ist schon ewig her, darum hab ich nicht mitbekommen dass sich das geändert hat.
Ja sonst funktioniert alles wunderbar. Ok wenn der Slider aus dem Modul genommen wurde erklärt es
das warum jetzt nur mehr pct dort steht. Wenn der wieder rein kommt wäre das natürlich super, dann brauch ich vorerst nicts ändern.
Vielen Dank für deine Antwort

Schöne Grüße
Bernhard

[Sommerfeld]

Hallo Bernhard,
mit dem Shelly uni läuft alles Bestens
und die Spannung wird jetzt auch angezeigt.
Vielen Dank für deine Arbeit.
Viele Grüße Armin

[RalfRog]

War auf dem Testsystem mit einem SpielVersuch beschäftigt ein laufendes Buster auf Bullseye upzugraden... der Kernel bleibt bei 5.10.103 wie buster 

So hab die alte SD wieder drin und nun zunächst einen Plug, PlusPlug, 1, 1PM und 3EM neu eingebunden. Sieht soweit gut aus   

• Der Shelly1 ist nicht ganz sauber. Modell wird nicht gesetzt und daher ist er nicht komplett (Relay etc.)
  -> Nachdem es manuell gesetzt wurde kommt das Reading relay.
  -> On/Off klappt und ICON wird angezeigt
  -> Es werden zu viele Attribute angezeigt (metertype, webhook etc.).
  -> Attribut showinputs fehlt, Rednigs kommen auch nicht nach Betätigung des Inputs (SW)
  ==> Zweiter Versuch den 1er einzubinden lief korrekt ab und er sah gut aus inkl. "showinputs" 
  
  
• "showinputs" ist am 1PM da und nichts Auffälliges
  
  
•   die Readings am 3EM sehen fast vollständig aus
  -> Ist powerTTL gerechnet oder der Wert aus "total_power" vom Shelly selber?
  -> energy_returned_0 und returnedTTL passen namentlich nicht ganz zusammen.
  -> Anzahl der Nachkommstellen bei den gerechneten reactivepower & apparentpower könnte weniger sein
    (Ich glaube es gibt 2Gen-Devices die liefern apparentpower. Da wäre die Frage nach Erkennbarkeit gerechneter zu ausgelesenen Werten)
  
  
• Plug: nichts Auffälliges
  
  
• PlusPlug: Webhooks noch nicht probiert, Anzeige im Webinterface noch "OK" statt "Lampen"-ICON
  

Habe blöderweise nicht mehr so ganz im Kopf wie das alles im Vorgänger aussah 

Gruß Ralf

[Starkstrombastler]

Hallo Ralf,

bei mir laufen mehrere Shelly1 ohne Probleme mit der Testversion. Ich schlage daher vor, das Verhalten weiter zu beobachten.

Zum Shelly3EM:

Ist powerTTL gerechnet oder der Wert aus "total_power" vom Shelly selber?

Im Moment ist powerTTL die Addition der Einzelleistungen.
In der nächsten Version wird total_power vom Shelly gelesen und im Reading powerTTL abgelegt. Der aus den Einzelwerten berechnete Wert wird dann in powerTTLc abgelegt. Wenn beide Werte immer übereinstimmen, kann in einer späteren Version auf die Berechnung verzichtet werden.

energy_returned_0 und returnedTTL passen namentlich nicht ganz zusammen.

Damit das passt, wird das Reading auf energy_returned_TTL geändert.

Anzahl der Nachkommstellen bei den gerechneten reactivepower & apparentpower könnte weniger sein

So ist das, wenn man das Device nicht in der Testumgebung zur Verfügung hat... Werte werden auf eine Kommastelle gerundet.
Wenn die Berechung stimmt, muss man das eigentlich nicht separat ausweisen. Das gilt natürlich auch für die Ausgangswerte. Mich machen bspw. die Leistungsfaktoren PF bei meinem ShellyPro3EM stutzig. Die liegen oft zwischen 0.6 und 0.7. Wenn das nicht valide ist, taugt eine darauf aufbauende Rechnung natürlich auch nichts.

PlusPlug: Webhooks noch nicht probiert, Anzeige im Webinterface noch "OK" statt "Lampen"-ICON

Für einkanalige Devices PlusPlug, Plus1 und Pro1 wird der 'state' im Modul entsprechend geändert.

Gruß
Bernhard

[RalfRog]

Wenn beide Werte immer übereinstimmen, kann in einer späteren Version auf die Berechnung verzichtet werden.

Wenn ich "händisch" schon mal die Summe kontrolliert habe, hat es bisher gepasst.

Wenn die Berechung stimmt, muss man das eigentlich nicht separat ausweisen. Das gilt natürlich auch für die Ausgangswerte. Mich machen bspw. die Leistungsfaktoren PF bei meinem ShellyPro3EM stutzig. Die liegen oft zwischen 0.6 und 0.7. Wenn das nicht valide ist, taugt eine darauf aufbauende Rechnung natürlich auch nichts.

Wenn ich "starke" ohmsche Lasten auf einer Phase hatte war ich immer nahe bei 1.
Mir fehlt allerdings Erfahrung wo man mit den modernen haushaltsüblichen Verbrauchern so landet (LED-Licht, Schaltnetzteile, Induktionsherd etc.) und wie zuverlässig die verbauten Mess-IC den PF erfasssen können.

Gruß Ralf

[curt]

Das Shelly Modul ist von der Anwendung her einfacher als MQTT und eignet sich daher insbesondere für FHEM-Einsteiger.

Ist ja cool, da denkt einer mal an mich...  und ein fröhliches Hallo allerseits!

Ich erzähle und frage einfach mal, ja?
Es geht um meine Rolläden. Die sollen hoch und runter und Status wäre nett. Hier lagen ein 2.5 und ein 2PM für Test rum, es fehlte das Entscheidende: Einer, der das einbaut.

Code Auswählen Erweitern

type "SHSW-25"
fw "20191217-074901/1047-long-id-for-shelly-devices@ab2bdce7"
----
id "shellyplus2pm-b8d61a85ff88"
model "SNSW-102P16EU"
gen 2
fw_id "20220527-091739/0.10.2-beta4-gecc3a61"
ver "0.10.2-beta4"
app "Plus2PM"

Nun habe ich endlich einen Elektromeister gefunden, der das mehr oder minder freiwillig will und zudem auch schon allgemein Erfahrungen mit Shelly hat - der hat heute beide eingebaut. Ja, inzwischen habe ich verstanden, dass ich den 2.5 als veraltet wegtun werde: Alle Rolläden werden künftig Plus2PM erhalten, das ist klar.
Die Integration war etwas hakelig, ich musste euch ja erst finden. Nun habe ich die 36_Shelly aus dem Beitrag #429 und beide Shelly sind integriert und ich kann beide Rolläden schon mal hoch und runterfahren - mehr brauche ich eigentlich nicht.

Frage: Ist eine Temperatur von um die 70°C eigentlich normal oder tendiere ich dazu, die Hütte abzubrennen?

Frage/Bitte bzgl. Plus2PM gen2: Könnt ihr mir bitte freundlicherweise zeigen, wie ihr das in FHEM integiert habt? Also mit devState-Icon und Knöpfen und event-on-* und was man da so macht. Also das wäre sehr schön, sehr hilfreich.

Darf ich bitte noch um Ratschläge zu weiteren künftigen Shelly bitten? Ich mach einfach mal, ja?

Lichtschalter, bisher Kippschalter (LED, Nullleiter wohl vorhanden): Welchen Shelly nehmen?

Lichtschalter, bisher Relais (LED, Nullleiter wohl vorhanden): Welchen Shelly nehmen?

Steckdosen, mit Messung: Welchen Shelly nehmen?

Ganz wichtig: Ich danke euch für eure tolle Arbeit!

[Starkstrombastler]

Hallo Curt,

willkommen in dieser Runde.

Ist eine Temperatur von um die 70°C eigentlich normal

Das ist die Prozessortemperatur. Die Gehäuse-Aussentemperatur ist (hoffentlich) niedriger. Ein ShellyPlus2PM, der bei mir auf dem Schreibtisch liegt hat eine interne Temperatur von 50°C.

Plus2PM gen2: Könnt ihr mir bitte freundlicherweise zeigen, wie ihr das in FHEM integiert habt?

Warte noch ein paar Tage, dann kommt ein Update der Testversion. Diese enthält für den Roller-Mode des ShellyPlus2PM vordefinierte Werte für die Attribute devStateIcon und cmdIcon.
Und vielleicht hat der eine oder andere noch spannende Code-Snippets, die er hier gerne verlinken kann.

Darf ich bitte noch um Ratschläge zu weiteren künftigen Shelly bitten?

Von einem Shelly-Verkäufer würden hier jetzt bestimmt ganz viele Vorschläge kommen. Ich schlage aber vor, zunächst einmal die grundsätzliche Frage zu durchleuchten: Wie ist die Ausgangslage und was soll erreicht werden?

Und weil wir hier hauptsächlich über die Integration der Shellies in Fhem mit dem Shelly-Modul sprechen, gibt es im Shelly Support Forum sicherlich auch viele Anregungen.

Gruß
Bernhard

[curt]

willkommen in dieser Runde.

Hallo Bernhard, danke für die Aufnahme und freundliche Antwort.

Ist eine Temperatur von um die 70°C eigentlich normal

Das ist die Prozessortemperatur. Die Gehäuse-Aussentemperatur ist (hoffentlich) niedriger. Ein ShellyPlus2PM, der bei mir auf dem Schreibtisch liegt hat eine interne Temperatur von 50°C.

Die jetzt bei mir verbauten zwei ShellyPlus2PM sind hintereinander (!) in Rigips + starke Isolierung eines Fertigteils-Niedrigenergiehauses der ersten Generation verbaut. Dort pendelt sich die interne Temperatur nun bei ca. 67°C ein.

Plus2PM gen2: Könnt ihr mir bitte freundlicherweise zeigen, wie ihr das in FHEM integiert habt?

Warte noch ein paar Tage, dann kommt ein Update der Testversion. Diese enthält für den Roller-Mode des ShellyPlus2PM vordefinierte Werte für die Attribute devStateIcon und cmdIcon.

Oh, das klingt ja wie Weihnachten, ich freue mich.

Und vielleicht hat der eine oder andere noch spannende Code-Snippets, die er hier gerne verlinken kann.

Ich habe vier Velux-Schrägdachfenster mit Rolläden (sowie Öffnung). Woher die dortigen Werte kommen (Modul oder von mir aus dem Forum abgeschrieben) kann ich nicht mehr sagen. Aber ich kann sie Dir gern zeigen. Da das andere vermutlich nicht so brennend interessiert, würde ich das alles in Anlagen packen, vmtl. sogar nachträglich in diesem Beitrag. (Erledigt)

Ganz unabhängig davon interessiert mich die Einbindung ShellyPlus2PM/Roller in die Nutzeroberfläche FTUI3, also falls das jemand hat. (Slider ist für mich gar nicht mal zwingend; on/off und Status wäre es.)

Danke zudem für den netten offtopic-Zaunpfahl, das wusste ich nicht. Ich werde dort nachfragen.

P.S:
Möglicherweise ist gleiche Firmware sinnvoll (oder umgekehrt wird von Firmwareupdates abgeraten). Bei mir steht jedenfalls derzeit im Reading "firmware"

Code Auswählen Erweitern

v0.10.2-beta4(update possible to latest stable v0.14.1)
PP.S:
Etwas schwer zu erkennen, es sind zwei Anhänge, der eigentlich ggf. interessante ist die Textdatei.

Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.

[Starkstrombastler]

Hallo Curt,

mit Firmwareupdates der Shellies habe ich bisher keine schlechten Erfahrungen gemacht. Ich habe nur von einem Fall gehört, wo sich ein Nutzer über verkürzte Speicherzeiten von Zählerdaten (Shelly3EM) in der Cloud beschwert. Für FHEM-Nutzer sollte dies aber gar kein Thema sein, da wir mit FHEM unsere eigenen Daten loggen und speichern.
Es ist vielmehr so, dass das FHEM-Modul auf der aktuellen Firmware aufsetzt. Es gibt kein Versionsmanagement, welches sicherstellt, dass das Modul mit älteren Firmwareständen zuverlässig funktioniert.
Wenn du, warum auch immer, ein Update rückgängig machen willst, bietet das Shelly-Support-Forum alle Firmwareversionen zum Download an.

Die von dir vorgestellten Device-Definitionen zeigen, dass du eine funktionierende Lösung für deine Rollos hast. Glückwunsch!
Ich dachte aber eher an Code-Snippets bzgl. einer weitergehenden Integration von Shelly-Devices.
Und noch ein Hinweis: für die Einbindung von Code hier im Forum bitte den Code-Tag der Symbolleiste nutzen.

Gruß
Bernhard

[curt]

Die von dir vorgestellten Device-Definitionen zeigen, dass du eine funktionierende Lösung für deine Rollos hast. Glückwunsch!

Leider bin ich nicht in der Lage, das auf Plus2PM anzuwenden, da ist mein Problem.

Shelly-Update verstanden und umgesetzt.

[Starkstrombastler]

Hallo Shelly-User,
hier ist wieder ein Update:  

Mit diesem Update werden die hier zuletzt diskutierten Punkte berücksichtigt.

Neu: für die Roller-Devices (Shelly2/2.5/Plus2/Pro2) wurde ein Befehl eingebaut, der vordefinierte Standardattribute für die Rollosteuerung setzt:

Code Auswählen Erweitern

get <name> predefAttrDamit werden die Attribute devStateIcon, cmdIcon, webCmd and eventMap gesetzt, sofern diese noch nicht definiert sind. Der User kann diese Attribute wie sonst üblich ändern oder auch löschen. Es gibt auch den Slider wieder.
Das Device sieht dann z.B. so aus:
Du darfst diesen Dateianhang nicht ansehen.

Inkrementelle Befehle erfolgen z.B. mit

Code Auswählen Erweitern

set <Rollo-Device> delta +20   oder
set <Rollo-Device> delta -25
Nicht neu, aber vielleicht nicht allen bekannt ist die Möglichkeit, an den Rollo direkt Fahrzeiten (in Sekunden) zu übergeben:

Code Auswählen Erweitern

set <Rollo-Device> open <int>   oder
set <Rollo-Device> closed <int>

Nochmal erwähnen möchte ich die Möglichkeit, mit dem Attribut 'webhook' die Actions auf dem Shelly automatisiert zu definieren:

Code Auswählen Erweitern

attr <name> webhook <FHEMWeb>Die verfügbaren FHEMWeb-Devices werden per Dropdown-List angeboten. Es muss eine nicht passwortgeschütze Instanz ausgewählt werden.
Damit können Ereignisse am Shelly (z.B. Tasterdruck) ohne Zeitverzögerung an Fhem übertragen werden.
Das Attribut steht zur Zeit nur für Gen2-Devices zur Verfügung. Die Befehle (URLs) können aber als Kopiervorlage für Gen1-Devices genutzt werden.
Die URL auf einem ShellyPro3EM sieht dann beispielsweise so aus:

Code Auswählen Erweitern

http://192.168.178.99:8083/fhem?XHR=1&cmd=set%20Shelly_Y173%20Active_Power_$phase%20$active_poweroder einem ShellyPlusi4:

Code Auswählen Erweitern

http://192.168.178.99:8083/fhem?XHR=1&cmd=set%20Shelly_Y176%20button_on%200
Viel Erfolg beim Ausprobieren
Gruß
Bernhard

[carlos]

Code Auswählen Erweitern

defmod Heizungsschalter Shelly 192.168.178.92
attr Heizungsschalter devStateIcon 1.on:fts_door_open@green:off 1.off:fts_door@red:on 2.OK:10px-kreis-gruen@green 2.NOTOK:10px-kreis-rot@red
attr Heizungsschalter interval 60
attr Heizungsschalter model shellyplus1pm
attr Heizungsschalter room Shelly
attr Heizungsschalter stateFormat 2:state\
<a href="http://IPAddress" target="_blank">Hostname</a> \
1:relay\
<br>\
<b>Firmware:</b>\
firmware\
<br>\
<b>Wifi AP:</b>\
network_ssid
attr Heizungsschalter userReadings IPAddress {InternalVal($NAME,"DEF","0.0.0.0")}, \
Hostname {InternalVal($NAME,"NAME","0.0")}

setstate Heizungsschalter 2:Error: JSON\
<a href="http://192.168.178.92" target="_blank">Heizungsschalter</a> \
1:relay\
<br>\
<b>Firmware:</b>\
v0.14.1(update possible to v1.0.0-beta5)\
<br>\
<b>Wifi AP:</b>\
FB7590
setstate Heizungsschalter 2023-07-13 12:17:14 Hostname Heizungsschalter
setstate Heizungsschalter 2023-07-13 12:17:14 IPAddress 192.168.178.92
setstate Heizungsschalter 2023-07-13 12:12:39 cloud enabled(connected)
setstate Heizungsschalter 2023-07-13 12:12:39 firmware v0.14.1(update possible to v1.0.0-beta5)
setstate Heizungsschalter 2023-07-13 12:12:39 input off
setstate Heizungsschalter 2023-07-13 12:12:39 input_mode switch straight follow
setstate Heizungsschalter 2023-07-13 12:17:14 network invalid JSON data
setstate Heizungsschalter 2023-07-13 12:16:39 network_rssi -54
setstate Heizungsschalter 2023-07-13 12:12:39 network_ssid FB7590
setstate Heizungsschalter 2023-07-13 12:12:36 state Error: JSON
setstate Heizungsschalter 2023-07-13 12:12:39 webhook_cnt 0
setstate Heizungsschalter 2023-07-13 12:12:39 webhook_ver 0


Ich bekomme leider bei network und state JSON Fehler.
War auch in der letzten Version schon so.
An was kann das liegen?

Gruß

Hubert

[Starkstrombastler]

Ich bekomme leider bei network und state JSON Fehler.

Da ich selbst keine ShellyPlus1PM im Einsatz habe: Frage an die Runde: gibt es ähnliche Probleme mit ShellyPlus1PM?

[RalfRog]

Vielleicht lässt sich mit verbose 5 das JSON-Ergebnis mal händisch analysieren.

Bei mir war ja auch mal so was komisches, was sich mit "$json = JSON->new->utf8->relaxed;" lösen ließ. Es war nichts offensichtlich falsch am Ergebnis.
(siehe im Mai https://forum.fhem.de/index.php?msg=1274939)

Gruß Ralf

[curt]

Neu: für die Roller-Devices (Shelly2/2.5/Plus2/Pro2) wurde ein Befehl eingebaut, der vordefinierte Standardattribute für die Rollosteuerung setzt:

Code Auswählen Erweitern

get <name> predefAttrDamit werden die Attribute devStateIcon, cmdIcon, webCmd and eventMap gesetzt, sofern diese noch nicht definiert sind.

Also für mich ist das ganz toll, herzlichen Dank!

Das (bis auf die Schrittschaltung) muss ich nun noch in FTUI3 umsetzen; Du nutzt nicht zufällig die Nutzeroberfläche FTUI3?