Modul 36_Shelly.pm

Begonnen von Prof. Dr. Peter Henning, 15 November 2018, 10:24:39

Vorheriges Thema - Nächstes Thema

CoolTux

Zitat von: Cluni am 27 Mai 2019, 12:22:30
Hallo pah,

mir ist nun auch aufgefallen, dass meine Shellys nach einem Neustart immer auf "Error!" stehen. Ursprünglich dachte ich ja auch, dass das ein Problem mit dem Passwort wäre, aber dem scheint nicht so zu sein. Sobald ich ein get status oder einen Schaltbefehl ausführe, verschwindet der Fehler. Kannst du dir darauf einen Reim machen? Wird der Status beim Fhem-Neustart ggf. zu einem ungünstigen Zeitpunkt geprüft oder hast du einen Rat, wie man diese Problem umgehen kann? Hatte schon überlegt einen Timer bei Systemstart auf bsw. 2 Minuten zu setzen und automatisch ein get status zu machen, aber das ist ja dann gefrickelt und sehr unschön...

LG Bernd

Hallo Bernd,

Stell mal bitte ein Shelly Device welches diesen Fehler hat auf verbose 5 und starte dann neu. Vorher speichern nicht vergessen  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Cluni


2019.05.27 12:32:56 1: [Shelly_status] invalid JSON data
2019.05.27 12:32:56 5: [Shelly_status] has obtained data 401 Unauthorized
2019.05.27 12:32:56 1: [Shelly_status] invalid JSON data
2019.05.27 12:32:56 1: [Shelly_status] invalid JSON data


Nach get status steht folgendes im Log:


2019.05.27 12:38:45 5: [Shelly_status] Issue a non-blocking call to http://Cluni:meinPW@192.168.0.150:80/status
2019.05.27 12:38:45 5: [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"Virus4free","ip":"192.168.0.150","rssi":-37},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"12:38","serial":1,"has_update":false,"mac":"CC50E350024D","relays" :[{"ison":false, "has_timer":false}],"meters":[{"power":0.00,"is_valid":"true"}],"update":{"status":"idle","has_update":false,"new_version":"20190522-070313/v1.5.0@a5e1e3f8","old_version":"20190522-070313/v1.5.0@a5e1e3f8"},"ram_total":51104,"ram_free":40820,"fs_size":233681,"fs_free":170429,"uptime":358429}

Benni

#272
Zu aller erst mal vorweg: Ich bin inzwischen ein echter Shelly-Fan!  ;D
Toll was die kleinen Dinger können! Super Preis-Leistungsverhältnist und mit Pahs Modul super simpel, quasi out-of-the-box einzurichten. Danke dafür!

So, jetzt zu meinem eigentlichen Anliegen:

Was mich  bei meinem Shelly 2 bei der Shelly-Modulumsetzung im Relay-Mode "gestört" hat ist, dass ich die beiden Ausgänge (Relays) nicht als Kanäle (und somit als eigenständige Devices) des Hauptdevices zur Verfügung habe. Also so wie es bspw. bei Homematic HM-Lc-SW2-Fm der Fall ist. Da ich bisher vor allem HM im Einsatz habe, bin ich das so gewöhnt und wollte das an der Stelle auch so haben.
Ich habe mir das dann einfach mit 2 readingsProxy selbst gebastelt. Vielleicht teilt ja jemand meine "Leidenschaft" für Kanal-Devices?

Hier mal ein rudimentäres List des Haupt-Devices, also des eigentlichen Shelly-Devices:


