Support-Thread Modul 36_Shelly.pm

[RalfRog]

Ich seh mal zu, dass ich da was testen kann.
Da CoIoT ja broadcastet kann ich alles parallel (Test und Produktiv) probieren ohne das es sich stört.

Das einzige Problem was ich immer hatte ist: zu erkennen welche Aktualisierung wodurch ausgelöst wird (Monitor oder Modul) - melde mich.

Ich habe Gen1 => PlugS, 1PM und 3EM mit aktivem CoIoT

[bene80]

Code Auswählen Erweitern

Diese Shellies können jedoch via Colo-T-Protokoll mit dem Modul [i]ShellyMonitor[/i] ausgelesen werden (nur Gen1)
Dann funktioniert vermutlich der ShellyMonitor  mit dem Motion2 nicht. Muss ich mir noch anschauen wie ich den lux Wert vom Motion2 in FHEM integriert bekomme.

[MadMax-FHEM]

Code Auswählen Erweitern

Diese Shellies können jedoch via Colo-T-Protokoll mit dem Modul [i]ShellyMonitor[/i] ausgelesen werden (nur Gen1)
Dann funktioniert vermutlich der ShellyMonitor  mit dem Motion2 nicht. Muss ich mir noch anschauen wie ich den lux Wert vom Motion2 in FHEM integriert bekomme.

MQTT?

Wäre bei einem Motion-Sensor eh besser?
Push vs. Poll (wenn man vom Shelly Modul ausgeht / ColloIt ist ja auch push)

Gruß, Joachim

[bene80]

MQTT?

Ja genau so hab ich es jetzt gelöst. Bin überrascht, dass das gleich alles so problemlos funktioniert. Bin ja doch nur ein Laie der sich alles zusammenbastelt und darauf angewiesen ist das andere den Code bereitstellen.

[RalfRog]

Ich seh mal zu, dass ich da was testen kann.
Da CoIoT ja broadcastet kann ich alles parallel (Test und Produktiv) probieren ohne das es sich stört.

Das einzige Problem was ich immer hatte ist: zu erkennen welche Aktualisierung wodurch ausgelöst wird (Monitor oder Modul) - melde mich.

Ich habe Gen1 => PlugS, 1PM und 3EM mit aktivem CoIoT

Mein Pi1 mit dem Testsystem hing irgendwie - läuft nun wieder.
Habe das Device ShellyMonitor definiert und am ShellyModul das pollen (interval 0) abgestellt => bisher sehe ich (Gen1):

• PlugS     war schon eingerichtet, der Monitor erkennt das vorhandene Device und aktualisiert
  - energy
  - power
  - relay
  
  
• 1PM     war schon eingerichtet, der Monitor erkennt das vorhandene Device und aktualisiert
  - energy
  - power
  - relay
  
  
• 3EM     war nicht eingerichtet, der Monitor erkennt ein Device und richtet es generic ein, habe es manuell auf 3EM umgestellt, aktualisiert werden
  - power_0|1|2
  - energy_0|1|2
  - energyReturned_0|1|2   (Achtung ReadingName durch ShellyModul energy_returned_0|1|2)
  - relay
  

Am Testsystem ist das relativ leicht festzustellen. Einfach alle Readings löschen und schauen was dann durch CoIot per MulticastMessage reinkommt. Die entsprechenden Readings werden wieder angelegt.
Fazit: prizipiell läuft es noch und die interesantesten Werte power, energy, energyReturned werden per push aktualisiert.

Ein Vergleich mit dem "alten" ShellyModul im produktiven System ist schwierig, da nicht unterschieden werden kann ob der WerteUpdate durch abfragen (poll) oder CoIot entsteht und event-min-interval auch noch mitwirkt. Ich vermute allerding, dass dort die gleichen Readings aktualisiert werden (und nicht noch Weitere).

[gvzdus]

Moin, ich kann das ShellyMonitor-Modul gerne für den 3EM anpassen, sodass das neue Shelly-Modul und ShellyMonitor gemeinsam "auf den Markt" kommen.
Generell: Zwar hat Shelly für Gen1 CoIoT nicht eingestellt, wie es mal aussah. Aber mit Gen2 ist es eben raus, und Dinge wie RPC über UDP passen auch nicht von der Art her. Deswegen läuft es da m.E. auf MQTT raus, wo übrigens der Support in FHEM durchaus gut ist (gestern mal mit den neuen Shelly Minis Plus 1PM und Plus PM getestet), oder man müsste doch auf WebSockets gehen.
Ein guter Grund für das Shelly-Modul, nämlich das es den Parallelbetrieb von Cloud und FHEM erlaubt (während MQTT bei Gen1 die Cloud ausschloss), ist ja bei Gen2 entfallen.

[RalfRog]

Moin, ich kann das ShellyMonitor-Modul gerne für den 3EM anpassen, sodass das neue Shelly-Modul und ShellyMonitor gemeinsam "auf den Markt" kommen.

Das wäre toll.

Es ist ja nicht so, dass die Gen1 in der Versenkung verschwinden. Eine installierte Basis ist ja da und mit Modul kann der Monitor interessant sei. Lt. Statistik immerhin

Shelly   591   3327   28
ShellyMonitor   103   104

