Modul 36_Shelly.pm

[Prof. Dr. Peter Henning]

Habe gerade die Version 2.02 eingecheckt, mit einigen Fixes in der CommandRef und der Umsetzung des Vorschlags von Benni. Geht aber nicht bei Internals, sondern nur bei Readings

LG

pah

[MarNei]

Guten Morgen zusammen,

erstmal Danke an pah für das Modul!

Ich habe es mit einem Shelly 2 im Einsatz. Der Shelly 2 hat die Firmware v1.5.0-hotfix2 und das Modul die Version 2.01. Da ich auf meiner Testinstanz etwas ausprobieren wollte, habe ich den Shelly dort neu angelegt. Das habe ich gemacht:

• define Shelly01 Shelly <IP address>
• attr Shelly01 model shelly2
• attr Shelly01 mode relay

Das führte zur Meldung

Code Auswählen Erweitern

Shelly01: unknown attribute mode. Type 'attr Shelly01 ?' for a detailed list.

Set-Befehle werden dann auch nicht verarbeitet. In der fhem GUI ist der komplette Block für die set-Befehle verschwunden.

Die Reihenfolge die allerdings funktioniert ist:

• define Shelly01 Shelly <IP address>
• attr Shelly01 mode relay
• attr Shelly01 model shelly2

Dann ist alles so, wie es sein soll. Falls das nicht ein lokales Problem bei mir ist (kann man ja nie ausschließen), wäre es schön, wenn auch der erste Weg, den ich versucht habe funktionieren würde.

[studiosus12]

Hallo
@PAH - Danke für das Beispiel und die Arbeit am Modul!
Ich habe ich Command Ref natürlich gelesen und seit einiger Zeit den Fehler von MarNei vorliegen. Ich dachte aber - der Fehler sitzt vor der Tastatur.... Nun zweifle ich etwas weniger an mir... .

define SHL_RGB_Stripes Shelly 192.168.178.75
attr SHL_RGB_Stripes model shellyrgbw
attr SHL_RGB_Stripes mode color
attr SHL_RGB_Stripes stateFormat rgb    
attr SHL_RGB_Stripes WebCmd rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:on:off

führt zu:  SHL_RGB_Stripes: unknown attribute mode. Type 'attr SHL_RGB_Stripes ?' for a detailed list. SHL_RGB_Stripes: unknown attribute WebCmd. Type 'attr SHL_RGB_Stripes ?' for a detailed list.

Ein
define SHL_RGB_Stripes Shelly 192.168.178.75
attr SHL_RGB_Stripes mode color
attr SHL_RGB_Stripes model shellyrgbw
attr SHL_RGB_Stripes stateFormat rgb    
attr SHL_RGB_Stripes WebCmd rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:on:off
attr SHL_RGB_Stripes room Shelly

führt nur zu SHL_RGB_Stripes: unknown attribute WebCmd. Type 'attr SHL_RGB_Stripes ?' for a detailed list.

On-off ist möglich RGB settings funktionieren nicht

FW Modul v1.5.0-hotfix2

Danke und Grüße,
Mark

[dkreutz]

Bei mir ist das Attribut ,,mode" auch nicht verfügbar wenn model=shellyrgbw gestzt ist.
Der Workaround von @MarNei funktioniert aber: zuerst mode setzen, danach model

[Prof. Dr. Peter Henning]

Ist in der aktuellen Version gefixt.

Es hilft auch, wenn man einfach noch einmal das Attribut "model" setzt - der Fehler tritt nur bei der ersten Definition auf.

LG

pah

[Cluni]

Nur kurze Rückmeldung zur aktuellen Version (keine Ahnung, ob du daran schon was angepackt hattest - soll also keine Kritik oder ein Drängen sein): der Error im state nach dem Neustart von fhem ist noch da. Nach einem get status ist alles wieder ok.


Gesendet von iPhone XR mit Tapatalk

[Prof. Dr. Peter Henning]

