Support-Thread Modul 36_Shelly.pm

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

Vorheriges Thema - Nächstes Thema

gvzdus

Das Reading "firmware" wird aus der JSON-Response update.old_version gebildet, das der verfügbaren neuen Version aus update.new_version

Hier 3 Beispiele:

"update": {
"status": "pending",
"has_update": true,
"new_version": "20210318-141150/v1.10.0-geba262d",
"old_version": "20210115-103659/v1.9.4@e2732e05"
},

"update": {
"status": "pending",
"has_update": true,
"new_version": "20210115-103820/v1.9.4@e2732e05",
"old_version": "20210209-101904/v1.10.0-rc2-g0cf9ee3-heads/v1.10.0-rc2",
"beta_version": "20210209-101904/v1.10.0-rc2-g0cf9ee3-heads/v1.10.0-rc2"
},

"update": {
"status": "idle",
"has_update": false,
"new_version": "20210318-141402/v1.10.0-geba262d",
"old_version": "20210318-141402/v1.10.0-geba262d"
}


Die alte Regel, um daraus etwas "Hübsches" zu machen, war "Nimm den Wert zwischen / und @". Die klappt also nicht mehr...
Mal ein Vorschlag mit Test, der mit dem neuen Format klar kommt:

#!/usr/bin/perl

my @a = ( "20210318-141150/v1.10.0-geba262d",
"20210115-103659/v1.9.4\@e2732e05",
"20210115-103820/v1.9.4\@e2732e05",
"20210209-101904/v1.10.0-rc2-g0cf9ee3-heads/v1.10.0-rc2",
"20210318-141402/v1.10.0-geba262d" );

foreach $firmware ( @a ) {
  print "$firmware  => ";
#  $firmware     =~ /.*\/(.*)\@.*/;
#  $firmware     = $1;
  $firmware     =~ /.*\/(v[0-9.]+(-rc\d|)).*/;
  $firmware     = $1;
  print "$firmware\n";
}

20210318-141150/v1.10.0-geba262d  => v1.10.0
20210115-103659/v1.9.4@e2732e05  => v1.9.4
20210115-103820/v1.9.4@e2732e05  => v1.9.4
20210209-101904/v1.10.0-rc2-g0cf9ee3-heads/v1.10.0-rc2  => v1.10.0-rc2
20210318-141402/v1.10.0-geba262d  => v1.10.0


Prof. Dr. Peter Henning

#16
Hier mal eine Version zum Testen.

1.ShellyUni sollte funktionieren
2. Problem mit dem neuen Firmware-format ist behoben
3. Externe Sensoren (Temperatur und Feuchte) werden ausgelesen und als Reading sangezeigt

LG

pah

gvzdus

#17
Firmwareanzeige funktioniert, Beispiele:

firmware v1.9.4(update needed to v1.9.6) 2021-03-20 19:31:28
firmware v1.10.0-rc5(update needed to v1.10.0) 2021-03-20 19:31:28
firmware v1.10.0 2021-03-20 19:35:19


Ich hatte zunächst einen FHEM-Crash mit folgender Meldung:
Can't use an undefined value as a HASH reference at ./FHEM/36_Shelly.pm line 1248.


Meine Küchen-Perl-Kenntnisse verstehen das Konstrukt
%{$jhash->{'ext_temperature'}}
nicht. Ich habe dann mal auf Verdacht den Abschnitt so gefasst:
  #-- look for external sensors
  if ($jhash->{'ext_temperature'}) {
    my %sensors = %{$jhash->{'ext_temperature'}};
    foreach my $temp (keys %sensors){
      readingsBulkUpdateIfChanged($hash,"temperature_".$temp,$sensors{$temp}->{'tC'});
    }
  }
  if ($jhash->{'ext_humidity'}) {
    my %sensors = %{$jhash->{'ext_humidity'}};
    foreach my $hum (keys %sensors){
      readingsBulkUpdateIfChanged($hash,"humidity_".$hum,$sensors{$hum}->{'hum'});
    }
  }

(Also quasi "ge-if-t"). Damit läuft es. Es werden auch Readings gelesen:

Internals:
   DEF        192.168.0.97
   DURATION   0
   FUUID      600d9340-f33f-8d06-ee79-c87b51dab11457b9
   INTERVAL   600
   NAME       wwvalveshelly
   NR         396
   SHELLYID   shelly1pm-84CCA8ADA7B0
   STATE      on
   TCPIP      192.168.0.97
   TYPE       Shelly
   READINGS:
     2021-03-20 19:31:28   cloud           disabled
     2021-03-20 19:37:08   energy          46.1
     2021-03-20 19:36:54   extTemp_0       42.6
     2021-03-20 19:36:54   extTemp_0f      108.7
     2021-03-20 19:31:34   extTemp_1       42.9
     2021-03-20 19:31:34   extTemp_1f      109.2
     2021-03-20 19:36:49   extTemp_2       31
     2021-03-20 19:36:49   extTemp_2f      87.8
     2021-03-20 19:31:28   firmware        v1.10.0-rc2(update needed to v1.9.4)
     2021-03-20 19:31:22   network         <html>connected to <a href="http://192.168.0.97">192.168.0.97</a></html>
     2021-03-20 19:37:08   power           5.26
     2021-03-20 19:31:28   relay           on
     2021-03-20 19:31:28   state           on
     2021-03-20 19:36:36   temperature_0   42.75
     2021-03-20 19:31:28   temperature_1   42.88
     2021-03-20 19:36:36   temperature_2   31.12
Attributes:
   alexaName  Solarventil
   devStateIcon {my $lderr = ReadingsVal($name,"network","-") !~ /^.*>connected.*/?"10px-kreis-rot":"10px-kreis-gruen"; my $light = ReadingsVal($name,"relay","off"); my $cons = ReadingsVal($name,"power","unknown");my $kwh = sprintf("%.2f kWh", ReadingsVal($name,"energy",0)/1000.0);FW_makeImage($lderr)."<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>$cons W / $kwh</div>"}
   interval   600
   model      shelly1pm


Ein bissel schade: "Ich" als ShellyMonitor schreibe das unter extTemp_0 ... rein, Du unter temperature. Ich habe das "extTemp" (aus der CoIoT-Tabelle von Allterco) deswegen genommen, weil temperature ja bereits die oft nervös machende interne Temperatur ist. "extTemp_0_f" ist hingegen mein Workaround, weil ich alle CoIoT-Werte schreiben wollte. Ich kann mich aber auch nach Dir in ShellyMonitor richten - wir sollten es nur einheitlich halten.

Einen Uni habe ich nicht zur Hand.

Vielen Dank! Georg

bombardi

Zitat von: Prof. Dr. Peter Henning am 20 März 2021, 18:25:00
Hier mal eine Version zum Testen.

1.ShellyUni sollte funktionieren
2. Problem mit dem neuen Firmware-format ist behoben
3. Externe Sensoren (Temperatur und Feuchte) werden ausgelesen und als Reading sangezeigt

LG

pah
Ich würde die Version auch gerne testen, sehe auch die Büroklammer, aber finde nicht wie ich sie runterladen kann.
Ist die wieder zurückgezogen worden ?

Prof. Dr. Peter Henning

#19
HIER - jetzt korrigiert

@gvzus: ich sollte es besser wissen und niemals den Code von anderen einfach übernehmen.

LG

pah

bombardi

Hallo pah,
ich kann bestätigen, das es bei mir mit dieser Version wieder problemlos funktioniert.

Tri

#21
Hallo pah,

bei mir funktioniert auch alles mit der Version vom 21.03.2021 19.15 Uhr. Habe aber nur das getestet, was ich im Einsatz habe und davon nur das, was ich benutze: shelly1 und shellyuni Button

Vielen Dank
Tri

det.

#22
Hallo pah,
funktioniert mit der neuen Version alles, was bei mir an Shelly vorhanden ist - danke! Nur die Kleinigkeit siehe Antwort 8 zeigt sich unverändert.
LG
det.

Prof. Dr. Peter Henning

OK, heißt dass, shellyuni schaltet beide Kanäle korrekt?

An der Einbindung des ADC arbeite ich noch.

LG

pah

bstaeheli

Hallo zusammen

Erstmals vielen herzlichen Dank für das tolle Modul!

Wir setzen hier zu Hause 15 Shelly 2.5 ein um die Jalousien zu steuern, oder Lamellen-Storen wie sie in der Schweiz auch genannt werden. Diese haben den Vorteil, dass man sie etwas schräg stellen kann um zu beschatten, aber doch noch Licht in den Raum lassen kann.

Um den Winkel aber genau einstellen zu können wäre es toll, wenn, im Roller-Mode, beim Befehl "closeD?" und "open" jeweils optional noch eine Duration mitgegeben werden könnte. Bin ich hier richtig um so einen Wunsch zu äussern?

Ich wünsche tolle Ostern und viel Gesundheit,
Boris

Prof. Dr. Peter Henning

Oh, Wünsche kann man viele äußern...

Ich glaube aber nicht, dass das realisierbar ist.

