Modul 36_Shelly.pm

[UweH]

Hat ein gewisser Herr "F..." seinen geistreichen Beitrag von 17:07 wieder gelöscht oder warum taucht der hier nicht auf? Über seine eigene Dummheit gestolpert?

[Prof. Dr. Peter Henning]

@UweH: Wird wohl - ich habe nichts gesehen...

@det: Sehn wir mal - immer etwas trickreich, Module für Hardware zu entwickeln, die man selbst nicht hat.

LG

pah

[UweH]

Hier...

[Prof. Dr. Peter Henning]

Ach, na ja, der war wenigstens noch witzig - da habe ich schon ganz andere Figuren gehört...


LG

pah

[87insane]

Hallo
Ich habe mir einige Shelly1pm gekauft.
Scheinbar werden die leider noch nicht voll unterstützt.

Wenn ich das attr model nicht setzte kann ich sie nicht schalten aber das Reading Power wird angezeigt.
list

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        192.168.6.146
   DURATION   0
   FUUID      5cc590d1-f33f-a5a6-54e9-4e562db7717387af
   INTERVAL   60
   MOVING     stopped
   NAME       OG1_SZ_Steckdose
   NR         1897
   STATE      OK
   TCPIP      192.168.6.146:80
   TYPE       Shelly
   Helper:
     DBLOG:
       network:
         mylogdb:
           TIME       1556451537.64286
           VALUE      connected
       state:
         mylogdb:
           TIME       1556451537.64286
           VALUE      initialized
   READINGS:
     2019-04-28 13:38:57   cloud           disabled
     2019-04-28 13:38:57   firmware        v1.4.9-switch1pm-hotfix4
     2019-04-28 13:38:57   network         connected
     2019-04-28 13:38:57   overpower_0     0
     2019-04-28 13:38:57   power           4.85
     2019-04-28 13:38:57   relay_0         on
     2019-04-28 13:38:57   state           OK
Attributes:

Sobald ich das attr model auf shelly1 setze kann ich sie zwar schalten aber das Reading Power fehlt.
list:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        192.168.6.146
   DURATION   0
   FUUID      5cc590d1-f33f-a5a6-54e9-4e562db7717387af
   INTERVAL   300
   MOVING     stopped
   NAME       OG1_SZ_Steckdose
   NR         1897
   STATE      OK
   TCPIP      192.168.6.146:80
   TYPE       Shelly
   Helper:
     DBLOG:
       network:
         mylogdb:
           TIME       1556451537.64286
           VALUE      connected
       state:
         mylogdb:
           TIME       1556451537.64286
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2019-04-28 13:38:57   cloud           disabled
     2019-04-28 13:38:57   firmware        v1.4.9-switch1pm-hotfix4
     2019-04-28 13:38:57   network         connected
     2019-04-28 13:38:57   relay_0         on
     2019-04-28 13:38:57   state           OK
Attributes:
   interval   300
   model      shelly1
   room       Obergeschoss 1->Schlafzimmer

Ich hoffe das das Model Shelly1pm nachgepflegt wird.

Gruß
Daniel

https://forum.fhem.de/index.php/topic,94060.msg934240.html#msg934240

Bin gerade dran. An sich wird alles unterstützt, man muss sich nur die Mühe machen und es einbauen bzw. nachvollziehen...

[Prof. Dr. Peter Henning]

Bin gerade dran

An 36_Shelly.pm ?

LG

pah

[87insane]

Nein! Habe auch gesehen, das ich wohl ein wenig durcheinander gekommen bin.

Mein Beitrag bezog sich auf ein Template für MQTT2. Nutze das Modul hier nicht aber ich denke, es kann ja shelly1 einfach erweitert werden. Braucht ihr ggf. Readings/Infos, die ich trotz meines nicht benutzen dieses Moduls, beisteuern kann? Ein Template für MQTT ist so gut wie fertig und Beta-User weiß bescheid. Es geht nur noch um Kleinigkeiten.

[justme1968]

@pah, det.: alexa 'spricht' hsv. mir ist zumindest auf den ersten blick nicht ganz klar wo und warum da rgb ins spiel kommt. im alexa-fhem log sollte zu sehen sein welches event von amazon kommt und welche FHEM kommandos dann ausgelöst werden.

[Prof. Dr. Peter Henning]