Internals:
   DEF        192.168.*.*
   FUUID      5ce02482-f33f-b8e7-22a9-5af5379d64542569
   FVERSION   36_Shelly.pm:v2.0.0-s19432/2019-05-21
   INTERVAL   60
   NAME       EG.BD.SW.Main
   NR         959
   STATE      0 W
   TCPIP      192.168.*.*:80
   TYPE       Shelly
   READINGS:
     2019-05-18 17:28:02   cloud           disabled
     2019-05-18 21:30:28   config          mode=relay=
     2019-05-27 15:31:23   energy          7.1
     2019-05-22 19:25:05   firmware        v1.5.0
     2019-05-26 07:08:39   network         connected
     2019-05-27 15:30:22   overpower_0     false
     2019-05-27 15:30:21   overpower_1     false
     2019-05-27 15:30:23   power           0
     2019-05-27 15:30:22   relay_0         off
     2019-05-27 15:30:21   relay_1         off
     2019-05-27 15:30:22   state           OK
Attributes:
   DbLogExclude .*
   defchannel 0
   mode       relay
   model      shelly2
   room       System->Shelly,EG->Bad
   shellyuser fhem
   stateFormat power W
   webCmd     :


Da ich ja nachher den Schaltzustand der Relays in den einzelnen proxy-Devices habe, habe ich mir hier über stateFormat noch die aktuell gemessene Leistung als Anzeigewert eingetragen.

Hier die beiden readingsProxy-Devices, die jeweils die beiden Realy-Readings des Haupt-Devices wiedergeben:


Internals:
   DEF        EG.BD.SW.Main:relay_0
   DEVICE     EG.BD.SW.Main
   FUUID      5ce1ab27-f33f-b8e7-7fef-5aac7a21cca92bd0
   NAME       EG.BD.SW.Main_00.Spiegel
   NOTIFYDEV  global,EG.BD.SW.Main
   NR         975
   NTFY_ORDER 50-rpBadSpiegel
   READING    relay_0
   STATE      off
   TYPE       readingsProxy
   CONTENT:
     EG.BD.SW.Main 1
   READINGS:
     2019-05-27 15:30:22   lastCmd         off
     2019-05-27 15:30:22   state           off
Attributes:
   alias      Bad Spiegel
   group      Licht
   icon       light_mirror
   room       EG->Bad
   setFn      {$CMD." 0"}
   setList    on off



Internals:
   DEF        EG.BD.SW.Main:relay_1
   DEVICE     EG.BD.SW.Main
   FUUID      5ce5a411-f33f-b8e7-1822-8cadb1737a4e6d59
   NAME       EG.BD.SW.Main_01.Decke
   NOTIFYDEV  global,EG.BD.SW.Main
   NR         3389
   NTFY_ORDER 50-rpBadDecke
   READING    relay_1
   STATE      off
   TYPE       readingsProxy
   CONTENT:
     EG.BD.SW.Main 1
   READINGS:
     2019-05-27 15:30:21   lastCmd         off
     2019-05-27 15:30:21   state           off
Attributes:
   group      Licht
   icon       light_downlight
   ipAlias    Bad Decke
   room       EG->Bad
   setFn      {$CMD." 1"}
   setList    on off


Interessant sind bei den beiden Devices v.a. die Attribute setFn und setList.
Per setFn wird festgelegt, wie ein set am jeweiligen proxy-Device eine entsprechende Umsetzung am Hauptdevice vornimmt.

Hier wird also bspw. ein set EG.BD.SW.Main_01.Decke on durchgeschleust ans Hauptdevice als set EG.BD.SW.Main on 1.

Durch das setzen des Attrbuts setList auf [on off] hat zur Folge, dass beim proxy-Device automatisch setExtensions aktiviert werden, sprich damit ist u.a. automatisch auch ein toggle verfügbar. Auch die anderen, wie etwa on-for-timer werden mit der o.g. setFn korrekt durchgeschleust.
Für die Umsetzung der [on-for-timer] und der anderen müsste setFn entsprechend erweitert werden. Da ich das aber so gut wie nie brauche, habe ich mir das erst mal gespart.

Wie gesagt: Vielleicht kann's ja jemand gebrauchen.  ;)

Btw.: Ich wusste nicht so recht, ob ich das hier posten soll, oder in Codeschnipsel, habe mich dann aber (offensichtlich) für hier entischieden.