keine Ahnung, ob du daran schon was angepackt hattest

Nö. Kann mit dem Startverhalten anderer FHEM-Komponenfen zusammenhängen.

LG

pah

[Prof. Dr. Peter Henning]

Habe gerade Version 2.03 eingecheckt - mit ein paar Fixes beim Setzen der Konfiguration.

Es geht z.B.jetzt auch

set ... config effect 0|..|6

LG

pah

[meyerhavener]

Moin,

Ich habe vor ein paar Tagen das Shelly Modul geupdatet. Ich nutze den Shelly 1 mit der Firmwar v1.5.0-hotfix2.

Seit dem Update des Moduls taucht im Log ständig die Fehlermeldung im Screenshot auf.

Ich habe gesehen, dass hier im Thread bereits im Januar über die Fehlermeldung gesprochen wurde. Ich konnte aber aus den Antworten für mein Problem nicht schlau werden bzw. habe einige Lösungsansätze ausprobiert.

Für jeden Hinweis wäre ich sehr dankbar

Ergänzung:
Es betrifft die lines: 844 und 890 im Shelly Modul

Code Auswählen Erweitern

CHANGED   
   DEF        192.168.xxx.xxx
   DURATION   0
   FUUID      5cfa38dd-f33f-7013-7c94-964fb1ed968f31e0
   INTERVAL   60
   NAME       SZ_mainlamp
   NR         57
   STATE      off
   TCPIP      192.168.xxx.xxx
   TYPE       Shelly
   READINGS:
     2019-06-07 12:17:17   cloud           disabled
     2019-06-07 12:17:17   firmware        v1.5.0-hotfix2
     2019-06-07 13:07:00   network         <html>connected to <a href="http://192.168.xxx.xxx">192.168.xxx.xxx</a></html>
     2019-06-07 13:12:28   relay           off
     2019-06-07 13:12:28   state           off
Attributes:
   interval   60
   model      shelly1
   shellyuser xy

Liebe Grüße meyerhavener

[wk]

Hallo,
hat von Euch einer neuere Informationen, ob die Shelly-Software auch bald den Status senden kann, wenn der Roller-Mode eingestellt ist?

Ich verwende das Modul AutoShuttersControl und das wird verwirrt dadurch, dass der richtige Status erst nach einem neuem Polling vorhanden ist.

Oder kann man das Polling unabhängig vom Interval kurz nach einem Fahrbefehl anstossen?

[Prof. Dr. Peter Henning]

Nach einem von FHEM gesendeten Fahrbefehl ist der Status automatisch richtig - nur manuelle Änderungen des Standes am Rolladenaktor selbst werden erst nach einem Polling erkannt.


LG

pah

[wk]

Hallo pah,

so habe ich es auch verstanden, aber wie im debug-log gezeigt, kommen verschiedene Werte.

Code Auswählen Erweitern


ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingBrightness: Sh_S - Event von einem Helligkeitssensor erkannt. Verarbeitung läuft. Sollten keine weitere Meldungen aus der Funktion kommen, so befindet sich die aktuelle Zeit nicht innerhalb der Verarbeitungszeit für Sunset oder Sunrise

ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShadingBrightness: Sh_S - Es wird nun geprüft ob der übergebene Event ein nummerischer Wert vom Brightnessreading ist.

ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShadingBrightness: Sh_S - Nummerischer Brightness-Wert wurde erkannt. Der Wert ist: 925.0 RainProtection: unprotected WindProtection: unprotected

ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Übergebende Werte - Azimuth:115.15, Elevation: 49.04, Brightness: 925.0, OutTemp: 16.8, Fenster Position: 125, Winkel Links: 10, Winkel Rechts: 10, Ist es nach der Zeitblockadezeit: JA, Ist es nach der manuellen Blockadezeit: JA, Ist es nach der Hälfte der Beschattungswartezeit: JA

ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Alle Werte für die weitere Verarbeitung sind korrekt vorhanden und es wird nun mit der Beschattungsverarbeitung begonnen

ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Alle Beschattungsbedingungen wurden erfüllt und somit wird der Beschattungsstatus um eine Stufe angehoben. Alter Status: in reserved Neuer Status: in