Der Knackpunkt ist, dass Alexa-Fhem hier _zwei_ FHEM-Kommandos auslöst, und zwar kurz nacheinander. Zuerst wird der RGB-Wert auf Hue=0°=360°=ff gesetzt, also rgb=ff0000. Und dann kurz danach rgb=ffffff. Und weil das so schnell danach kommt, wird das 2. Kommando eben ignoriert.

Aus meiner Sicht ist das wirklich ein Fehler in Alexa-Fhem, es sollte einfach das erste Kommando entfallen. Wobei ich natürlich nicht ausschließen kann, dass dies schon falsch von Amazon kommt - dann müsste man es irgendwie abfangen.

LG

pah

[gvzdus]

Hi pah, hi det.,

ich möchte mich mal wieder etwas Warmlaufen, nachdem justme nun länger alleine supported hat. Ich hatte mir den ShellyBulb gekauft, und mit MQTT2_SERVER zum Laufen gebracht. Inzwischen geht das auch über 39_Shelly?

Alexa liefert einen HSV-Vektor. Das Ganze ist obendrein hässlich, weil es in der Doku zudem heißt:

Important: The brightness value of a SetColor directive will align to the customer's requested color, however, for the best customer experience when you make a color change, you should maintain the current brightness setting of the target endpoint. For example, if a bulb is set to white at 50% brightness (0.5), and a customer requests a color change to red, the SetColor directive provides hue, saturation and brightness values of 0,1,1, respectively, which indicates full brightness. In this case, you should ignore the brightness value in the directive, and maintain the current brightness setting of 0.5.

Aber das sind ja Luxusprobleme.

MQTT2_SERVER verliert keine Befehle, also "rot" auf "weiß" klappt mit meinem Shellybulb, aber auch hier werden zwei rgb-Werte nacheinander gesetzt. Und wenn ich die Helligkeit über "Schalte <Licht> auf 80%" ändere, geht mein Weiß auch in ein Rot über.

Lange Rede, kurze Frage: Wird 39_Shelly in Sachen HSV auch korrekt ausschließlich über das Setzen von "rgb" angesprochen? Oder welche Settings werden hier exponiert? Falls ja, dann kann ich mich an beiden Problemchen zugleich versuchen.

[Prof. Dr. Peter Henning]

Ich habe keine Probleme damit, dem Shelly-Modul auch ein "set hsv ..." beizubringen. Die meisten Systeme verwenden dazu zwar eine inkorrekte Umrechnungsfunktion (die richtige kann man in einem meiner Bücher nachlesen...), das ist aber eher unwesentlich.

Die Frage ist nur, ob Alexa-Fhem beim Setzen eines HSV-Wertes tatsächlich nur EINEN Fhem-Befehl abliefert, das muss vorher geklärt werden.

LG

pah

[WhyTea]

Wie heißt gleich das Zauberwort?

LG

pah

Ui, das Zauberwort? 

Ah ich weis! Supercalifragilisticexpialigetisch 

Spaß beiseite. Natürlich war mein Post als Bitte gemeint auch wenn ich lediglich von hoffen schrieb.

[gvzdus]

> Die Frage ist nur, ob Alexa-Fhem beim Setzen eines HSV-Wertes tatsächlich nur EINEN Fhem-Befehl abliefert, das muss vorher geklärt werden.


Nein. Z.Zt. kommen tatsächlich bis zu 3 verschiedene Aufrufe, die sich alle auf den RGB-Wert beziehen. Du hast Recht, dass das unschön ist, und da will ich ran. Wir haben aber diverse Layer:

• Echo-API: HSV-Wert. Weiß erkennt man an S=0. Außerdem mit der Hässlichkeit, dass man "Brightness" bei Erkennen eines Farbwechsels ignorieren und aus der Historie übernehmen soll. Alternativ kommt ein "SetBrightness"-Befehl bei "Schalte Licht auf 40%" rein. Wir sind uns wohl einig: So einen Mist sollte, wenn, dann alexa-fhem ausbügeln
• FHEM-API 1 und 2: 1) ist mod_shelly, 2) ist MQTT_SERVER. Das sollte möglichst gleich sein. Praktischerweise habe ich die Discovery für den ShellyBulb bei MQTT_SERVER implementiert, daher holen mich die eigenen Verbrechen jetzt wieder ein. Unten ein Device-List für meinen ShellyBulb über MQTT_SERVER. Mit der Zielsetzung, dass die FHEM-API gleich sein sollte, egal ob 39_Shelly oder MQTT_SERVER, wäre mir jetzt ein HSV in 39_Shelly nicht lieb.
• Die Shelly-API. Sie hat zwei Eigenarten: Die beiden Modi "white/color" und die Tatsache, dass im Color-Modus mindestens noch "gain" für die Helligkeit gesetzt werden muss. Das gibt meine Implementierung schon mal nicht her - die setzt nur "rgb" - obwohl das API auch noch white und gain hergibt und zumindest ohne gain nicht "richtig" arbeitet.