gb#

Edit: Anpassung nach Pahs Anmerkung aus folgendem Post: https://forum.fhem.de/index.php/topic,93251.msg944004.html#msg944004


Hauenschild

#273
N'abend allerseits!

Ich habe einen Shelly_1 und FHEM auf einem Raspberry Pi mit dem Modul 36_Shelly.pm Version 2.01 von phenning = ,pah'.

Die Internals vom Shelly_1 lauten:

   DEF        192. *** . *** . ***
   FUUID      ****...
   INTERVAL   10
   NAME       Ankleide_Taster
   NR         743
   STATE      on
   TCPIP      192.*** . *** . ***:80
   TYPE       Shelly
   READINGS:
     2019-02-02 19:03:43   cloud           disabled
     2019-05-25 09:20:03   firmware        v1.5.0
     2019-05-27 19:30:03   network         connected
     2019-05-24 19:25:39   relay           on
     2019-02-02 19:03:43   relay_0         off
     2019-05-27 19:30:03   state           on
Attributes:
   group      Licht_Nebenraeume
   icon       taster@black
   interval   10
   model      shelly1
   room       Shelly


Der Shelly 1 ist immer auf on und versorgt ein OSRAM-Lightify mit Strom. Die Internals von der Lightify-Leuchte lauten:

   CHANGED   
   DEF        DFA4050000261884  IODev=Lightify
   FUUID      ****...
   FVERSION   31_HUEDevice.pm:0.192010/2019-04-16
   ID         ****...
   INTERVAL   
   IODev      Lightify
   NAME       LIGHTIFYDFA4050000261884
   NR         742
   STATE      dim06%
   TYPE       HUEDevice
   desired    1
   type       Dimmable
   uniqueid   DFA4050000261884
   READINGS:
     2019-05-27 03:36:33   bri             10
     2019-05-24 18:40:35   ct              370 (2702K)
     2019-05-27 19:30:07   onoff           1
     2019-05-27 19:30:07   pct             4
     2019-05-27 03:36:31   reachable       1
     2019-05-27 19:30:07   state           dim06%
   helper:
     alert     
     bri        10
     colormode 
     ct         370
     devtype   
     effect     
     hue        -1
     on         1
     pct        4
     reachable  1
     rgb       
     sat        -1
     transitiontime 0
     type       4
     update_timeout 1
     xy         
Attributes:
   IODev      Lightify
   alias      Ankleide
   color-icons 2
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   group      Licht_Nebenraeume
   icon       light_control@orange
   mqttDefaults pub:qos=0 sub:qos=2 retain=0
   mqttPublish *:topic=Lichter/Ankleide
   mqttSubscribe state:stopic=Lichter/Ankleide/set
   room       Allgemein,LIGHTIFY
   subType    dimmer
   webCmd     pct:on:off


Folgendes DOIF soll die OSRAM-Lightify anschalten beim Betreten des Ankleide-Zimmers:

([Sensor_Ankleide_Schrank] eq "open" and [Motion_Sensor_1:reportedState] eq "open" and [Motion_Sensor_1:luminance:d]<50) (set LIGHTIFYDFA4050000261884 on)


Motion_Sensor_1 ist ein ZWave https://www.fibaro.com/de/products/motion-sensor/ .

Nun zu meinem Problem:

Ich habe ständig Probleme mit der Netzwerkverbindung zum Shelly_1. Ich habe ein FileLog_Ankleide_Taster erstellt und erhalte folgende Log's:

2019-05-26_09:54:49 Ankleide_Taster Error
2019-05-26_09:54:49 Ankleide_Taster network: not connected
2019-05-26_09:54:54 Ankleide_Taster network: connected
2019-05-26_09:54:54 Ankleide_Taster on
2019-05-26_09:55:04 Ankleide_Taster Error
2019-05-26_09:55:05 Ankleide_Taster network: not connected
2019-05-26_09:55:10 Ankleide_Taster network: connected
2019-05-26_09:55:10 Ankleide_Taster on
2019-05-26_09:58:50 Ankleide_Taster Error
2019-05-26_09:58:51 Ankleide_Taster network: not connected
2019-05-26_09:59:04 Ankleide_Taster Error
2019-05-26_09:59:04 Ankleide_Taster network: not connected
2019-05-26_09:59:13 Ankleide_Taster Error
2019-05-26_09:59:13 Ankleide_Taster network: not connected
2019-05-26_09:59:22 Ankleide_Taster Error
2019-05-26_09:59:23 Ankleide_Taster network: not connected
2019-05-26_09:59:32 Ankleide_Taster Error
2019-05-26_09:59:32 Ankleide_Taster network: not connected
2019-05-26_09:59:38 Ankleide_Taster network: connected
2019-05-26_09:59:38 Ankleide_Taster on
2019-05-26_10:06:11 Ankleide_Taster Error
2019-05-26_10:06:12 Ankleide_Taster network: not connected
2019-05-26_10:06:21 Ankleide_Taster network: connected
2019-05-26_10:06:21 Ankleide_Taster on
2019-05-26_10:32:06 Ankleide_Taster Error
2019-05-26_10:32:06 Ankleide_Taster network: not connected
2019-05-26_10:32:16 Ankleide_Taster Error
2019-05-26_10:32:16 Ankleide_Taster network: not connected
2019-05-26_10:32:25 Ankleide_Taster Error
2019-05-26_10:32:25 Ankleide_Taster network: not connected
2019-05-26_10:32:33 Ankleide_Taster network: connected
2019-05-26_10:32:33 Ankleide_Taster on
2019-05-26_10:32:43 Ankleide_Taster Error
2019-05-26_10:32:43 Ankleide_Taster network: not connected
2019-05-26_10:32:52 Ankleide_Taster Error
2019-05-26_10:32:52 Ankleide_Taster network: not connected
2019-05-26_10:32:58 Ankleide_Taster network: connected
2019-05-26_10:32:58 Ankleide_Taster on
2019-05-26_11:17:58 Ankleide_Taster Error
2019-05-26_11:17:58 Ankleide_Taster network: not connected
2019-05-26_11:18:07 Ankleide_Taster Error
2019-05-26_11:18:07 Ankleide_Taster network: not connected
2019-05-26_11:18:16 Ankleide_Taster Error
2019-05-26_11:18:16 Ankleide_Taster network: not connected
2019-05-26_11:18:26 Ankleide_Taster Error
2019-05-26_11:18:26 Ankleide_Taster network: not connected
2019-05-26_11:18:35 Ankleide_Taster Error
2019-05-26_11:18:35 Ankleide_Taster network: not connected
2019-05-26_11:18:44 Ankleide_Taster Error
2019-05-26_11:18:44 Ankleide_Taster network: not connected
2019-05-26_11:18:52 Ankleide_Taster Error
2019-05-26_11:18:52 Ankleide_Taster network: not connected
2019-05-26_11:18:58 Ankleide_Taster network: connected
2019-05-26_11:18:58 Ankleide_Taster on
2019-05-26_11:36:44 Ankleide_Taster Error
2019-05-26_11:36:44 Ankleide_Taster network: not connected
2019-05-26_11:36:49 Ankleide_Taster network: connected
2019-05-26_11:36:49 Ankleide_Taster on
2019-05-26_17:38:43 Ankleide_Taster Error
2019-05-26_17:38:43 Ankleide_Taster network: not connected
2019-05-26_17:38:55 Ankleide_Taster network: connected
2019-05-26_17:38:55 Ankleide_Taster on
2019-05-26_18:29:08 Ankleide_Taster Error
2019-05-26_18:29:08 Ankleide_Taster network: not connected
2019-05-26_18:29:21 Ankleide_Taster network: connected
2019-05-26_18:29:21 Ankleide_Taster on
2019-05-26_18:29:50 Ankleide_Taster Error
2019-05-26_18:29:50 Ankleide_Taster network: not connected
2019-05-26_18:30:00 Ankleide_Taster network: connected
2019-05-26_18:30:00 Ankleide_Taster on
2019-05-26_22:28:42 Ankleide_Taster Error
2019-05-26_22:28:42 Ankleide_Taster network: not connected
2019-05-26_22:28:53 Ankleide_Taster network: connected
2019-05-26_22:28:53 Ankleide_Taster on
2019-05-27_07:56:04 Ankleide_Taster Error
2019-05-27_07:56:04 Ankleide_Taster network: not connected
2019-05-27_07:56:14 Ankleide_Taster network: connected
2019-05-27_07:56:14 Ankleide_Taster on
2019-05-27_08:27:05 Ankleide_Taster Error
2019-05-27_08:27:05 Ankleide_Taster network: not connected
2019-05-27_08:27:41 Ankleide_Taster Error
2019-05-27_08:27:41 Ankleide_Taster network: not connected
2019-05-27_08:28:02 Ankleide_Taster Error
2019-05-27_08:28:02 Ankleide_Taster network: not connected
2019-05-27_08:28:30 Ankleide_Taster Error
2019-05-27_08:28:30 Ankleide_Taster network: not connected
2019-05-27_08:28:41 Ankleide_Taster network: connected
2019-05-27_08:28:41 Ankleide_Taster on
2019-05-27_19:02:35 Ankleide_Taster Error
2019-05-27_19:02:35 Ankleide_Taster network: not connected
2019-05-27_19:02:46 Ankleide_Taster network: connected
2019-05-27_19:02:46 Ankleide_Taster on
2019-05-27_19:07:04 Ankleide_Taster Error
2019-05-27_19:07:04 Ankleide_Taster network: not connected
2019-05-27_19:07:18 Ankleide_Taster network: connected
2019-05-27_19:07:18 Ankleide_Taster on
2019-05-27_19:29:52 Ankleide_Taster Error
2019-05-27_19:29:53 Ankleide_Taster network: not connected
2019-05-27_19:30:03 Ankleide_Taster network: connected
2019-05-27_19:30:03 Ankleide_Taster on