ASC_DEBUG!!! 2019.06.11 10:41:51 - FnSetCmdFn: Sh_S - Rolllo wird gefahren, aktuelle Position: 100, Zielposition: 10. Grund der Fahrt: shading in

ASC_DEBUG!!! 2019.06.11 10:41:51 - FnSetDriveCmd: Sh_S - NICHT versetztes fahren

ASC_DEBUG!!! 2019.06.11 10:41:51 - FnSetDriveCmd: Sh_S - NoOffset: NEIN

ASC_DEBUG!!! 2019.06.11 10:41:51 - FnShuttersCommandSet: Sh_S - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür

ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Der aktuelle Beschattungsstatus ist: in und somit wird nun in die Position: 10 zum Beschatten gefahren

ASC_DEBUG!!! 2019.06.11 10:41:51 - ShadingProcessing: Sh_S - Der aktuelle Beschattungsstatus ist: in, Beschattungsstatus Zeitstempel: 2019.06.11 10:41:51

ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShadingBrightness: Sh_S - Alle Bedingungen zur weiteren Beschattungsverarbeitung sind erfüllt. Es wird nun die eigentliche Beschattungsfunktion aufgerufen

ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShutters: Sh_S - Event vom Rolllo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von gettimeofday: 1560242511 Last Position Timestamp: 1560242511 Drive Up Max Duration: 60 Last Position: 100 aktuelle Position: 10

ASC_DEBUG!!! 2019.06.11 10:41:51 - EventProcessingShutters: eine automatisierte Fahrt durch ASC wurde erkannt! Es werden nun die LastDriveReading und StateReading Werte gesetzt!

ASC_DEBUG!!! 2019.06.11 10:42:05 - EventProcessingShutters: Sh_S - Event vom Rolllo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von gettimeofday: 1560242525 Last Position Timestamp: 1560242511 Drive Up Max Duration: 60 Last Position: 100 aktuelle Position: 100

ASC_DEBUG!!! 2019.06.11 10:42:05 - EventProcessingShutters: eine automatisierte Fahrt durch ASC wurde erkannt! Es werden nun die LastDriveReading und StateReading Werte gesetzt!

ASC_DEBUG!!! 2019.06.11 10:43:06 - EventProcessingShutters: Sh_S - Event vom Rolllo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von gettimeofday: 1560242586 Last Position Timestamp: 1560242511 Drive Up Max Duration: 60 Last Position: 100 aktuelle Position: 5

ASC_DEBUG!!! 2019.06.11 10:43:06 - EventProcessingShutters: eine manualle Fahrt wurde erkannt!

ASC_DEBUG!!! 2019.06.11 10:44:36 - EventProcessingTwilightDevice: Sh_S - Event vom Astro oder Twilight Device wurde erkannt. Event wird verarbeitet


Um 10:41:51 wird die Fahrt ausgelöst und die Position 10 gesetzt.
Um 19:42:05 wird die Position wieder auf 100 gesetzt und dann nach weitern 60 Sekunden kommt die Position 5.

Das kann ich mir nicht erklären.

[Prof. Dr. Peter Henning]

Ich bin aber nicht der Maintainer von ASC.

LG

pah

[wk]

Hallo pah,

das ist mir klar.
Da aber der Rolladen im Shelly-Modul betrieben wird und dieser Modul dem ASC irgendwelche Fahrten meldet, habe ich es hier versucht zu klären.

Trotzdem vielen Dank.

cu
Walter

[Prof. Dr. Peter Henning]

Sorry, aber das ist nicht korrekt - dieses Modul meldet gar nichts an ASC, sondern setzt nur seine eigenen Readings. Dieser Unterschied ist wesentlich für die Fehlersuche, da darf man also bitte keine Nebelkerzen zünden.

LG

pah