Das Pferdchen muss also für "sauber" von unten definiert werden, hier: Der Shelly-API. Deswegen hätte ich gerne ein "list device" über 39_Shelly.

Hier der Bulb über MQTT_SERVER:

Code Auswählen Erweitern

Internals:
   CID        shellybulb_3CC533
   DEF        shellybulb_3CC533
   DEVICETOPIC MQTT2_shellybulb_3CC533
   FUUID      5c4d5eff-f33f-8d06-27e7-a9681ec2a8b57c90
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 81
   MQTT2_FHEM_Server_TIME 2019-05-02 00:27:12
   MSGCNT     81
   NAME       MQTT2_shellybulb_3CC533
   NR         211
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-16 12:52:56   blue            0
     2018-12-16 12:52:56   brightness      10
     2018-12-16 12:52:56   effect          0
     2018-12-16 12:52:56   gain            26
     2018-12-16 12:52:56   green           0
     2018-12-16 12:52:56   ison            true
     2018-12-16 12:52:56   mode            white
     2018-12-16 12:52:56   red             128
     2019-05-02 00:27:12   rgb             800000
     2019-05-02 00:27:12   shellies/shellybulb-3CC533/color/0 off
     2019-05-02 00:27:12   state           off
     2019-05-02 00:27:12   status_blue     125
     2019-05-02 00:27:12   status_brightness 51
     2019-05-02 00:27:12   status_effect   0
     2019-05-02 00:27:12   status_gain     26
     2019-05-02 00:27:12   status_green    128
     2019-05-02 00:27:12   status_ison     false
     2019-05-02 00:27:12   status_mode     white
     2019-05-02 00:27:12   status_red      128
     2019-05-02 00:27:12   status_temp     4750
     2019-05-02 00:27:12   status_white    0
     2018-12-16 12:52:56   temp            3890
     2018-12-16 12:52:56   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   alexaName  Licht Kinderzimmer
   genericDeviceType light
   icon       light_control
   readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shellybulb-3CC533/color/0/command off
  on:noArg shellies/shellybulb-3CC533/color/0/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
  temp:colorpicker,CT,3000,10,6500 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/; "shellies/shellybulb-3CC533/color/0/set {\"ison\":true,\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2)."\"blue\":".hex($3) }
   userReadings rgb {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
   webCmd     on:off:brightness:temp:rgb

[justme1968]

@pah: alexa sendet alle drei komponenten in einem event. das lässt sich also als ein kommando an FHEM durchreichen.
            homekit sendet leider drei unabhängige events. die idee wäre hier nach dem ersten event ein paar ms zu warten und alles
            was danach kommt zu einem set zusammen zu fassen.

ich würde ein set <name> hsv <hue> <saturation> <brighness> als standart vorschlagen. mit hue 0..359, saturation und brighness 0..100.

das würde ich so auch für hue devices nachziehen.

technisch müssen wir dann bei alexa-fhem und homebridge-fhem noch eine HSV characteristic einbauen die alexa direkt verwenden kann und homebridge intern auf Hue, Saturation und Brighness mapped. das warten auf folgende events ist aus anderem Grund zum teil schon implementiert. sollte also auch kein problem sein.

damit sollte das problem aus anwender sicht für zu lösen sein.


für die farbtemperatur muss intern berücksichtig werden sowohl die sprach/app seite als auch das fhem device jeweils entweder mit einer farbtemperatur in kelvin/mired als auch mit einem angenäherten RGB wert arbeiten können. es gibt also 4 Kombinationen zu berücksichtigen. das sollt aber so weit fast alles da sein.

[gvzdus]

ich würde ein set <name> hsv <hue> <saturation> <brighness> als standart vorschlagen. mit hue 0..359, saturation und brighness 0..100.

Du bist auf dem FHEM-API-Layer. Was sollte denn dann FHEM im Fall ShellyBulb des tun? Bei "S=0" in den Weißmodus wechseln, sonst in den Farbmodus? Die Shellys sind wirklich fies universell, da sie die beiden Modi haben. Perfekterweise müsste Alexa-seitig auch das ColorTemperatureController-Interface rausgereicht werden, also die Weißtemperatur.