Support-Thread Modul 36_Shelly.pm

Begonnen von Prof. Dr. Peter Henning, 03 Februar 2021, 08:03:09

Vorheriges Thema - Nächstes Thema

Starkstrombastler

Zitat von: bene80 am 22 September 2023, 10:08:07Der Webhook geht ja trotzdem an einen shelly, also wieder ins Modul rein.
Ja, das stimmt gewissermaßen. Aber dein Rollladenaktor ist halt nur (zufällig) ein Shelly, es könnte auch ein anderes FHEM-Device oder irgendein anderes Gerät sein, welches in der Lage ist URLS zu interpretieren.

Zitat von: bene80 am 22 September 2023, 10:08:07Hmm, verstehe einen eingehenden Befehl vom i4 müsste ich dann noch in FHEM mit dem Rollo verbinden, so sollte es funktionieren.
Ich habe das so vorgeschlagen (eine Action mit zwei URLs), um zu sehen was im FHEM-i4-Device ankommt. Du hast schließlich ein merkwürdiges Verhalten an deinem Rolloaktor beschrieben.

Ansonsten ist mMn immer die einfachste ausreichende Lösung zu bevorzugen, also URL direkt an den Rollo-Aktor. Wenn es einen Grund für etwas komplizierteres gibt, dann sollte die URL auf den i4 gehen und die Readings des i4 triggern bspw. ein Notify.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

bene80

#586
Ich glaube das ist ein bug im shelly i4. Ich habe es jetzt so gelöst, dass ich mit dem i4 direkt ein shelly Relay schalte und nicht mit dem Umweg über fhem. Dann funktioniert es, das relay wird nur einmal geschaltet
Den Status lasse ich mir trotzdem an das fhem shelly i4 device schicken, so wie von dir vorgeschlagen. Da kommen dann genau 4 Befehle im Abstand von 16s an

2023-09-22_20:04:21 shelly_Kizi_i4 input_3: ON
2023-09-22_20:04:05 shelly_Kizi_i4 input_3: ON
2023-09-22_20:03:49 shelly_Kizi_i4 input_3: ON
2023-09-22_20:03:32 shelly_Kizi_i4 input_3: ON

Wüsste nicht wo ich das im shelly einstellen kann und warum es mit mit direkten HTTP-Requests funktioniert

Mir ist gerade aufgefallen, dass das alle V2 shellys so machen. Bei einem shely plus1 mit activierten output webhooks, sieht man in fhem, dass das device mehrmals einen Befehl erhält. 

Boris

Hi zusammen,