Der Shelly 2.5 hat interne Parameter, die man zwar auch über das Modul einstellen kann, die aber besser verständlich im Web-Frontend des Shelly einstellbar sind. Unter
ZitatSettings->Open/Close Working Time
kann man einstellen, wie viele Sekunden der Motor höchstens laufen muss, bis der Rollladen komplett geschlossen oder komplett geöffnet ist. Der Shelly kann mit
ZitatSettings->Positioning Controls->Calibrate
dazu gebracht werden, diese Werte automatisch zu ermitteln. Dazu wird der Motor betätigt und die Leistung gemessen. Fällt diese auf Null (=Endabschaltung), nimmt der Shelly diese Stellung als Endstellung an.

Wenn man nun
ZitatSettings->Positioning Controls->Enable positioning controls
setzt, benutzt der Shelly 2.5 die Laufzeit im Verhältnis zur maximalen Laufzeit, um seine "Position" zu ermitteln. Damit ist sonnenklar, dass diese Pseudoposition mit der tatsächlichen Rollladenposition nur wenig zu tun hat. Typischerweise ist
Zitatset <device> pct 75
etwa ein halb geschlossener Rollladen. Auch die Wiederholgenauigkeit dieser Positionierung ist eher schlecht.

Auch im Modul gibt es ein Attribut maxtime. Das dient aber nur dazu, weitere Befehle an den Shelly zu blockieren, bis er zur Ruhe gekommen ist.

Nun zu den Lamellen-Stores. Dafür gibt es mindestens drei verschiedene Systeme. Am häufigsten ist m.E. das Folgende:

1. Lamellen komplett geöffnet
2. Schiebe Lamellen zu 50% über das Fenster (beispielsweise)
3. Um die Lamellen selbst zu verstellen, gib einen kurzen (!) Fahrbefehl in Richtung Öffnung.

Das lässt sich ohne Änderung am Modul problemlos mit einem DOIF oder etwas Perl-Code realisieren:

1. Speichere den gegenwärtigen Wert G (sagen wir 100 = komplett geöffnet) und den Zielwert Z (sagen wir 50)
2. set <device> pct Z
3. warte ein paar Sekunden, die Wartezeit ist auch genauer bestimmbar
4 set <device> pct Z-5

Den Wert G braucht man, weil eventuell ja auch G kleiner als Z sein kann - dann wird es etwas komplizierter.

Der langen Rede kurzer Sinn: Mit Fahrzeiten werde ich im Modul nicht herumspielen, das kann jeder auf FHEM-Ebene oder auf Perl-Ebene außerhalb des Moduls lösen.

Machbar wäre im Modul höchstens, dass dem pct-Parameter ein Vorzeichen mitgegeben werden kann, das dann als Verstellung relativ zur gegenwärtigen Position interpretiert wird.

LG

pah

bstaeheli

#26
Hallo Pah

Vielen Dank für deine Zeit um die ausführliche Antwort zu formulieren.

Meine Jalousien sind kalibriert, ich löse das Ganze momentan auch mit einem DOIF, indem ich die Jalousien wieder etwas hochfahre um sie schräg zu stellen. Leider ist die Prozent-Skala zu grob. Oft ist die optimale Position zwischen 3 und 4 Prozent.

Bezüglich der Fahrzeiten, vielleicht sprechen wir nicht vom Gleichen. Ich meine den Parameter "duration", der dem Fahrbefehl zusätzlich angehängt werden kann. (https://shelly-api-docs.shelly.cloud/#shelly2-5-roller-index).

Gemäss oben verlinkter Dokumentation ist dieser Parameter, wenn nicht angegeben, die eingerichtete maximale Fahrzeit, kann aber für den aktuellen, gerade zu sendenden Befehl, angepasst werden.

Beispiel:
http://shelly/roller/0?go=open&duration=1.2

Das funktioniert, getestet mit CURL, sehr gut und erlaubt eine präzise Lamellen-Justierung.

Natürlich kann ich eine eigene Perl-Funktion schreiben, mit der ich diesen Befehl schicken kann. Ich dachte mir, dass vielleicht auch Andere davon profitieren könnten. Mir schwebt ein optionaler Parameter beim "close" und "open" Befehl vor. Ähnlich der Ramp-Time bei gut implementierten Beleuchtungsmodulen. Oder ein neuer Befehl wie z.b. "drive-up-for"

LG Boris

gvzdus

Ich wäre auch ein glücklicher Nutzer: Gleiche Situation, was die Jalousie betrifft.

Prof. Dr. Peter Henning

Hmm, das mit dem duration-Parameter ist irgendwann in den letzten Firmware-Versionen neu hinzugekommen.

Mal sehen, ob ich das einbauen kann.

LG

pah

Prof. Dr. Peter Henning

Ich habe eine neue Version eingecheckt, die einen optionalen Parameter für die Befehle "set open" und "set closed" akzeptiert.

LG

pah