Die Probleme treten immer dann auf, wenn das DOIF etwas abfragt. Also z. B. wenn ich die Ankleide betrete. In dem Moment schaltet sich die Osram–Leuchte an (d. h. das ,,Licht brennt"), obwohl der Sensor_Ankleide_Schrank nicht auf open, sondern auf close steht. D. h. zu den vorgenannten Zeiten mit den Fehlermeldungen

Ankleide_Taster network: not connected

waren die Zeiten,wo jemand die Ankleide betreten hat.

Kann mir jemand weiterhelfen? [Ich hoffe, ich habe das einigermaßen verständlich geschildert.]

Viele Grüße von Frank und danke an ,pah' für das tolle Modul!

CoolTux

Hallo Frank,

Der besseren Lesbarkeit wegen setze bitte Logs und list Ausgaben in Codetags. Das ist die Raute im Texteditor des Forums.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Hauenschild


Prof. Dr. Peter Henning

#276
@Cluni: Muss ich sehen, ob ich das irgendwie abfangen kann. Ab Dienstag wieder, bis dahin wegen 2 BMBF-Deadlines "Land unter".

@Benni: Sehr schön, habe das auch mit readingsProxy gelöst. Geplant ist, solche Proxies durch das Modul selbst anlegen zu lassen.

@hauenschild: Das Abfrageintervall von 10 Sekunden ist zu kurz, die Latenz der Shellys bei den Antworten spielt hier eine Rolle. Macht auch bei den neuen Rückmeldemöglichkeiten nicht wirklich Sinn, würd eich auf 60 Sekunden hochsetzen.

LG

pah

Cluni

Zitat von: Prof. Dr. Peter Henning am 28 Mai 2019, 04:14:34
@Cluni: Muss ich sehen, ob ich das irgendwie abfangen kann. Ab Dienstag wieder, bis dahin wegen 2 BMBF-Deadlines "Land unter".

Keine Panik - das ist ja nichts lebensbedrohendes und schließlich ist das alles hier ja mehr oder weniger Hobby und läuft nebenbei. Beim Skript für die Rollladensteuerung war das damals ja auch nicht anders. Daher bin ich auch recht froh, dass Marko aka Cooltux sich der "Modulifizierung" der Rollladensteuerung angenommen hat. Das hätte ich zeitlich nicht so schnell hinbekommen... ;)