vorab vielen Dank für das Shelly Modul, gefällt mir sehr gut.
Ich habe es bei mir eingebunden und nutze es mit einem Shelly3em. Dabei ist mir aufgefallen, dass bei den Readings nur ein Teil der verfügbaren Daten vorhanden zu sein scheint.
Konkret vermisse ich das total_returned bei den emeters. (ist unter https://shelly-api-docs.shelly.cloud/gen1/#shelly-3em-emeter-index auch dokumentiert.) Ich habe mal den Code im Github angeschaut und dort habe ich gesehen, dass der Teil einfach nicht mit eingelesen wird.
Jetzt kenne ich mich damit nicht so gut aus, könnte man das noch mit dazu nehmen?

(Hintergrund ist, dass ich eine Solaranlage hat, diese an einer Phase einspeist, aber an einer anderen wird noch was verbraucht. In Summe speise ich eigentlich noch ein, aber da es pro Phase betrachtet wird bleibt das "total" bei der einen stehen, bei der anderen läuft es weiter. In Summe geht der Energieverbrauch hoch, obwohl ich sogar einspeise.)

Starkstrombastler

Hallo Boris,
herzlich Willkommen im Forum!

Zitat von: Boris am 23 September 2023, 16:09:12Konkret vermisse ich das total_returned bei den emeters
Der Shelly3EM kumuliert für jede Phase einerseits die bezogene Energie (total), andererseits die eingespeiste Energie (total_returned).
Das Modul liest diese Werte und legt sie in den Readings 'energy_0|1|2' und 'energy_returned_0|1|2' ab. Außerdem berechnet das Modul jedesmal die Summe von  'energy_0'+'energy_1'+'energy_2' und legt den Wert im Reading 'energy_TTL' ab. Entsprechend wird 'energy_returned_TTL' ermittelt.
Diese Readings sollten also vorhanden sein. Benutze das Attribut 'showunits', um die Einheiten zu sehen, dadurch wird das verständlicher.

Allerdings ermittelt der Shelly3EM keinen Saldo. Vereinfacht lässt sich der Saldo aus der Differenz von 'energy_TTL'-'energy_returned_TTL' ermitteln. Das stimmt aber nur, wenn die Leistungen auf den drei Phasen während des Erfassungsintervalls konstant sind. Liegt dagegen auf der Phase von der Solaranlage ein getakteter Verbraucher (z.B. Induktionskochfeld), so kann es passieren das auf dieser Phase in kurzen Abständen eingespeist und bezogen wird. Der Shelly zählt dann seine beiden Werte hoch.

Eine Verbesserung könnte durch ein hinreichend kleines Intervall erreicht werden. Zumindest beim ShellyPro3EM funktioniert das aber nicht, weil der Shelly mit einem internen Intervall von 60 Sekunden arbeitet. Dies wird sichtbar, wenn im Modul ein kleines Intervall eingestellt wird: neue Werte kommen dann trotzdem nur im Minutentakt.
Zumindest wird im nächsten Modulupdate für den Shelly3EM die oben erwähnte Differenz berechnet und als Reading ausgewiesen. Vielleicht liefert das ja trotzdem brauchbare Ergebnisse.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

Boris

#589
Hi Starkstrombastler,

vielen dank für das herzliche willkommen und die schnelle Antwort.
Vielleicht muss ich da dann was anders einstellen oder so, aber bei mir sehe ich die Readings energy_returned_0 etc nicht. Das aufsummieren der energy_* habe ich selbst manuell gemacht, da ich auch das energy_TTL nicht sehe.
Kann man irgendwo eine Versionsnummer des Shelly Moduls sehen um sicher zu sein, dass ich da nichts zu altes habe?
Update von FHEM habe ich allerdings ausgeführt. Und in dem code im Github habe ich auch keine Zeilen für energy_returned gefunden.

Was mache ich hier noch falsch?

Habe was bezüglich Version gefunden, mittels "update" kommt bei mir wohl folgendes Shelly Modul:
  36_Shelly.pm        26017 2022-05-02 07:04:23Z phenning

Passt das?

Starkstrombastler

Also zur Erklärung: Das Shelly-Modul wurde von P. Henning entwickelt, per update erhält man die letzte von ihm erstellte Version. Ab Dezember '22 habe ich mich an das Thema herangewagt und insbesondere Ergänzungen für die Plus- und Pro-Shellies entwickelt. Das überarbeitete Modul wurde von mir zunächst immer als Testversion hier im Forum zur Verfügung gestellt.
Die aktuell letzte Version findet sich hier zum Herunterladen. Diese Datei ersetzt die auf deinem System vorhandene 36_Shelly.pm.
Damit die neue Version nicht durch das nächste Update überschrieben wird:
attr global exclude_from_update 36_Shelly.pm
Die aktuelle Version erhälst du im Shelly-Device mittels get <name> version.

IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

Starkstrombastler

Zitat von: bene80 am 22 September 2023, 20:25:14Ich glaube das ist ein bug im shelly i4. Ich habe es jetzt so gelöst, dass ich mit dem i4 direkt ein shelly Relay schalte und nicht mit dem Umweg über fhem. Dann funktioniert es, das relay wird nur einmal geschaltet
Den Status lasse ich mir trotzdem an das fhem shelly i4 device schicken, so wie von dir vorgeschlagen. Da kommen dann genau 4 Befehle im Abstand von 16s an
Ich kann das Verhalten des ShellyPlusI4 inzwischen auch auf meinem Testsystem sehen. Im Modul finde ich keine Ursache, ich denke dass die Shelly FW 1.0.3 eine nicht parametrierbare Wiederholfunktion hat.... Aber es wundert mich, dass dein Relais immer nur einen Schaltbefehl erhält.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

RalfRog

Zitat von: Boris am 23 September 2023, 21:25:34....
36_Shelly.pm        26017 2022-05-02 07:04:23Z phenning
...

Es ist definitiv so, dass das "alte Original von Mai 2022" energyReturned nicht kann.

Ich habe Starkstrombastlers tolle Version zwar nur auf dem Testsystem - läuft bei mir mit Shelly1, 1PM, Plug-S, PlugPlus-S und 3EM ohne Auffälligkeiten.


FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

bene80

Zitat von: Starkstrombastler am 23 September 2023, 22:17:08Ich kann das Verhalten des ShellyPlusI4 inzwischen auch auf meinem Testsystem sehen. Im Modul finde ich keine Ursache, ich denke dass die Shelly FW 1.0.3 eine nicht parametrierbare Wiederholfunktion hat.... Aber es wundert mich, dass dein Relais immer nur einen Schaltbefehl erhält.

Wie gesagt dieser Befehl funktioniert nicht, der wird immer 4 Mal ausgeführt. http://192.168.0.3:8088/fhem?XHR=1&cmd=set%20shelly_Rollo_KiZi%20closed%20
Dieser Befehl, der direkt an den shelly geschickt wird funktioniert. Der Status wird trotzdem 4Mal an fhem weitergeschickt. Klar dass der Rollo mehrmals färht http://192.168.0.100/roller/0?go=close
Ein shelly plus1 und 2 zeigt das selbe Verhalten. Bei denen ist das allerdings nicht immer und nur einmal. Außerdem ist mir aufgefallen, wenn man einen Schalter mehrmals hintereinander betätigt, dass diese Befehle nicht mehr direkt in FHEM ankommen, sondern erst mit Verzögerung. So als ob das Web Interface mit dem senden der Befehle nicht hinterherkommt


RAM5869

Hallo Zusammen,
Danke für die Erstellung und ständige Verbesserung dieses Moduls.
Ich habe mir vor kurzem auch zwei shellysi4 mit den dazugehörigen Shelly 4-fach Wandtastern für die Steuerung verschiedener zigbee Lampen zugelegt.
Nach langem Studium dieses Themas (leider funktioniert die Suchfunktion nicht) bin ich nun auch bei dem Problem, dass beide Shellyi4 jeden befehl viermal alle 16s senden. Das ist der Fall sowohl bei "Button" wie auch "Switch" Konfiguration im Shellyi4.
Hat jemand eine Idee wie man das im FHEM abfangen könnte, sodass das notify nicht viermal hintereinander ausgelöst wird?

Starkstrombastler

Zitat von: RAM5869 am 26 September 2023, 08:54:58sodass das notify nicht viermal hintereinander ausgelöst wird
versuche mal die Events, auf welche das Notify reagiert mit event-min-interval zu "drosseln", z.B. so:
attr ShellyPlusI4 event-min-interval input_0:60,input_1:60
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

RAM5869

Danke dir, das funktioniert erst einmal.
Hat nur den Nachteil, dass man den Taster erst wieder nach 60s benutzen kann.

Ich habe mir inzwischen das Debug Log vom Shelly angeschaut.
Leider geht ständig die Verbindung zum WebUI verloren:
Du darfst diesen Dateianhang nicht ansehen.

Das macht es schwierig das Debug log vom Shelly auszuwerten, da die Daten bei jedem Verbindungsverlust gelöscht werden. Ich habe deshalb mal ein Bildschirmvideo aufgezeichnet und daraus dann die Screenshots genau vor den Verbindungsverlusten geholt und hier zusammengesetzt:
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.

Darin ist zum Einen zu sehen, dass das WebUI die Verbindung immer bei der Statusabfrage verliert und zum Anderem das vierfache Senden des Shellys.
Es sieht so aus, als würde der Shelly auf eine Rückmeldung vom Modul warten, welche er nicht bekommt und deshalb noch einmal sendet "DEADLINE_EXCEEDED: Timed out". Nach dem vierten Versuch gibt er dann auf "failed too many times".

Vielleicht hilft dir diese Auswertung weiter.
   

 

Starkstrombastler

Hallo RAM5860,
danke für die Analyse. Das Logging sehe ich jetzt auch so bei mir. Damit bestätigt sich, dass das Verhalten eigentlich ein Thema für das Shelly Support Forum ist.

Interessant wäre das Verhalten des ShellyPlusI4 mit älterer Firmware als 1.0.3. Ich kann das leider nicht nachstellen, weil es für die Gen-2 keine Firmware zum Download gibt.

Zitat von: RAM5869 am 26 September 2023, 13:17:20Leider geht ständig die Verbindung zum WebUI verloren:
Das passiert, wenn das Modul eine Anfrage an den Shelly sendet. Für "ungestörtes" Logging kann das Interval vorübergehend auf 0 gesetzt werden.
Das Shelly-Log lässt sich im Übrigen ganz komfortabel als Textdatei herunterladen. Interessante Abschnitte können dann hier im Forum in Code-Tags gesetzt werden.
Dabei kannst du auch deine ggf. sichtbaren Passwörter etc. verschleiern.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

RAM5869

Hallo Starkstrombastler,
die Anfrage beim Shelly Support habe ich heute schon gestartet:
https://www.shelly-support.eu/forum/thread/22320-actions-werden-4x-im-abstand-von-16s-gesendet/?postID=231843#post231843
Allerdings habe ich auch dort das Problem, dass ich kein vollständiges Logfile über das vierfache senden zur Verfügung stellen kann.

Das Interval habe ich auf 0 gesetzt wie von dir empfohlen.
Beim Betätigen des Tasters wird aber dann die Anfrage gesendet, das WEBUI verliert die Verbindung und die Logeinträge werden gelöscht. Dadurch gibt es auch nichts zum herunterladen als Textdatei.
Das vierfache Senden kann ich also leider immer noch nicht in einem Logfile für den Shelly Support zur Verfügung stellen.

Dein Hinweise zu den Code-Tags werde ich gern umsetzen.
Danke für deine Unterstützung!

LuWoody

#599
Moin zusammen,

hat schon jemand erfolgreich geschafft, einen ShellyPro3EM über FHEM einzubinden?

In dem FHEM commandref & in dem 36_Shelly.pm Modul taucht der ShellyPro3EM leider nicht mit auf ( <attr <name> model generic|shelly1|shelly1pm|shelly2|shelly2.5|shellyuni|shelly4|shellyplug|shellydimmer|shellyrgbw ).
Die Vermutung liegt daher nahe, dass dieser leider noch nicht von dem FHEM Modul supportet wird.
Allerdings taucht im FHEM wiki für das Modul bereits das Gerät "ShellyPro3EM" in einem Beispiel mit auf. ( https://wiki.fhem.de/wiki/Modul_Shelly )

Ich habe es trotzdem mit einem der anderen Modelle ausprobiert, doch es erscheint bei allen modellen nur im Fhem log ein Eintrag "[Shelly_configure] invalid JSON data for device <DEVICENAME>".

EDIT:
Falls noch jemand das gleiche Probleme haben sollte
-> Ich bin auf die angepasste Version für das Shelly Modul von Starkstrombastler gestoßen [ https://forum.fhem.de/index.php?topic=111905.msg1285498#msg1285498 ].
Hiermit funktioniert es, vielen Dank hierfür! :)

LG
LuWoody