Für meinen kleinen Gerätepark ist momentan sogar noch die Kombi Monitor & Modul (alt) ausreichend (wenn man von der Modifiaktion für energyReturned & total_power beim 3EM absieht), daher schwenke ich auch nicht zu MQTT (einige Problembeispiele von Usern schrecken ja eher ab).

Die Weiterentwicklung des 36_Shelly.pm ist auf jeden Fall toll, da es bei Shelly ja munter weitergeht.


Eine Abstimmung hinsichtlich der Readings wäre noch wünschenswert (z.B. beim 3EM energyReturned_0|1|2 vs. energy_returned_0|1|2).
Bei Apassung ne Info (Hinweis im Modul, internals?) damit man am Monitor oder Modul entsprechend reagieren kann.

[gamauf]

Hallo!

Habe einen Shelly Pro1PM.
Mit Modulversion neuer als 4.04e kann ich das relay nicht mehr via FHEM schalten.
im Log steht:

Code Auswählen Erweitern

2023.09.12 12:16:50.521 1: [Shelly_onoff] device PV_WR has error "invalid JSON data"und Reading state wechselt auf "Error: JSON"
Hab ich ein problem in meiner Konfiguration, oder liegt es am Modul?

LG
Rainer

PS.: Übrigens vielen Dank für die Arbeit am Modul!

[Starkstrombastler]

Mit Modulversion neuer als 4.04e kann ich das relay nicht mehr via FHEM schalten.

Hallo gamauf,
probiere einmal das Device neu zu definieren, mit defmod .... oder indem du in der Web-Oberfläche "DEF" betätigst. 

Zumindest hier funktioniert der Shelly Pro1, vmtl. mit Modul Version 4.09a vom 24.08.2023:

ich habe seit heute einen Shelly Pro1 im Einsatz.

Ansonsten benötige ich mehr Daten.

[gamauf]

Ich glaub ich habe die Ursache gefunden:
Ich hatte

Code Auswählen Erweitern

attr PV_WR defchannel KanalNamegesetzt, was die neue Modulversion veranlasst hat im URL statt

Code Auswählen Erweitern

http://192.168.1.86/relay/0?turn=offdas zu senden:

Code Auswählen Erweitern

http://192.168.1.86/relay/KanalName?turn=offnach dem Löschen des Attributes funktioniert auch die neue Modulversion!

neut setzen/ändern kann ich "defchannel" nicht -> Altlast, wird aber trotzdem verwendet wen gesetzt???

[Starkstrombastler]

attr PV_WR defchannel KanalName

Alphanumerische Kanalnamen der Shelly-Weboberfläche werden vom Modul nicht unterstützt. Beim defchannel Attribut muss zwingend ein Integer angegeben werden.

Mit dem nächsten Update des Moduls wird geprüft, dass das Attribut defchannel nur bei Geräten mit mehreren Kanälen mit einem Integer als Wert eingegeben wird.

Altlast, wird aber trotzdem verwendet wen gesetzt???

Solange wird hier mit Testversionen arbeiten, kann es schon mal vorkommen, dass Attribute in nicht vorgesehener Weise setzbar sind.

Aber auch wenn typische Fehlerfälle abgefangen werden, wird es nie möglich sein alle möglichen Problemfälle zu berücksichtigen.

[JWRu]

Für's Finetuning des Moduls:
Ich erhalte ab und zu folgende Warnung

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_Shelly.pm line 1890.

[gvzdus]

Moin, ich kann das ShellyMonitor-Modul gerne für den 3EM anpassen...

ShellyMonitor habe ich angepasst - ist morgen per Update verfügbar, zufällig war ich nämlich heute in der Verlegenheit, einen 3EM in Betrieb zu nehmen.
Betrifft aber eigentlich nur die Auto-Creation und Erkennung. Die "energyReturned"-Werte habe ich so gelassen, bevor ich jemandem, der sich auf die Werte stützt, seine Config wegschieße.

Btw: Jetzt steuert der Shelly3EM meinen Victron und die OpenWB. Vorher war es der OBIS-Lesekopf am Zähler. Da hatte ich zwar das 47_OBIS-Modul auch auf den Tibber Pulse angepasst, aber der Delay war dann doch etwas höher, um den Victron fein zu steuern. So bin ich wieder auf den USB-Lesekopf zurückgegangen, aber ab 1.10.2023 startet bei uns der Tibber-Tarif, sodass der Pulse jetzt ran muss.

Auf der OpenWB habe ich noch eine 2. FHEM-Instanz hochgezogen, die sich *nur* um Verarbeitung der Energiewerte kümmert - dank CoIoT ist ja der Parallelbetrieb mit mehreren FHEM-Instanzen möglich.

[Starkstrombastler]

ShellyMonitor habe ich angepasst

heißt das, dass im Shelly Modul die Readings für den Shelly3EM so bleiben können wie sie sind?

Jetzt steuert der Shelly3EM meinen Victron und die OpenWB.

Gibt es eigentlich Erfahrungserte zur Genauigkeit der Shelly-Meter? Ein User hier im Forum hatte über 5% Abweichung bei einem ShellyPro3EM berichtet.

[VB90]

Am Zähler abgelesen: 174,1 kWh
Vom 3EM gemessen: 168,4 kWh
In absolut exakt dem selben Zeitraum.

Mit dieser Abweichung kann ich aktuell leben.

vb