nils_

@pah
nur ne kleinigkeit - mal wieder die cref :)
der link https://commandref.fhem.de/commandref_DE.html#Shelly in die deutsche commandref funktioniert nicht richtig. ich weiß das du aktiv eh nur die englische schreibst, aber falls jemand die übersicht am anfang der cref vor sich hat und zum shelly teil "springen" möchte geht das leider nicht.
wenn ich es richtig sehe fehlt der anker für den link?!
viele Wege in FHEM es gibt!

Prof. Dr. Peter Henning

@Benni: Übrigens ist es viel besser, für die setFn einfach {$CMD." 0"} zu verwenden - dann funktionieren alle SetExtensions...

LG

pah

Benni

Danke Pah!

Ich habe das bei mir umgestellt und auch den Post angepasst.

gb#

Benni

Ich habe mir schon wieder was praktisches zum Shelly dazugebastelt.  ;D

Ich habe mir ein mir ein userreading erstellt, in dem ein Link auf das webUI des Shellys zur Verfügung gestellt wird. Damit kann ich dann direkt aus der Detailansicht des Devices in FHEMWEB auf die Shelly-Weboberfläche springen:

Dazu ein userreading mit folgendem Inhalt:


webUI:.* {ShellyUI($NAME)}


Und die darin aufgerufene Funktion in der 99_myUtils.pm:


sub ShellyUI($) {
my ($name)=@_;

my $tcpip=InternalVal($name,'TCPIP',undef);

return '<html><a href="http://'.$tcpip.'">Shelly\'s WebUI</a></html>' if defined($tcpip);
return 'unknown';
}


Zurückgegeben wird ein HTML-Link (a href), eingebettet in <html>-Tags. Dies wird bei Readings im FHEMWEB vor der Anzeige entsprechend umgesetzt, so dass hier ein funktionierender Link im Reading angezeigt wird (s. Screenshot).

Hinweis für alle ungeduldigen: Die Auswertung des Userreadings erfolgt natürlich erst, wenn (irgend-)ein Event beim Shelly-Device eintrudelt.

@Pah: Den Link könnte man evtl. auch direkt in die Anzeige von TCPIP in FHEMWEB einbauen  ;)

gb#

studiosus12

Hallo
könnte bitte jemand ein Beispiel einer Shelly RGBW2 Definition einstellen ? Bevorzugt über HTTP - MQTT ginge auch..

Danke und Grüße

Hauenschild

#283
Vielen Dank pah! Ich habe das Abfrageintervall auf 60 Sekunden gesetzt:
interval   60

Jetzt funktioniert es einwandfrei.

Prof. Dr. Peter Henning

#284
Zitatkönnte bitte jemand ein Beispiel einer Shelly RGBW2 Definition einstellen ?
Was ist denn daran unklar ? Wenn das Teil im color-Modus ist natürlich


define WZ.Strip Shelly 192.168.0.180
attr WZ.Strip model shellyrgbw
attr WZ.Strip mode color


Das steht auch so in der CommandRef dazu - man muss sie nur l - e - s - e - n
Und wer es komfortabler möchte, setzt noch


attr WZ.Strip stateFormat rgb
attr WZ.Strip WebCmd rgb:rgb ff0000:rgb 98FF23:rgb 0000ff:on:off


LG

pah