Dieser Thread dient der Diskussion des Moduls 36_Shelly.pm. Wer es nicht nutzen will, soll es bitte einfach sein lassen und sich entsprechender Äußerungen enthalten.
Eine weitere Dokumentation findet sich im Wiki https://wiki.fhem.de/wiki/Modul_Shelly
LG
pah
Hallo zusammen,
mir ist eben aufgefallen, das der "toggle" Befehl unter FHEM in den Shelly Device nicht mehr richtig funktioniert, er schaltet die Lampe an, aber nicht wieder aus wenn sie an ist 🤔 Im Event-Monitor sehe ich auch, dass immer nur ein "on" Befehl gesendet wird, ist das bei euch auch so?
Der state im FHEM Device bleibt auch auf OK stehen nach dem umschalten, nur relay_0 ändert von on auf off oder umgekehrt beim on / off schalten
Kann ich nicht bestätigen, funktioniert bei mir problemlos.
Um welchen Shelly-Typ handelt es sich?
LG
pah
P.S.: Bitte immer mit Listings in Code-Tags arbeiten, nicht mit Screenshots.
Geht in dem Beispiel um den Shelly 1...
Hall und erstmal vielen Dank für das Modul! Kam mir wie gerufen, da ich erst jetzt mit ein paar neuen Shelly (1 V3) anfange zu spielen. Deren Firmware scheint mir (auch ohne Tasmota) ziemlich ausgereift und funktionell (Cloud Voreinstellung deaktiviert). Nun meine Fragen,
1. Wie bekomme ich die Geräte ins Alexa?
Stand:
* Steuerung in fhem und Status-Abfrage via Poll funktioniert
* Statusanzeige via http-Aktion vom Shelly ebenfalls
Gerät ist mit Raumname, Modell und genericDeviceType konfiguriert und Status "on", "off" sollten ausreichend sein:
Internals:
CFGFN
DEF 192.168.178.139
FUUID 6028569c-f33f-bea7-b902-b740620a27e3b278
INTERVAL 60
NAME Fackellampe
NR 16795
STATE Error
TCPIP 192.168.178.139
TYPE Shelly
Helper:
DBLOG:
firmware:
logdb:
TIME 1613256356.9219
VALUE 1047-long-id-for-shelly-devices(update needed to v1.9.4)
state:
logdb:
TIME 1613291674.00212
VALUE off
READINGS:
2021-02-13 23:45:56 cloud disabled
2021-02-13 23:45:56 firmware 1047-long-id-for-shelly-devices(update needed to v1.9.4)
2021-02-14 09:35:47 network not connected
2021-02-14 00:52:10 relay off
2021-02-14 09:35:47 state Error
Attributes:
event-on-change-reading .*
genericDeviceType light
model shelly1
room Wohnzimmer
timeout 10
2. Es gibt immer mal Errors im Log, darum habe ich Timeout auf 10 erhöht (dem Grund muss ich noch nachgehen), hat jemand ein Tipp vom vorgehen?
Im Log auf verbose 5 klappt es die eine Minute und die nächste eben nicht. Wie oft wird denn versucht den Status zu bekommen in einem Intervall? Wie bei einem Ping 4 mal standardmäßig?
2021.02.14 09:43:31 5: [Shelly_status] Issue a non-blocking call to http://192.168.178.139/status
2021.02.14 09:43:35 5: [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"Theon","ip":"192.168.178.139","rssi":-67},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"09:43","serial":1,"has_update":true,"mac":"483FDA8DA73F","relays" :[{"ison":false, "has_timer":false}],"meters":[{"power":0.00,"is_valid":"true"}],"inputs":[{"input":1}],"ext_temperature":{},"update":{"status":"pending","has_update":true,"new_version":"20210115-102904/v1.9.4@e2732e05","old_version":"20191217-140757/1047-long-id-for-shelly-devices@a0661583"},"ram_total":50960,"ram_free":40392,"fs_size":233681,"fs_free":173943,"uptime":39700}
2021.02.14 09:44:33 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 536338) line 1.
2021.02.14 09:44:36 5: [Shelly_status] Issue a non-blocking call to http://192.168.178.139/status
2021.02.14 09:44:48 1: [Shelly_status] has error connect to http://192.168.178.139:80 timed out
2021.02.14 09:45:49 5: [Shelly_status] Issue a non-blocking call to http://192.168.178.139/status
2021.02.14 09:46:00 1: [Shelly_status] has error connect to http://192.168.178.139:80 timed out
2021.02.14 09:47:00 5: [Shelly_status] Issue a non-blocking call to http://192.168.178.139/status
2021.02.14 09:47:05 5: [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"Theon","ip":"192.168.178.139","rssi":-69},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"09:47","serial":1,"has_update":true,"mac":"483FDA8DA73F","relays" :[{"ison":false, "has_timer":false}],"meters":[{"power":0.00,"is_valid":"true"}],"inputs":[{"input":1}],"ext_temperature":{},"update":{"status":"pending","has_update":true,"new_version":"20210115-102904/v1.9.4@e2732e05","old_version":"20191217-140757/1047-long-id-for-shelly-devices@a0661583"},"ram_total":50960,"ram_free":40392,"fs_size":233681,"fs_free":173943,"uptime":39909}
2021.02.14 09:48:07 5: [Shelly_status] Issue a non-blocking call to http://192.168.178.139/status
2021.02.14 09:48:18 1: [Shelly_status] has error connect to http://192.168.178.139:80 timed out
Grüße
Zu 1.: gehört nicht (wirklich) hier her. Und sollte alles im alexa-fhem Connector Wiki stehen. Das wichtigste hast du vergessen: alexaName zu vergeben (sofern alexa-fhem Connector und nichts am "Filter" in der cfg verändert wurde)... https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa
EDIT: zu 2. soweit mir bekannt ist das "Standard-Poll-Untervall": 60s... Und es wird (soweit ich weiß) nur 1x "gepollt"... Nicht mehrmals (alle Minute)...
Gruß, Joachim
Danke für den Hinweis. alexaName hatte ich glatt übersehen :-/
Hallo pah,
nach langer Zeit ist das siehe unten immer noch offen - und es sind alle Attribute richtig gesetzt. Vieleicht findst Du eine Lösung für den Schönheitsfehler?
Danke021.02.21 23:25:10 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw|shellybulb
2021.02.21 23:25:10 1: [Shelly_Attr] setting the maxtime attribute only works for model=shelly2/2.5 and mode=roller
2021.02.21 23:25:10 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw|shellybulb
2021.02.21 23:25:10 1: [Shelly_Attr] setting the maxtime attribute only works for model=shelly2/2.5 and mode=roller
2021.02.21 23:25:09 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw|shellybulb
2021.02.21 23:25:09 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw|shellybulb
2021.02.21 23:25:09 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw|shellybulb
2021.02.21 23:25:09 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw|shellybulb
mein Zoo:
192.168.2.235 Shelly_1G shelly2.5 relay
192.168.2.236 Shelly_TV shelly2.5 relay
192.168.2.237 Rollo_WZ_vorn_links shelly2.5 roller
192.168.2.238 Rollo_WZ_vorn shelly2.5 roller
192.168.2.239 Shelly_1H shelly2.5 relay
192.168.2.240 Shelly_1A shelly1
192.168.2.241 Shelly_1B shelly1
192.168.2.242 Shelly_1C shelly1
192.168.2.243 Shelly_1D shelly1
192.168.2.244 Shelly_1E shelly1pm
192.168.2.245 Shelly_1F shelly1pm
192.168.2.246 Shelly_RGBW_Bad shellyrgbw color
192.168.2.247 TVBacklight shellyrgbw color
192.168.2.251 StripeColor shellyrgbw color
Hallo,
ich möchte gerne das Shelly Modul "Shelly UNI" einsetzen. Das hat den Vorteil, daß es mit 12-36V DC oder AC Versorgungsspannung läuft. Es unterstützt 2 Taster/Schalter Eingänge zusätzlich bis zu 3 Temperatur Sensoren 18B20 einen AD Wandler DC 1-30V und hat 2 Ausgänge (AC 24C /DC 36V)
Es ist das ideale Modul zur Verwendung im Wohnwagen/Wohnmobil (ist zwar kein Haus - aber auch ein zu Hause ;D)um zusätzlich zur 230V Technik die 12 V Technik abzudecken. Temperaturen, Füllstände, Signale Batterie Ladung usw.
Aber auch zu Hause , z.Bsp bei einem Torantrieb, ist das kleine Ding recht nützlich. Da die Torsteuerungen auch im 12 -24 V Bereich laufen, kann auch hier schnell und einfach Endschalter Stellungen (Tor auf oder zu) in FHEM protokolliert werden. Auch das öffnen und schließen ist dann durch das Anschließen von den offenen Schaltausgängen an die 24 V Torsteuerung möglich.
Leider finde ich dieses Modul nicht in der Shelley Model Auswahl beim FHEM Shelley Modul. Kann dieses Model mit aufgenommen werden ? Das Protokoll ist ja alles das Gleiche, nur es sind andere Ein/Ausgange vorhanden.
Danke für die Unterstützung
Gruß Mopedpaul
Das Problem ist immer, etwas für Hardware zu testen, die man selbst nicht hat ...
1. Schritt: Einfach mal in einer Kopie des 36_Shelly.pm in den Hash ab Zeile 11 einfügen:
Zitat"shellyuni" => [2,0,0,1],
2. Schritt: Testen, was damit angezeigt bzw. gesteuert wird. idealerweis schaltet die Kiste schon, und wenn der A/D-Wandler wie ein Leistungsmessgerät abgefragt wird, kommt auch das schon an.
3. Schritt: genau dokumentieren, wie das hier:
https://shelly-api-docs.shelly.cloud/#shelly-uni
von einem Shelly 2 abweicht.
Bezüglich der Temperatursensoren: Das ist in Arbeit.
LG
pah
Hallo,
habe das heute mal ausprobiert. Das erste Relais (Kanal 0) wird geschaltet, alles weitere ohne Funktion.
Schalter/Taster Eingang 1 und 2 ohne Funktion
AD Wandler ohne Funktion (Wird auch nicht bei den Leistungsmessungen angezeigt)
Alle 3 möglichen Externen Temp Sensoren werden nicht angezeigt.
Konfiguration habe ich ausgelesen und als JSON Datei angehängt
Gruß Mopedpaul
Hallo zusammen,
ich hätte 2 Anmerkungen und Fragen zum Shelly Modul.....
1)
Ich benutze Shelly's 2.5 als Wechselschalter. Alles funktioniert tadellos. Ich hatte früher andere Wechselschalter, daher
war an verschiedenen Punkten ein on-for-timer gesetzt....
Wenn dieser Befehl auf die Shelly's losgelassen wird (in der Weboberfläche gibt es ja auch in der Combobox das on-for-timer),
dann kommt eine Fehlemeldung im Log:
[Shelly_onoff] returns with problem, timer not set
ABER.... nach der agegebene Zeit geht die Lampe trotzdem aus.....
Deshalb.... wo steckt der Fehler , oder ist die Log Ausgabe schlicht falsch ?!
2)
Beim Reboot kommen immer die Fehlermeldungen (ist schon von "det." beschrieben, aber da Februar, wollte ich es nochmals ansprechen):
2021.03.15 07:30:27 1: [Shelly_Attr] setting the maxtime attribute only works for model=shelly2/2.5 and mode=roller
2021.03.15 07:30:27 1: [Shelly_Attr] setting the mode attribute only works for model=shelly2|shelly2.5|shellyrgbw|shellybulb
Alles steht richtig ein. Ich glaube, dass das die Reihenfolge (alphabetisch) ist, mit der die Attribute gesetzt werden nach einem Reboot.
Da Mode immer vor Model gesetzt wird, kommt der Fehler (so vermute ich)
Am Ende sind aber beide Attribute im Device drin...
VG
mcfly
Muss ich mir ansehen. Kann aber ein paar Tage dauern, wir haben gerade Semesterbeginn.
LG
pah
Hallo,
ich habe heute begonnen das aktuelle Update 1.10 einzuspielen.
Dabei ist mir aufgefallen, dass das reading Firmware nicht mehr aktualisiert wird.
Also zum testen meinen Shelly 1 auf 1.9.3 downgegraded und Firmware liefert v1.9.3(update needed to v1.9.3).
Danach Downgrade auf 1.9.0 und Firmware liefert v1.9.0(update needed to v1.9.0).
und mit /status abfragen
Ergebnis:
wifi_sta
connected true
ssid "AK58K"
ip "192.168.0.30"
rssi -55
cloud
enabled false
connected false
mqtt
connected false
time "07:29"
unixtime 1616138948
serial 3
has_update true
mac "CC50E350053B"
cfg_changed_cnt 0
actions_stats
skipped 0
relays
0
ison false
has_timer false
timer_started 0
timer_duration 0
timer_remaining 0
source "http"
meters
0
power 0
is_valid true
inputs
0
input 1
event "L"
event_cnt 1
ext_sensors {}
ext_temperature {}
ext_humidity {}
update
status "pending"
has_update true
new_version "20210318-135942/v1.10.0-geba262d"
old_version "20201124-091217/v1.9.0@57ac4ad8"
ram_total 50736
ram_free 38032
fs_size 233681
fs_free 143572
uptime 50
Nochmal update auf 1.10 und mit /status abfragen
Ergebnis:
wifi_sta
connected true
ssid "AK58K"
ip "192.168.0.30"
rssi -55
cloud
enabled false
connected false
mqtt
connected false
time "07:22"
unixtime 1616134928
serial 1
has_update false
mac "CC50E350053B"
cfg_changed_cnt 0
actions_stats
skipped 0
relays
0
ison false
has_timer false
timer_started 0
timer_duration 0
timer_remaining 0
source "input"
meters
0
power 0
is_valid true
inputs
0
input 1
event ""
event_cnt 1
ext_sensors {}
ext_temperature {}
ext_humidity {}
update
status "idle"
has_update false
new_version "20210318-135942/v1.10.0-geba262d"
old_version "20210318-135942/v1.10.0-geba262d"
ram_total 50224
ram_free 38216
fs_size 233681
fs_free 147839
uptime 412
Nach dem update auf 1.10 ist das Firmware Reading v1.9.0
Ich habe dieses verhalten auch bei anderen Typen bemerkt. (Version ist 3.0)
Die Firmware meiner RGBW2 wird jetzt als RGBW angegeben.
Meine PlugS und Plug liefern jetzt als Firmwareversion 4 (vorher version 1.9.4)
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
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
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
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 ?
HIER - jetzt korrigiert
@gvzus: ich sollte es besser wissen und niemals den Code von anderen einfach übernehmen.
LG
pah
Hallo pah,
ich kann bestätigen, das es bei mir mit dieser Version wieder problemlos funktioniert.
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
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.
OK, heißt dass, shellyuni schaltet beide Kanäle korrekt?
An der Einbindung des ADC arbeite ich noch.
LG
pah
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
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
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
Ich wäre auch ein glücklicher Nutzer: Gleiche Situation, was die Jalousie betrifft.
Hmm, das mit dem duration-Parameter ist irgendwann in den letzten Firmware-Versionen neu hinzugekommen.
Mal sehen, ob ich das einbauen kann.
LG
pah
Ich habe eine neue Version eingecheckt, die einen optionalen Parameter für die Befehle "set open" und "set closed" akzeptiert.
LG
pah
Hallo PAH,
wollte nochmal antriggern:
Zitat
1)
Ich benutze Shelly's 2.5 als Wechselschalter. Alles funktioniert tadellos. Ich hatte früher andere Wechselschalter, daher
war an verschiedenen Punkten ein on-for-timer gesetzt....
Wenn dieser Befehl auf die Shelly's losgelassen wird (in der Weboberfläche gibt es ja auch in der Combobox das on-for-timer),
dann kommt eine Fehlemeldung im Log:
Code: [Auswählen]
[Shelly_onoff] returns with problem, timer not set
ABER.... nach der agegebene Zeit geht die Lampe trotzdem aus.....
Deshalb.... wo steckt der Fehler , oder ist die Log Ausgabe schlicht falsch ?!
VG
mcfly
Liegt irgendwo im Todo-Stack. Wenn die Funktion gegeben ist, drängt es halt nicht so.
Ersaufe gerade in Arbeit.
LG
pah
Servus...
alles klar... uind nicht ersaufen....
VG
mcfly
Hallo pah,
danke für das Modul!
Soweit ich die ref verstehe sollte ich auch ein ShellyDoorWindow Modul als unabhängigen Sensor in FHEM einbinden können, oder?
Ich habe das Modul als "model generic" angelegt und dachte ich könnte jetzt mit
http://<FHEM IP address>:<Port>/fhem?XHR=1&cmd=set%20<Devicename>%20button_on%20[<channel>]
einen Button erzeugen den ich dann weiter nutzen kann.
Ich sehe aber kein "Button" reading des Device??
Gibt es irgendwo eine Anleitung was ich tun muss?
Danke!
VG tiede
Hallo, ich habe jetzt auch ein ShellyDoorWindow2 Modul in Betrieb genommen. Das Gerät wurde mit dem shellmon angelegt. Es gibt ein dwlsOpened reading, der anscheinend den Status vom Fensterkontakt enthält. Die Temperatur und Leuchtstärke sowie der Winkel sind auch zu sehen. Dir Temperatur musste ich um 5K korrigieren, diese Messung scheint nicht sehr zuverlässig zu sein, mal sehen.
N.
Hallo,
hat schon jemand die versucht einen Shelly Motion in FHEM einzubinden?
Falls nein, was wäre nötig um diesen ebenfalls zu supporten?
Danke und Grüße
Christian
Es macht überhaupt keinen Sinn, Sensoren über das Modul 36_Shelly.pm einzubinden. Denn die senden asychron, das Modul müsste also dauernd auf Daten lauschen.
Bitte MQTT verwenden.
LG
pah
Hallo PAH,
erstmal danke für das Modul, ich habe damit div. shelly Plugs und shelly 1PM erfolgreich einbinden können. Nun gibt es bei den shelly1PM einen internen Temperatur Sensor. Diese Temperatur würde ich gerne noch als Reading in fhem angezeigt bekommen. Das ist grade dann interessant wenn das shelly1PM in einer Steckdose vom bsplw. Trockner hängt und sich dann auch gerne mal aufheizt. So könnte man die Temperatur in fhem direkt im Auge behalten.
Ich habe mir das 36_shelly.pm modul mal angeschaut und verstanden, dass über die IP/status Seite die JSON ausgelesen wird. Über eben diese Status JSON kommt ebenfalls die Temperatur, hier ein Auszug als Beispiel:
"temperature": 57.16,
"overtemperature": false,
"tmp": {
"tC": 57.16,
"tF": 134.89,
"is_valid": true
},
"temperature_status": "Normal",
Mir mangelt es leider an weiteren Kenntnissen um die betreffende Stelle im Code von 36_Shelly.pm ein zu fügen sodass die Werte als Reading übernommen werden.
Ich sehe auch grade, dass auch die shelly plug s die Temperatur übermitteln. Vielleicht ist das ja ein genereller interner Sensor?
gruß ruN
/edit:
ich habs selbst hin bekommen, ich habe unter
#-- common to all Shelly models
folgendes hinzugefügt:
#-- update internal temperture
my $int_temp = $jhash->{'tmp'}{'tC'};
readingsBulkUpdateIfChanged($hash,"int_temp",$int_temp);
uU ist das ja wert in den Code aufgenommen zu werden?
gruß ruN
Die Frage kam schon vor mehr als einem Jahr auf, ich habe mich dagegen entschieden. Readings gibt es, wenn mit dem Sensor-Zusatz externe Temperatursensoren angeschlossen sind.
LG
pah
Sorry, ich habe diesen Thread irrtümlich unter Anfängerfragen aufgemacht. Also hier noch einmal.
ich habe mir jetzt zum Testen einen neuen Shelly 4PRO-PM zugelegt. Bisher habe ich das in FHEM mit einem HTTPMOD-Modul zur Statusabfrage und einem Dummy-Modul zur Übermittlung der On/Off Befehle realisiert. Es wäre natürlich schön, die neuen Shelly Pro Geräte 1Pro, 2Pro und 4Pro in das Modul 36 zu integrieren. Ist so etwas geplant und wenn ja, wann?
Ich würde, wenn benötigt, auch gerne testen.
Ich gebe hier mal die Ausgabe des Geräts mit http://192.168.x.xxx/rpc/Shelly.GetStatus:
{"ble":{},"cloud":{"connected":true},"eth":{"ip":"192.168.1.175"},"input:0":{"id":0,"state":false},"input:1":{"id":1,"state":false},"input:2":{"id":2,"state":false},"input:3":{"id":3,"state":false},"mqtt":{"connected":false},"switch:0":{"id": 0, "source": "HTTP", "output": true, "apower": 1.163, "voltage": 240.265,"aenergy": {"total":25.365,"by_minute":[3.122,3.032,2.793],"minute_ts":1631976899},"temperature":{"tC":48.6, "tF":119.5}},"switch:1":{"id": 1, "source": "HTTP", "output": true, "apower": 0.000, "voltage": 240.252,"aenergy": {"total":35.903,"by_minute":[8.604,7.454,8.410],"minute_ts":1631976899},"temperature":{"tC":48.6, "tF":119.5}},"switch:2":{"id": 2, "source": "HTTP", "output": true, "apower": 1.319, "voltage": 241.069,"aenergy": {"total":43.217,"by_minute":[15.908,15.684,17.073],"minute_ts":1631976899},"temperature":{"tC":48.6, "tF":119.5}},"switch:3":{"id": 3, "source": "HTTP", "output": true, "apower": 1.153, "voltage": 241.130,"aenergy": {"total":16.794,"by_minute":[0.597,0.597,0.269],"minute_ts":1631976899},"temperature":{"tC":48.6, "tF":119.5}},"sys":{"mac":"84CCA87E3880","restart_required":false,"time":"16:55","unixtime":1631976901,"uptime":73519,"ram_size":234524,"ram_free":118292,"fs_size":474641,"fs_free":319523,"available_updates":{"stable":{"version":"0.8.0"}}},"wifi":{"sta_ip":"192.168.1.176","status":"got ip","ssid":"Eddie-Gaas-IoT","rssi":-35}}
Der Schaltbefehl wäre:
http://192.168.x.xxx/rpc/Switch.Set?id=0|1|2|3&on=true|false
ZitatEs wäre natürlich schön, die neuen Shelly Pro Geräte 1Pro, 2Pro und 4Pro in das Modul 36 zu integrieren
Soso.
pah
Hallo zusammen,
ich betreibe seit einiger Zeit einen Shelly RGBW2 mit dem Modul 36_Shelly. FHEM und alle Module auf dem neuesten Stand.
Seit einiger Zeit funktioniert:
set Kueche2 rgbw 660000000
nicht mehr. Dagegen funktioniert folgender Code:
set Kueche2 rgbw 880000000
Ich habe ein wenig mit den Werten herumgespielt. Werte kleiner 88 funktionieren nicht größere dagegen funktionieren.
Gab es an dieser Stelle ein Update oder hat sich da etwas geändert?
Ich bin für jeden Hinweis dankbar.
Gruß
Mario
Nein, da hat sich nichts geändert. Die Fehlerbeschreibung "funktioniert nicht" ist nicht sehr erhellend.
Ich tippe deshalb auf einen einfachen Eingabefehler, denn der Parameter muss ein 8-stelliger Hexadezimalcode sein, nicht wie oen ein neunstelliger Code.
LG
pah
Hallo zusammen,
nachdem ich hier schon mehrere shelly 1 seit Ewigkeiten mit dem genialen Shelly Modul am laufen habe, scheitere ich nun am shelly 2.5.
Dachte mir, "wird ziemlich so sein wie der shelly 1"....
Irgendwie scheitere ich noch an der Zuweisung der Kanäle. Ich will einfach nur zwei Lampen schalten und dies via Homebridge in Apple Home abbilden.
Aber zuerst muss ich das überhaupt erst einmal in FHEM mittels shelly Modul hinbekommen.
So sieht momentan meine Definition aus:
defmod Kellerspots Shelly 192.168.2.64
attr Kellerspots genericDeviceType light
attr Kellerspots interval 5
attr Kellerspots mode relay
attr Kellerspots model shelly2.5
attr Kellerspots room Kellerappartement,Shelly
setstate Kellerspots OK
setstate Kellerspots 2021-09-26 19:33:51 cloud disabled
setstate Kellerspots 2021-09-26 19:55:15 config mode= [channel ]]
setstate Kellerspots 2021-09-26 20:02:02 energy_0 8.5
setstate Kellerspots 2021-09-26 20:02:02 energy_1 8.6
setstate Kellerspots 2021-09-26 19:33:51 network <html>connected to <a href="http://192.168.2.64">192.168.2.64</a></html>
setstate Kellerspots 2021-09-26 19:42:55 overpower_0 0
setstate Kellerspots 2021-09-26 19:42:55 overpower_1 0
setstate Kellerspots 2021-09-26 20:02:07 power_0 10.75
setstate Kellerspots 2021-09-26 20:02:02 power_1 10.79
setstate Kellerspots 2021-09-26 19:56:29 relay_0 on
setstate Kellerspots 2021-09-26 19:42:55 relay_1 on
setstate Kellerspots 2021-09-26 19:42:55 state OK
Was fehlt bzw.muss ich noch zuweisen?
(Verkabelung ist i.O. - Schalten via Webinterface und Wandschalter funktioniert)
Beste Grüße
Jan
Zitat von: stratege-0815 am 27 September 2021, 15:26:36Was fehlt bzw.muss ich noch zuweisen?
Aus der CRef:
set <name> xtrachannels
create readingsProxy devices for switching device with more than one channel
https://fhem.de/commandref.html#Shelly (https://fhem.de/commandref.html#Shelly)
Zitat von: Frank_Huber am 27 September 2021, 15:39:39
Aus der CRef:
set <name> xtrachannels
create readingsProxy devices for switching device with more than one channel
https://fhem.de/commandref.html#Shelly (https://fhem.de/commandref.html#Shelly)
Genau das war die fehlende Info - da hatte ich wohl Tomaten auf den Augen.
Zitat von: Prof. Dr. Peter Henning am 17 September 2021, 19:25:44
Die Frage kam schon vor mehr als einem Jahr auf, ich habe mich dagegen entschieden. Readings gibt es, wenn mit dem Sensor-Zusatz externe Temperatursensoren angeschlossen sind.
Kann man erfahren, wieso die internen Temperaturen nicht übertragen werden?
Im Shelly Forum schreiben Leute, daß deren Shelly 1 PM selbst ohne Last schon bei 60° interner Temperatur liegen.
Ich denke, daß das schon interessant wäre, wenn man mehrere im Einsatz hat und diese Werte dann vergleichen könnte.
Zitat von: eddie1104 am 18 September 2021, 17:00:53
Es wäre natürlich schön, die neuen Shelly Pro Geräte 1Pro, 2Pro und 4Pro in das Modul 36 zu integrieren.
Da werden die weiteren Plus Geräte schneller verfügbar sein als die Pro.
Der Shelly Plus 1 PM ist wohl auf dem Weg zu mir.
Na, da freue ich mich doch, dass ich endlich etwas zu tun habe und Software schreiben darf für Hardware, die zu anderen Personen unterwegs ist.
Sonst noch Wünsche?
pah
Zitat von: Prof. Dr. Peter Henning am 17 Oktober 2021, 18:05:47
Na, da freue ich mich doch, dass ich endlich etwas zu tun habe und Software schreiben darf für Hardware, die zu anderen Personen unterwegs ist.
Sonst noch Wünsche?
pah
Klar doch: die Sache aus Antwort 8 ist noch offen - das betrifft Hardware die bei Dir im Einsatz ist
Zitat von: Prof. Dr. Peter Henning am 17 Oktober 2021, 18:05:47
Na, da freue ich mich doch, dass ich endlich etwas zu tun habe und Software schreiben darf für Hardware, die zu anderen Personen unterwegs ist.
Sonst noch Wünsche?
Naja, war darauf bezogen, daß die Shelly Plus Geräte jetzt verkauft werden, von den Pro gibts bis jetzt nur den 4er.
Hast du das als persönlichen Angriff angesehen?
Und du hast alle Shellys im Einsatz, die von deinem Modul unterstützt werden?
ZitatKlar doch: die Sache aus Antwort 8 ist noch offen - das betrifft Hardware die bei Dir im Einsatz ist
Habe ich auch kürzlich festgestellt, als ich meinen Shelly UNI in Betrieb genommen habe.
Aber mehr als bitten kann man nicht.
Oh, das steht schon auf der Agenda. Wenn ich neben meinem normalen 40-Stunden Job das hier https://www.learntec.de/de/ und das hier https://delfi-tagung.de/ fertig geplant habe, dieses hier https://www.h-ka.de/die-hochschule-karlsruhe/aktuelles/news/2021/merlot erfolgreich gestartet ist und hier https://www.h-ka.de/ilin/projekte/karl das erste halbe Jahr rum ist, ferner mein neues Buch fertig lektoriert ist und ich meine fällige Steuererklärung abgeschickt habe.
Dann kann ich auch mal wieder etwas für FHEM machen...
LG
pah
Um die Nachricht als "On-Topic" zu tarnen:
Dimitar von Shelly / Allterco hat in seinem Facebook-Post heute Bilder vom "Shelly TRV" - einem Wifi-Heizkörperthermostat von Shelly gezeigt! Da kommt also auch für diesen Problembereich bald was.
Und jetzt greife ich pah voraus: Nein, das wird noch nicht von 36_Shelly.pm unterstützt :-)
Da müssen sie am Design noch etwas zulegen. ;D
Ich habe den neuen 4Pro jetzt bekommen, der wird als Nächstes eingebaut.
LG
pah
Zitat von: gvzdus am 10 November 2021, 17:15:24
Um die Nachricht als "On-Topic" zu tarnen:
Dimitar von Shelly / Allterco hat in seinem Facebook-Post heute Bilder vom "Shelly TRV" - einem Wifi-Heizkörperthermostat von Shelly gezeigt! Da kommt also auch für diesen Problembereich bald was.
Und jetzt greife ich pah voraus: Nein, das wird noch nicht von 36_Shelly.pm unterstützt :-)
Dimitar hat leider nicht verstanden, was eine adaptives Heizungsprofil ist, also werden die das "noch" nicht können.
DAS wäre für mich der einzige Grund gewesen, von Homematic weg zu gehen.
Christian, mein Google spuckt mir für "adaptives Heizungsprofil" nichts Sinnvolles aus. Hättest Du was?
Meine Rückfragen:
- Bitte Ventil-Position auf jeden Fall auslesbar machen
- Idealerweise: Modus 'Öffnungsgrad manuell setzen' vorsehen
wurden positiv beantwortet. Was will man mehr, als ein Ventil, das tut, was man ihm sagt? Okay, okay, Design. Aber wer die Alt-Maxe oder Alt-HMs am Heizkörper hängen hat, kann sich da ja nur verbessern. (Ich selber habe 23 MAXe der "schlanken", billigen Linie).
Ich hatte zuletzt die "dumben" Honeywell HR25.
Da konnte ich entweder klassisch sagen: Stell bitte um 14 Uhr die Heizung so ein, daß ich 21 Grad bekomme.
Oder man konnte die adaptiven Profile aktivieren, da konnte ich sagen: um 15:30 möchte ich 21 Grad im Zimmer haben.
Das hat dann 2-3 Tage gedauert, dann hat der HKT gemerkt, wie schnell er das Zimmer warm bekommt und man hat nie zu früh oder zu spät geheizt.
Verstanden, danke! Das hat auch Homematic IP laut einem Freund.
Aber gerade, wenn dank Wifi kein Funkquota besteht, sollte es ja nicht aufwendig sein, diese nötige Vorlaufzeit selber zu bestimmen und in FHEM abzubilden, da man nicht auf "Automatik im Device" angewiesen ist. (pah: Sorry für's Thread-Kapern)
Dir ist aber schon klar, daß je nach Außentemperatur die Wohnung schneller oder langsamer auskühlt?
Also es macht schon einen Unterschied von der Zeit her, ob du +15 oder - 5 Grad draußen hast.
Und ich fand es halt super angenehm, mich da nicht drum kümmern zu müssen.
Hallo zusammen,
ich habe gerade einen ShellyUni in Betrieb genommen und der läuft auch wunderbar, nur leider wird die per ADC gemessene Spannung nicht im Device als Reading übernommen. Im WebInterface des Shelly ist sie vorhanden. Ist das ggf. gar nicht vorgesehen?
Aktuelle Version des Perl Moduls ist 36_Shelly.pm:v3.3.0-s24222/2021-04-11, sollte also passen. Unten noch die relevanten Daten aus dem Geräte Details.
Grüße
Matthias
DEF 192.168.2.17
DURATION
0
FUUID
619b5e35-f33f-ccbf-92e0-b5a99cbb6a26db9c
FVERSION
36_Shelly.pm:v3.3.0-s24222/2021-04-11
INTERVAL
5
NAME
msdShellyUni1
NR
177
SHELLYID
shellyuni-3C6105E4EE1D
STATE
OK
TCPIP
192.168.2.17
TYPE
Shelly
cloud
disabled
2021-11-22 10:09:09
energy
0
2021-11-22 10:23:55
firmware
v1.11.7
2021-11-22 10:23:55
network
connected to 192.168.2.17
2021-11-22 10:23:52
relay_0
off
2021-11-22 10:23:55
relay_1
off
2021-11-22 10:23:55
state
OK
2021-11-22 10:23:55
interval
5
model
shellyuni
Hallo,
ich habe mir das 36_Shelly.pm mal angeschaut und eine Änderung eingebaut für das Auslesen und Schreiben der per ADC gemessenen Spannung, funktioniert einwandfrei.
Es müssten diese 2 Zeilen Code eingefügt werden in die Sub "Shelly_Status", nach Zeile 1081 (lt. Eclipse):
$voltage = $jhash->{'adcs'}[0]{'voltage'};
readingsBulkUpdateIfChanged($hash,"voltage",$voltage);
Dann natürlich noch $voltage aufnehmen in "my" in Zeile 1060.
Besteht eine Chance, dass das offiziell aufgenommen wird? Ich habe mich bislang noch gar nicht mit den Gepflogenheiten der FHEM (Modul-)Weiterentwicklung beschäftigt. Werden die Module gemeinschaftlich weiterentwickelt? Wie kann man da ggf. einsteigen? Ist es überhaupt üblich für "fremde" Modulen zu (mit-)zu entwickeln?
An dieser Stelle erstmal einen riesigen Dank an pah für dieses Modul!!!
Grüße
Matthias
Before:--------------
readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower)
if(defined($overpower));
if($model =~ /shelly(1|(plug)).*/){
readingsBulkUpdateIfChanged($hash,"state",$ison)
}else{
readingsBulkUpdateIfChanged($hash,"state","OK");
}
}
Before:--------------
Änderung hier einfügen
After:----------------
my $metern = ($model eq "shellyem")?"emeters":"meters";
for( my $i=0;$i<$meters;$i++){
$subs = ($meters == 1) ? "" : "_".$i;
$power = $jhash->{$metern}[$i]{'power'};
$energy = int($jhash->{$metern}[$i]{'total'}/6)/10;
readingsBulkUpdateIfChanged($hash,"power".$subs,$power);
After:----------------
1. Bitte in den Posts die Code-Tages verwenden (Icon #)
2. Werd ich mir bei Gelegenheit ansehen. Keine Zeitangabe möglich - und in derselben Form werde ich es auch nicht übernehmen, weil dann negative Effekte für andere Hardware auftauchen
3.
ZitatIch habe mich bislang noch gar nicht mit den Gepflogenheiten der FHEM (Modul-)Weiterentwicklung beschäftigt.
Na, das kann man ja nachholen.
LG
pah
Moin, Du kannst auch versuchen, das Modul "ShellyMonitor" zu verwenden. Allterco hat den CoIoT-Support doch bis jetzt nicht eingestellt. ShellyMonitor schreibt in angelegte Shelly-Devices automatisch alle Werte rein, die im Netz herumgeschickt werden, also auch Settings, die das Shelly-Modul nicht kennt.
Und die Alternative wäre MQTT.
Shelly (und ShellyMonitor) haben halt den Vorteil, dass man gleichzeitig die Cloud nutzen kann.
Moin,
@pah:
zu 1) OK
zu 2) die gleiche Form hätte ich auch nicht erwartet... :-)
zu 3) das gehe ich dann mal an, sobald Zeit frei wird
@gvzdus:
ShellyMonitor werde ich mal ausprobieren, klingt interessant. Mit den Wolken ist so eine Sache, ich meide sie wo immer es noch geht.
Mit MQTT habe ich mich noch nicht beschäftigt. Hört sich so an, als ob da erstmal die Überwindung einiger Eintritts-Barrieren anstehen würde. Welche Vorteile hätte dieser Ansatz ggb. dem Shelly Modul bzw. Schelly Monitor? Als Nachteil sehe ich, dass man anscheinend zusätzlich erstmal eine Broker Instanz benötigt.
Grüße
Matthias
Hi, die Diskussion Shelly-Modul versus MQTT ist oft im Forum geführt worden und wäre hier sowohl redundant wie auch falsch platziert. Du wirst mit der Suchfunktion oder Google viele Beiträge finden.
Hi,
ok, danke. Über diese Diskussion bin ich noch nicht gestolpert hier im Forum, war mir daher nicht bekannt.
Grüße
Matthias
Moin,
bestehen eigentlich Pläne, die neuen Shelly Plus einzubinden? Wenn es an der HW mangeln sollte - ich würde einen Shellyplus 1 dann zur Verfügung stellen (ich kann selber leider nicht programmieren...), um zumindest auf diese Weise dazu beitragen zu können ;D
Gruß, Christoph
Ich muss demnächst mal einen Bastel-Tag einlegen, ich habe vor mir einen 4pm pro sowie einen 1pm plus, und den Shelly TRV soeben bestellt.
Moin,
ist dann nur noch zu klären, in wieweit der 1plus und der 1pm plus gleich behandelbar sind - mal von Power abgesehen ...
Gruß, Christoph
Ich habe jetzt mal 1-2 h "gespielt". Alles gilt für "Shelly Gen2" - also Plus1, Plus1pm, PlusI4, Pro4 und mutmaßlich TRV.
Die Doku findet sich hier: https://shelly-api-docs.shelly.cloud/gen2/ (https://shelly-api-docs.shelly.cloud/gen2/), und sollte wirklich von oben nach unten gelesen werden.
Was hat sich geändert?
- Shelly wollte aufräumen und hat das recht radikal gemacht
- CoIoT ist tot (ShellyMonitor-Modul als Ergänzung zum Shelly-Modul), live/push-Updates gibt es weiterhin per MQTT oder - neu - per Websocket
- Es ist z.B. jetzt möglich, Shelly-Cloud und MQTT gleichzeitig zu verwenden (übrigens geht auch MQTT über TLS)
Was ergibt sich daraus?
Zwar klappt z.B. noch das "An / Aus" für den Shelly Pro1pm, wenn man Shelly 1pm auswählt. Aber schon das Status-Auslesen funktioniert nicht.
D.h., eigentlich müsste das Shelly-Modul grundsätzlich und tiefgreifend auf Websocket umgeschrieben werden. Dafür spräche aus Nutzersicht, dass das Shelly-Modul (m.E.) immer noch "schöner" in den Readings ist und ein Stückchen einfacher aufzusetzen ist als die Abfolge "MQTT-Server (einmalig) einrichten", MQTT auf dem Shelly zu konfigurieren, neues Device suchen, Attribut-Template anzubinden.
Andererseits: Auch kleine Änderungen am Shelly-Modul haben ja bisher ihre Reifezeit benötigt, und hier geht es um eine größere Änderung.
Soweit zum Stand meines Abendbastelns.
Hmm. Ich habe in den nächsten Wochen wieder einmal viel um die Ohren, und werde zu einer so gigantischen Änderung schwerlich kommen. Ich bin mir auch nicht sicher, ob ich mein zentrales FHEM-System mit einer ganzen Zahl von Websocket-Verbindungen belasten will. Wäre für mich eher ein Grund, das Modul aufzugeben und komplett auf MQTT umzustellen.
LG
pah
Hallo,
an dieser Stelle schon mal danke für die Entwicklung und Wartung dieses Moduls.
Ich habe einen ShellyEM im Einsatz und mir ist aufgefallen, dass die Skalierung des Energiewertes hier nicht in Watt-Minuten (wie bei den bisherigen Shelly-Modellen) sondern in Watt-Stunden zurückgegeben wird. Auf der Weboberfläche ist außerdem der Leistungsfaktor mit dargestellt.
Folgende Code-Anpassungen habe ich zum Test ab Zeile 1082 durchgeführt. Wäre schön wenn sie bei Gelegenheit den Weg in das offizielle Modul finden würden.
my $metern = ($model eq "shellyem")?"emeters":"meters";
for( my $i=0;$i<$meters;$i++){
$subs = ($meters == 1) ? "" : "_".$i;
$power = $jhash->{$metern}[$i]{'power'};
readingsBulkUpdateIfChanged($hash,"power".$subs,$power);
if ($model eq "shellyem") {
my $voltage = $jhash->{$metern}[$i]{'voltage'};
readingsBulkUpdateIfChanged($hash,'voltage'.$subs,$voltage);
my $reactivePower = $jhash->{$metern}[$i]{'reactive'};
my $apparentPower = sqrt( ($power * $power) + ($reactivePower * $reactivePower) );
my $powerFactor = ($apparentPower != 0)?(int($power / $apparentPower * 100) / 100):"0";
readingsBulkUpdateIfChanged($hash,'powerFactor'.$subs,$powerFactor);
$energy = $jhash->{$metern}[$i]{'total'};
}else{
$energy = int($jhash->{$metern}[$i]{'total'}/6)/10;
}
readingsBulkUpdateIfChanged($hash,"energy".$subs,$energy);
}
Grüße, Tobias
Zur Info: Das TRV ist ein Gen1 Device lt. CEO von Allterco.
@TobiL:
ZitatWäre schön wenn sie bei Gelegenheit den Weg in das offizielle Modul finden würden.
Soso. In meinem Universum gibt es dafür ein magisches Wort.
pah
Hallo Forum, hallo pah,
danke für das Modul. Ich habe einen Shelly plus 1 eingebunden und 2 Grundlegende Probleme.
Firmware ist aktuell 0.9.1. FHEM ist ebenso aktuell.
Problem 1:
Der state ist nach connect und nach jedem Schaltvorgang auf error. Der Schaltvorgang wird aber durchgeführt. Rückmeldung ist wieder Error.
Problem 2:
Ich hatte anfangs connectionsprobleme weil ich den shelly mit Passwort gesichert hatte. In der Shelly Konfiguration kann man lediglich ein Passwort setzen.
In der FHEM Modul Konfiguration muss aber Username und Passwort gesetzt werden. Ich habe das ganze jetzt erstmal ohne Passwort laufen. Connection steht damit.
In der commandref konnte ich zu den Themen nichts finden. Liegt das generell an der neueren Shelly Firmware?
Ein Gerätelist hänge ich an:
Internals:
.AttrList
DEF 192.168.1.50
DURATION 0
FUUID 61c86b37-f33f-284d-9b1e-c848039fd6303626
INTERVAL 60
NAME Strom_Strasse
NR 351
STATE Error
TCPIP 192.168.1.50
TYPE Shelly
.attraggr:
.attrminint:
READINGS:
2021-12-26 14:38:51 network <html>connected to <a href="http://192.168.1.50">192.168.1.50</a></html>
2021-12-26 14:39:28 relay off
2021-12-26 14:39:51 state Error
Attributes:
group Außensteckdosen
model shelly1
room Outdoor[ftp][/ftp]
Viele Grüße
Matze
Moin,
das dürfte daran liegen, daß der ShellyPlus zur neuen Generation von Shelly-Devices gehört, und bei denen wird nicht mehr das alte Protokoll unterstützt. Ich habe einen Plus1 mittels mqtt testweise eingebunden, und das funktioniert offenbar gut...
Gruß,
Christoph
gibts dazu einbindungsbeispiele? bzw. kannst du die einstellen?
Da die Geräteanzahl die mittlerweile im Umlauf ist schon recht ordentlich ist, würde sich ein umstieg generell auf mqtt sicherlich lohnen. Bislang habe ich mich mit der Thematik aber noch nicht beschäftigt. Die http abfragen empfand ich immer als sehr einfach umsetzbar.
viele Grüße
Matze
Moin,
ich habe ihn testweise so eingebunden - ist aber zur Zeit deaktiviert, da ich ihn noch nicht weiter verbaut habe, und wenn ich ihn nicht angeschlossen hatte, gab es bei mir freeze im FHEM, der offenbar in meinem Fall auf dieses Device zurück zu führen war.
Internals:
DEVICETOPIC shellyplus1-441793cf9254
FUUID 61b90650-f33f-378b-4430-7ae3b08824eb04ee
FVERSION 10_MQTT2_DEVICE.pm:0.248610/2021-08-20
IODev MQTT2_FHEM_Server
NAME Shelly1plus
NR 1685
STATE off
TYPE MQTT2_DEVICE
JSONMAP:
params_switch_0_aenergy_total aenergy_total
params_switch_0_apower apower
params_wifi_sta_ip ip
temperature_tC temperature
temperature_tF 0
READINGS:
2021-12-26 11:59:03 IODev MQTT2_FHEM_Server
2021-12-14 22:03:02 attrTemplateVersion 20211128
2021-12-16 20:28:53 dst shellyplus1-441793cf9254/events
2021-12-16 20:28:53 method NotifyStatus
2021-12-15 20:40:07 mqtt_connected true
2021-12-16 21:23:27 online false
2021-12-15 20:40:07 params_mqtt_connected false
2021-12-14 22:06:06 params_switch_0_id 0
2021-12-14 22:06:06 params_switch_0_output false
2021-12-14 22:06:06 params_switch_0_source MQTT
2021-12-16 20:28:53 params_sys_available_updates_stable_version 0.9.1
2021-12-16 20:28:53 params_ts 1639682933.11
2021-12-16 20:28:53 src shellyplus1-441793cf9254
2021-12-14 22:06:06 state off
2021-12-14 22:06:06 switch_0_id 0
2021-12-14 22:06:06 switch_0_output false
2021-12-14 22:06:06 switch_0_source MQTT
2021-12-14 22:06:06 switch_0_temperature_tC 52.6
2021-12-14 22:06:06 switch_0_temperature_tF 126.7
2021-12-16 20:28:53 sys_available_updates_stable_version 0.9.1
2021-12-16 20:28:53 sys_cfg_rev 8
2021-12-16 20:28:53 sys_fs_free 237568
2021-12-16 20:28:53 sys_fs_size 458752
2021-12-16 20:28:53 sys_mac 441793CF9254
2021-12-16 20:28:53 sys_ram_free 176696
2021-12-16 20:28:53 sys_ram_size 249416
2021-12-16 20:28:53 sys_restart_required false
2021-12-16 20:28:53 sys_time 20:28
2021-12-16 20:28:53 sys_unixtime 1639682933
2021-12-16 20:28:53 sys_uptime 172812
Attributes:
DbLogExclude .*
autocreate 1
devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot': ReadingsVal($name,'new_fw','false') eq 'true' ? '10px-kreis-gelb' : '10px-kreis-gruen';; $onl = FW_makeImage($onl);; my $light = ReadingsVal($name,'switch_0_output','false') =~ m{false|off}?'off':'on';; $light = FW_makeImage($light);; my $ip = ReadingsVal($name,'ip','none');; qq(<a href="http://$ip"target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>)}
devicetopic shellyplus1-441793cf9254
disable 1
event-on-change-reading state,online,mqtt_connected
icon message_socket
jsonMap params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip
model shellyPlus_1
readingList $DEVICETOPIC/online:.* online
$DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }
$DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }
$DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }
$DEVICETOPIC/status/switch_0:.* { json2nameValue($EVENT, 'switch_0_', $JSONMAP) }
room Entwicklung
setList toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Toggle","params": {"id":0}}
off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":false}}
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":true}}
on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}
x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Shelly.Update","params": {"stage":"stable"}}
x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Shelly.Reboot"}
Gruß, Christoph
PS: ich stehe mit mqtt bisher noch am Anfang, kann also nicht wirklich mit Erfahrungen großartig dienen ...
hmm freezes sind natürlich unschön.
alternativ evtl. espeasy drüber flashen? so habe ich das mit sämtlichen sonoff pendanten gemacht.
Ich mach dazu mal nen extra thread auf um die Übersichtlichkeit nicht zu gefährden
Viele Grüße
Matze
Zitat von: smoudo am 26 Dezember 2021, 14:57:57
... connectionsprobleme weil ich den shelly mit Passwort gesichert hatte. In der Shelly Konfiguration kann man lediglich ein Passwort setzen.
In der FHEM Modul Konfiguration muss aber Username und Passwort gesetzt werden. Ich habe das ...
Der Username wird per Attribut gesetzt.
Grüße
ergerd
Ist fhem seitig schon klar. Ich kann im Shelly aber keinen usernamen angeben. Da kann man nur ein passwort erstellen
Viele Grüße
Matze
ZitatIch kann im Shelly aber keinen usernamen angeben
Wer lesen kann, ist klar im Vorteil:
ZitatDer Username wird per Attribut gesetzt.
Einfach mal die CommandRef ansehen.
LG
pah
Ich glaube wir reden an einander vorbei.
Problem: ich kann in der shelly Geräte Firmware keinen Usernamen hinterlegen.
Passwort schon.
Um in fhem ein Passwort setzen zu können muss ich das attr shellyuser setzen.
Das habe ich auch alles getan. Funktioniert nicht. Fehler: no Connection.
Ist ja auch logisch, da im shelly kein User hinterlegt werden kann.
Bevor ich mich erdreistet habe hier Hilfe zu erbeten habe ich natürlich wie oben beschrieben die Commandref ersucht. Leider konnte ich das Problem so nicht lösen.
Das Problem habe ich jetzt per mqtt gelöst.
Danke für Deine Bemühungen.
Viele Grüße
Matze
Zitat von: Xell1984 am 22 Dezember 2021, 23:34:23
Zur Info: Das TRV ist ein Gen1 Device lt. CEO von Allterco.
Ich habe heute meinen TRV bekommen. Ich schreibe demnächst mal einen Test in einem anderen Thread.
Den Sparring-Partner zum 36_Shelly-Modul, nämlich 36_ShellyMonitor, habe ich angepasst - die Readings kommen entsprechend sinnvoll.
Wenn der Autor, pah, himself überlegt, auf MQTT umzusteigen, ist natürlich 36_Shelly nicht die beste Basis für die Einbindung. Ich mag das Modul weiterhin, weil die Readings & Co. eben sinnvoll angepasst sind, und außerdem MQTT für alle Gen1-Geräte nicht mit der Shelly-Cloud kombiniert werden kann.
Lieber pah: Würdest Du einen Patch für TRV haben und wohlwollend prüfen wollen?
In jedem Fall werde ich zusehen, auch für MQTT ein AttrTemplate zu erstellen.
ZitatDu einen Patch für TRV haben und wohlwollend prüfen wollen?
Mach ich gerne und zeitnah. Ich mag das Modul auch noch, ich habe aber keine Lust, mir auch noch ein halbes Dutzend der neuen Shellys zuzulegen um diese zu testen.
LG
pah
Guten Morgen,
ich habe mir eine Bulb DUO RGBW gegönnt und über das Modul eingebunden.
Internals:
CFGFN
DEF 192.168.2.239
FUUID 61e0fdb2-f33f-8873-1adc-7f291d212cb03754
INTERVAL 60
NAME Bulb1
NR 1525041
SHELLYID shellycolorbulb-E8DB84D30DFD
STATE off
TCPIP 192.168.2.239
TYPE Shelly
OLDREADINGS:
READINGS:
2022-01-14 05:48:25 L-blue 27
2022-01-14 05:48:25 L-green 57
2022-01-14 05:48:25 L-red 69
2022-01-14 05:39:58 L-white 86
2022-01-14 05:36:03 cloud disabled
2022-01-14 05:37:08 config mode=color [channel s]
2022-01-14 05:48:13 energy 0.3
2022-01-14 05:36:03 firmware v1.11.7
2022-01-14 05:36:02 network <html>connected to <a href="http://192.168.2.239">192.168.2.239</a></html>
2022-01-14 05:48:40 power 0
2022-01-14 05:48:25 rgb 45391B
2022-01-14 05:48:40 state off
Attributes:
mode color
model shellybulb
room Shelly
Das funktioniert soweit auch.
Nur leider habe ich seit dem minütliche Warnungen im Log:
2022.01.14 06:11:41 1 : PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4927.
2022.01.14 06:11:41 1 : stacktrace:
2022.01.14 06:11:41 1 : main::__ANON__ called by fhem.pl (4927)
2022.01.14 06:11:41 1 : main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (1224)
2022.01.14 06:11:41 1 : main::Shelly_status called by ./FHEM/36_Shelly.pm (1030)
2022.01.14 06:11:41 1 : main::__ANON__ called by FHEM/HttpUtils.pm (647)
2022.01.14 06:11:41 1 : main::__ANON__ called by fhem.pl (771)
Muss ich da noch etwas zusätzlich einstellen oder habe ich sonst etwas falsch gemacht?
Norbert
Edit 1:
Es funktionieren auch die Definition als model shellyrgbw mit den zusätzlichen readings für energy und power.
Warning bleibt aber unverändert.
Edit 2:
Durch attr Bulb1 interval 0 wird das minütliche Warning unterdrückt.
Es bleibt aber bei einem warning bei Übertragung eines Befehls.
In Zeile 1223 des Moduls steht
Zitatmy $rgb = sprintf("%02X%02X%02X", $red,$green,$blue);
Bitte mal unmittelbar nach dieser Zeile einfügen
ZitatLog 1,"===========> $rgb";
Modul neu laden und Log hier posten.
LG
pah
Hier im Modul steht das zwar in Zeile 1217.
FVERSION
36_Shelly.pm:v3.3.0-s24222/2021-04-11
Im Log-File steht mit der Ergänzung jetzt:
2022.01.14 09:51:00 1: ===========> 070001
2022.01.14 09:51:00 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4927.
2022.01.14 09:51:00 1: stacktrace:
2022.01.14 09:51:00 1: main::__ANON__ called by fhem.pl (4927)
2022.01.14 09:51:00 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (1225)
2022.01.14 09:51:00 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (1030)
2022.01.14 09:51:00 1: main::__ANON__ called by FHEM/HttpUtils.pm (647)
2022.01.14 09:51:00 1: main::__ANON__ called by fhem.pl (771)
2022.01.14 09:51:06 1: ===========> 070001
2022.01.14 09:51:06 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4927.
2022.01.14 09:51:06 1: stacktrace:
2022.01.14 09:51:06 1: main::__ANON__ called by fhem.pl (4927)
2022.01.14 09:51:06 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (1225)
2022.01.14 09:51:06 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (1030)
2022.01.14 09:51:06 1: main::__ANON__ called by FHEM/HttpUtils.pm (647)
2022.01.14 09:51:06 1: main::__ANON__ called by fhem.pl (771)
2022.01.14 09:51:12 1: ===========> 820013
2022.01.14 09:51:12 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4927.
2022.01.14 09:51:12 1: stacktrace:
2022.01.14 09:51:12 1: main::__ANON__ called by fhem.pl (4927)
2022.01.14 09:51:12 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (1225)
2022.01.14 09:51:12 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (1030)
2022.01.14 09:51:12 1: main::__ANON__ called by FHEM/HttpUtils.pm (647)
2022.01.14 09:51:12 1: main::__ANON__ called by fhem.pl (771)
OK, dann habe ich an einer falschen Stelle nachgesehen - mein Modul ist nämlich schon weiter entwickelt ...
Also bitte Folgendes ersetzen:
In Zeile 1224 (alte Zählung, der obige Log-Eintrag kann wieder raus)
ZitatreadingsBulkUpdateIfChanged($hash,"overpower",$overpower);
durch
ZitatreadingsBulkUpdateIfChanged($hash,"overpower",$overpower) if( $overpower);
Offenbar haben die kein Overpower-Reading (mehr?)
LG
pah
Funktioniert, kein warning mehr im Log-File.
Im Web-Interface gibt es in der Tat auch keine Auswahlmöglichkeit mehr für Power (Reiter Safety bei den Plugs).
Danke!
Hi,
ich hatte noch einen Shelly-3EM, den ich einbauen wollte. Am liebsten über das Shelly Modul, da so die Cloud Speicherung erhalten bleibt.
Das ist nun passiert und zur Probe habe ich die Definition vom shellyem im Code von 36_Shelly angepasst.
Zum Auslesen aller drei Messungen reicht das schon:
"shellyem" => [1,0,0,3],
Dazu noch stateformat angepasst und ein userreading für die Summe. Mir reicht das so.
attr MeinShelly3EM userReadings energy_sum:energy.* {(ReadingsVal($name,"energy_0",0))+(ReadingsVal($name,"energy_1",0))+(ReadingsVal($name,"energy_2",0)) },\
power_sum:power.* {(ReadingsVal($name,"power_0",0))+(ReadingsVal($name,"power_1",0))+(ReadingsVal($name,"power_2",0)) }
attr MeinShelly3EM stateFormat {my $state = lc ReadingsVal($name, "relay", "off");;\
my $devStateIcon = 'black_Steckdose.on.png';;\
if ($state eq "off")\
{\
$devStateIcon = 'black_Steckdose.off.png';;\
}\
"<div><img width='25px' height='25px' src='/fhem/images/default/" . $devStateIcon . "'>" . sprintf(" ; ;\
[L1 Verbrauch: %.1f W / Total: %.1f kWh]<br> ; ; ; ; ; ; ; ; ;\
[L2 Verbrauch: %.1f W / Total: %.1f kWh]<br> ; ; ; ; ; ; ; ; ; ;\
[L3 Verbrauch: %.1f W / Total: %.1f kWh]<br> ; ;\
[Summe: %.1f W / Total: %.1f kWh]",\
ReadingsVal($name,"power_0",0),\
ReadingsVal($name,"energy_0",0)/10,\
ReadingsVal($name,"power_1",0),\
ReadingsVal($name,"energy_1",0)/10,\
ReadingsVal($name,"power_2",0),\
ReadingsVal($name,"energy_2",0)/10,\
ReadingsVal($name,"power_sum",0),\
ReadingsVal($name,"energy_sum",0)/10\
)\
}
Wenn Herr Professor die Definition für shelly3pm als Kopie vom shellypm mit 3 Messtellen in die 36_shelly.pm einbauen würde, wäre das super!
(Nicht getestet habe ich: Relays)
Grüße!
Die Anrede
ZitatWenn Herr Professor ... würde
passt mir nicht >:(
Aber ich werde das machen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 14 Januar 2022, 11:04:35
Also bitte Folgendes ersetzen:
In Zeile 1224 (alte Zählung, der obige Log-Eintrag kann wieder raus
Hallo pah,
ich habe mal mit den Attributen gespielt und umgeschaltet mit
attr Bulb 1 mode whiteDann wird ein warning in der alten Zeile 1193 ausgeworfen.
Das ist der Abschnitt
Zitat# -- we have a Shelly Bulb /Duo in white mode
Die Zeile müsste ebenfalls entsprechend geändert werden.
Norbert
Bei Gelegenheit.
pah
Hallo,
ich habe mittels shelly-Modul auch einen Shelly Pro4PM soweit eingebunden bekommen (model = shelly4), es wurden (nach erstmaligem Ansprechen des jeweiligen Kanals) auch die Stati aller Kanäle in den Readings hinzugefügt und werden aktualisiert.
Auch das Reading state wird jedesmal aktualisiert, in der Zeile "deviceOverview" kann man kurz ein OK sehen, aber im state sehe ich nur ein Error
Das Device:
Internals:
CFGFN
DEF 192.168.1.150
DURATION 0
FUUID 61e31c8f-f33f-378b-c49c-828dc5e2449d032c
INTERVAL 60
MOVING stopped
NAME ShellyPro4_Gartenhaus
NR 46937
STATE Error
TCPIP 192.168.1.150
TYPE Shelly
READINGS:
2022-01-16 11:48:38 network <html>connected to <a href="http://192.168.1.150">192.168.1.150</a></html>
2022-01-15 20:13:20 overpower_0 0
2022-01-15 20:22:23 overpower_1 0
2022-01-15 20:22:15 overpower_2 0
2022-01-15 20:20:11 overpower_3 0
2022-01-15 20:13:20 relay_0 off
2022-01-15 20:22:23 relay_1 off
2022-01-15 20:22:15 relay_2 off
2022-01-15 20:20:11 relay_3 on
2022-01-16 11:49:38 state Error
Attributes:
DbLogExclude .*
group Shelly
model shelly4
room Arbeitszimmer,Draussen->Gartenhaus
Da im List nicht angezeigt, die FW des Shelly ist aktuell 0.9.2
Im Log erscheint folgendes bei Verbose5 für das Modul/Device:
2022.01.16 12:18:19.893 5: [Shelly_onoff] Issue a non-blocking call to http://192.168.1.150/relay/1?turn=on
2022.01.16 12:18:20.026 5: [Shelly_onoff] has obtained data {"ison": true, "has_timer":false, "timer_started_at": 0, "timer_duration": 0.00, "timer_remaining": 0.00, "overpower": false, "source": "http"}
2022.01.16 12:18:21.001 5: [Shelly_status] Issue a non-blocking call to http://192.168.1.150/status
2022.01.16 12:18:21.030 5: [Shelly_status] has obtained data Not Found
2022.01.16 12:18:21.030 1: [Shelly_status] invalid JSON data
2022.01.16 12:18:27.335 5: [Shelly_onoff] Issue a non-blocking call to http://192.168.1.150/relay/1?turn=off
2022.01.16 12:18:27.355 5: [Shelly_onoff] has obtained data {"ison": false, "has_timer":false, "timer_started_at": 0, "timer_duration": 0.00, "timer_remaining": 0.00, "overpower": false, "source": "http"}
2022.01.16 12:18:28.000 5: [Shelly_status] Issue a non-blocking call to http://192.168.1.150/status
2022.01.16 12:18:28.016 5: [Shelly_status] has obtained data Not Found
2022.01.16 12:18:28.016 1: [Shelly_status] invalid JSON data
Das Modul 36_shelly.pm ist eben erst aktualisiert:
36_Shelly.pm 25465 2022-01-14 14:54:04Z phenning
Mache ich jetzt gerade etwas falsch, habe ich etwas übersehen/vergessen, oder liegt es am Shelly-Modul?
Gruß, Christoph
PS: PAH, vielen Dank für dieses Dein Modul, meine anderen "alten" Shellys laufen damit wunderbar!
Ich betreibe mit dem Modul zwei Shelly4Pro, ohne Probleme. Die beiden haben allerdings Firmware Version 1.6.6, also bitte erst einmal den Shelly updaten.
LG
pah
Hallo pah,
bei mir sieht es ähnlich aus. Von allein werden die Readings nicht aktualisiert, erst, wenn ich einen Kanal aktiv schalte, erfolgt eine Aktualisierung. Im folgenden list gut zu sehen ist, dass ich Kanal 0 noch nicht über das Modul geschaltet habe, also kein Reading.
Da scheint es einen grundlegenden Unterschied zwischen dem 4 pro und dem pro4pm zu geben. Solange man nur schalten will ist das kein Problem. Bei mir ist es so, dass bestimmte Funktionen auf die Leistungsmessung des Kanals angewiesen sind. Das funktioniert nicht mehr. Ich werde wohl die beiden Shelly pro4pm wieder ausbauen und die alten 4er wieder einsetzen.
(Hat zusätzlich den Grund, dass es beim pro4pm keinen Schaltertyp "activation switch" mehr gibt, aber das ist ein anderes Thema. Grundsätzlich kann man die pro4pm auch per MQTT anbinden, da kommen readings ohne Ende. Funktioniert aber kurioserweise nur bei einem meiner beiden pro4pm...aber auch ein anderes Thema.)
DEF 192.168.xxx.xxx
DURATION 0
FUUID 61e2e93b-f33f-342e-b08c-adf407209e6368aa
INTERVAL 60
MOVING stopped
NAME Shelly4OG
NR 531
STATE Drucker:relay_0 | DekoAK/SZ:off | DekoGZ/WC:off | Lüftung:on
TCPIP 192.168.xxx.xxx
TYPE Shelly
READINGS:
2022-01-16 12:59:28 network <html>connected to <a href="http://192.168.xxx.xxx">192.168.xxx.xxx</a></html>
2022-01-16 08:57:47 overpower_1 0
2022-01-16 08:57:47 overpower_2 0
2022-01-15 17:44:23 overpower_3 0
2022-01-16 08:57:47 relay_1 off
2022-01-16 08:57:47 relay_2 off
2022-01-15 17:44:23 relay_3 on
2022-01-16 13:00:28 state Error
Attributes:
defchannel 3
mode relay
model shelly4
Die Firmware der "alten" 4er ist die 1.6.6_4, die der neuen 0.9.2
Viele Grüße
Uwe
Hallo Pah,
Zitat von: Prof. Dr. Peter Henning am 16 Januar 2022, 13:06:22
Ich betreibe mit dem Modul zwei Shelly4Pro, ohne Probleme. Die beiden haben allerdings Firmware Version 1.6.6, also bitte erst einmal den Shelly updaten.
Ich habe gerade mal etwas im I-Net gesucht - der ShellyPro4pm ist ein Gen2-Gerät, daher wohl die Fehler über das Modul.
Der Shelly 4 pro ist weiß, der shelly Pro4pm ist schwarz ...
Gruß, Christoph
Hallo Prof. Dr. Peter Henning,
die Umsetzung für shellyem3 funktioniert noch nicht.
Zeile 1071 sollte in shellyem.* angepasst werden.
#-- we have a Shelly 1/1pw, Shelly 4, Shelly 2/2.5, ShellyPlug or ShellyEM switch type device
if( ($model =~ /shelly1.*/) || ($model eq "shellyuni") || ($model eq "shellyplug") || ($model eq "shelly4") || [b]($model =~ /shellyem.*/) [/b]|| (($model =~ /shelly2.*/) && ($mode eq "relay")) ){
Zeile 1092, 1098 und 1663 muß auch die Abfrage auf shellyem3 erweitert werden, sonst tut die Deklaration vom shellyem3 ganz oben ja nix.
Über eine Ergänzung würde ich mich freuen.
Grüße
Zitatpro4pm
OK. Ich habe einen von den "neuen schwarzen" hier herumliegen, und einen Use Case zum Einbau. Ab nächster Woche kann man damit rechnen, dann wird das auch vom Modul unterstützt.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 17 Januar 2022, 06:05:41
OK. Ich habe einen von den "neuen schwarzen" hier herumliegen, und einen Use Case zum Einbau. Ab nächster Woche kann man damit rechnen, dann wird das auch vom Modul unterstützt.
LG
pah
Oha, gute Nachrichten. Dann warte ich noch mit dem Rückbau ;)
Vielen Dank schon mal und viele Grüße
Uwe
Hallo PAH,
super vielen Dank schon einmal.
Gruß, Christoph
Hallo,
ich habe einen neuen Shelly Plus 1 verbaut und bekomme immer "error" als state.
Internals:
DEF 192.168.0.71
DURATION 0
FUUID 61e2XXX
FVERSION 36_Shelly.pm:v3.4.0-s25465/2022-01-14
INTERVAL 60
NAME sz.WS.Shelly71
NR 80
STATE Error
TCPIP 192.168.0.71
TYPE Shelly
READINGS:
2022-01-20 16:58:38 network <html>connected to <a href="http://192.168.0.71">192.168.0.71</a></html>
2022-01-21 17:28:54 relay on
2022-01-22 14:10:01 state Error
Attributes:
DbLogExclude .*
alexaName Licht Schlafzimmer
alexaRoom Schlafzimmer
alias Licht Schlafzimmer
genericDeviceType light
icon light_ceiling
model shelly1
room 1.4_Schlafzimmer,Homekit,Shelly
siriName Licht Schlafzimmer
Ist hier bei mir etwas falsch, oder könnte das an dem vergleichsweise neuen Gerät liegen das noch nicht mit dem Modul zusammenarbeitet?
Hallo maddhin,
der Shellyplus1 ist ein Gerät der Generation2, da wird nicht mehr auf das alte Protokoll gesetzt ... wenn Du (wir) Glück haben, wird PAH evtl. die neuen Geräte auch noch mal einbinden ...
Soweit ich weiß, wollte er sich in absehbarer Zeit mit dem Pro4PM beschäftigen, der auch zu den neuen Geräten gehört ...
Du kannst den ShellyPlus1 aber auch über MQTT gut mit einbinden, das funktioniert auch, und es gibt auch schon Templates dafür ...
Gruß, Christoph
Zitat von: caldir65 am 22 Januar 2022, 14:25:48
der Shellyplus1 ist ein Gerät der Generation2, da wird nicht mehr auf das alte Protokoll gesetzt ...
OK - aber immerhin funktioniert der shellyplus1 soweit mit FHEM bzw. dem Modul. Bzw. man kann über ihn über set steueren. Ohne state kann man allerings nicht so richtig viel machen... Wäre super, wenn die neuen Shellys (Shellies?!?) dann auch eingebunden werden, damit man die richtig benutzen kann.
Was möchtest Du denn nutzen? Den Status, ob on oder off? Wenn Du einmal schaltest und die Browserseite aktualisierst, bekommst Du noch ein Reading Relay, das spiegelt den Status auch wieder. Da mußt Du dann halt statt auf state auf relay abfragen ...
Hier einmal mein Test-Device:
Internals:
CFGFN
DEF 192.168.1.140
DURATION 0
FUUID 61ec15db-f33f-378b-666c-57cf83a6ea0c40d1
INTERVAL 60
NAME Shellyplus1_test
NR 21287
STATE off
TCPIP 192.168.1.140
TYPE Shelly
READINGS:
2022-01-22 15:34:03 network <html>connected to <a href="http://192.168.1.140">192.168.1.140</a></html>
2022-01-22 15:37:34 relay off
2022-01-22 15:37:35 state Error
Attributes:
DbLogExclude .*
model shelly1
room Arbeitszimmer
stateFormat relay
Ich habe das jetzt ziemlich genau analysiert. Erstens ist es nicht richtig, dass man das Modul komplett auf Websocket umstellen müsste, um die Shelly 2G zu untetrstützen. Zweitnes aber ist das etwas kniffelig, weil die Herrschaften nun den Status nicht mehr in einer Abfrage mitteilen. Sondern es muss pro Kanal eine Abfrage erfolgen. Das bedeutet ein paar tieferen Einschnitte und wird noch ein paar Tage in Anspruch nehmen.
LG
pah
Hallo zusammen,
mit dem Modul betreibe ich problemlos einen Shelly RGB2 mit mode color und model shellyrgbw.
Die API bietet verschiedene Effekte: https://shelly-api-docs.shelly.cloud/gen1/#shelly-bulb-rgbw-device-modes
Gibt es eine Möglichkeit, diese Effekte mit dem Modul zu nutzen?
Grüße, Alex
Aber natürlich. Einfach das Kommando "set <device> config effect=<Ziffer>" (Ziffern 0..4) verwenden. Und das steht auch in der Beschreibung, die man mit "get <device> registers" bekommt. Vorschlag: Diese mal lesen
LG
pah
Vielen Dank, das klappt! Wieder was gelernt, ich wusste gar nicht, dass an der Stelle auch noch Doku versteckt ist...
Hallo pah,
ich würde gern noch einmal das Thema Shelly TRV aufgreifen.
Heute habe ich den TRV endlich bekommen und wollte voller Elan das Gerät in Fhem einbinden, aber :o per Einbindung als Shelly ist kein Modell TRV auszuwählen :( .
ich hatte vorher in diesem Thread gelesen, dass du das TRV einbinden wolltest, scheint jedoch noch nicht den Weg in die 36_Shelly.pm gefunden zu haben.
Wirklich Schade, ich würde gern das Modul und nicht MQTT nutzen wollen.
Kannst du da was machen? Würde mich freuen wie Bolle ;) .
OK, um zu zeigen, dass doch noch etwas passiert: Hier ist die erste Testversion des Shelly-Moduls, die auch ein Gerät der neuen Generation unterstützt - nämlich den Shelly4PM.
Die Energiemessung funktioniert noch nicht, aber das Schalten der vier Kanäle und die richtige Anzeige passen schon.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 01 April 2022, 20:42:28
das Schalten der vier Kanäle und die richtige Anzeige passen schon.
Moin und ja, kann ich bestätigen :D
Vielen Dank!
Viele Grüße
Uwe
Hier die nächste Version. Mit kompletter Energiemessung. Auch die automatische Generierung von readingsProxies funktioniert.
Konfigurationsabfrage noch nicht (ist auch ziemlich kniffelig).
Wer hat denn noch andere 2G-Devices zum Testen?
LG
pah
Danke, läuft auch :)
Zu Deiner Frage: Ich erst mal nicht. Neben zwei 4er pm hab ich ein testweise ein TRV.
Gruß
Uwe
Moin,
ich hätte noch einen ShellyPlus1, den ich zur Verfügung stellen könnte ...
Gruß, Christoph
Wenn ich es richtig gemacht habe, funktionieren mit dieser Version auch Shelly Plus 1 und Shelly Plus 1PM.
Achtung: Wegen der doofen inkonsistenten Namensgebung von Allterco habe ich jetzt statt shelly4pm jetzt shellypro4pm als Auswahl für model eingesetzt, dass muss beachtet werden !
LG
pah
Neue Version (alpha04) ist drin und im state prangt ein "Error". Ich meine, der state zeigte in der letzten Version ein schönes "OK". Ich will mich da aber nicht festlegen...
Gruß
Uwe
Ich nehm' alles zurück. Nachdem ich ein paar mal geschaltet habe, steht der state wieder auf OK.
Du musst bedenken, dass derzeit bei jedem Schaltvorgang 4 HTTP requests abgesetzt werden.
LG
pah
Hab ich jetzt gesehen, ja. War mal wieder zu ungeduldig... ::)
Gruß
Uwe
Anbei noch eine aktualisierte Testversion des neuen Moduls - die vorige hatte leider einen Bug, der die regelmäßige Statusabfrage bei den 1st Generation Devices verhindert hat.
Ich würde gerne wissen, ob Anzeige und Schaltvorgänge bei anderen 2nd Generation Devices jetzt klappen.
LG
pah
Der Status der 1er ist wieder ok, kein "Error" mehr :) Und sie aktualisieren auch den Status, wenn das Schalten von anderer Stelle erfolgt.
Das Schalten bei meinen 4er pm funktioniert, aber das ging doch auch vorher...oder hatte ich was übersehen?
Danke und Gruß
Uwe
Die Statusänderung aber nicht ...
LG
pah
Ja...ich habe extra nochmal die vorherige Version eingespielt, um das nachvollziehen zu können :D
Viele Grüße
Uwe
Hallo!
Da mein Shelly 1 Plus beim state stets Error anzeigte, bin ich auf diesen Thread gestoßen. Ich habe weder weiterführende Tests gemacht, noch den Thread komplett gelesen. Trotzdem will ich auf die Schnelle mal mitteilen, dass bei Einstellung des models shellyplus1 der state nun richtig gesetzt wird. Bei Schaltung über die Weboberfläche [Edit: des Shellys!] wird der Status nach einiger Zeit (geschätzt < 1 min) detektiert. Auc bei meinen 2.5er-Shellys geschieht dies weiterhin korrekt. Weitere Tests habe ich noch nicht gemacht, da ich aber beide Versionen im Einsatz habe, dürften mir evtl. Nebenwirkungen im Laufe der nächsten Tage auffallen.
Grüße,
Seli
ZitatBei Schaltung über die Weboberfläche [Edit: des Shellys!] wird der Status nach einiger Zeit (geschätzt < 1 min) detektiert.
"Nach einiger Zeit", soso.
Dazu gibt es entweder das Attribut interval - führt allerdings zu hoher Funklast.
Besser noch: In der Weboberfläche des Shelly eintragen als "Button pressed URL"
http://<ip-adresse von fhem>:8083/fhem?XHR=1&cmd=get%<devicename>%20statusDann wird jeder Schaltvorgang am Shelly dazu führen, dass FHEM sich den Status holt.
LG
pah
Ja, das ist mir bekannt. Meine 2.5er Shellys laufen auch mit so einer Button-Switched-Url. Beim 1plus ist kein Schalter angeschlossen. Die Minute reicht mir hier völlig. Ich wollte damit nur sagen, dass das Polling bei beiden (weiterhin) funktioniert und der Status beim 1plus nun korrekt ermittelt wird.
Grüße, Seli
Hm, ich hatte mich so über den nun korrekten Status gefreut, dass ich gestern Abend nicht mehr bemerkt hatte (da nicht getestet), dass der Shelly 1 plus gar nicht mehr auf den on-Befehl reagiert. Er wird kommentarlos geschluckt, ohne dass der Shelly das relay schaltet.
Moin,
ich habe jetzt auch seit gestern abend die letzte hier ladbare Version im Test, und einen ShellyPlus1 eingerichtet. Der Status kommt (zeitverzögert) immer, und über die Shellyeigene Weboberfläche kann ich auch heute noch schalten. Ich bemühe mich jetzt, den Shelly per fhem zu schalten, das klappt aber nicht. Ist das noch nicht implementiert für die neue Generation2, oder stelle ich mich zu blöd an?
set Shelly1plus_Test on 0
oder
set Shelly1plus_Test on
und noch das Device:
Internals:
CFGFN
DEF 192.168.1.140
DURATION 0
FUUID 6251d795-f33f-378b-2a5b-bb240376d44d35df
INTERVAL 43200
NAME Shelly1plus_Test
NR 2039
STATE OK
TCPIP 192.168.1.140
TYPE Shelly
Helper:
DBLOG:
network:
logdb:
TIME 1649530773.66858
VALUE <html>connected to <a href="http://192.168.1.140">192.168.1.140</a></html>
state:
logdb:
TIME 1649530773.66858
VALUE initialized
READINGS:
2022-04-10 09:06:27 inttemp 54.2
2022-04-09 20:59:33 network <html>connected to <a href="http://192.168.1.140">192.168.1.140</a></html>
2022-04-09 21:00:33 relay off
2022-04-09 20:59:41 relay_0 off
2022-04-10 09:06:27 state OK
Attributes:
DbLogExclude .*
group Shelly
interval 43200
model shellyplus1
room Arbeitszimmer
Gruß, Christoph
ZitatIst das noch nicht implementiert für die neue Generation2
Das Problem ist, dass es "die neue Generation" nicht gibt, sondern die Herrschaften das API extrem kompliziert haben.
Schalten für shelly4pm pro ist getestet - bei den shellyplus1 und plus1em nur geraten, weil ich die selbst nicht habe.
Also bitte verbose=5 setzen und das Log hier posten.
LG
pah
Beim Schalten tut sich im Log außer "Shelly_Bad6 on" nichts! Weder im Haupt-Log, noch im Shelly-FileLog. Verbose 5 ist gesetzt. Das Schalten des Shelly1plus klappt mit der eingecheckten Version mit dem alten Kommando. Mit der Version vom Freitag funktioniert der Status, aber beim Schalten tut sich nichts.
Grüße,
Seli
Das Problem liegt vermutlich in Zeile 582: Das on/off-Kommando wird beim model shellyplus1 einfach nicht durchgelassen. Wenn man die Prüfung umgeht, funktionieren die Kommandos!
Grüße,
Seli
Schau ich mir heute am frühen Abend an.
LG
pah
Moin,
kann es sein, daß das Modul das Passwort "vergißt", wenn man z.b. das Device umbenennt in fhem? Ich hatte jedenfalls heute das Problem, daß nach dem umbenennen das Device (PlugS, FW1.11.7) mit error und "not connected" angezeigt wurde, erst, als ich das PW neu gesetzt habe, wurde wieder ein sinnvoller Status gezeigt sowie konnte ich das Device steuern.
Gruß,
Christoph
Zitatdas Modul das Passwort "vergißt",
Nö, da das PW nicht im Modul, sondern in FHEM gespeichert wird. Und zwar unter dem Device-Namen, was ja auch sinnvoll ist.
Also: It's not a bug, it's a feature.
LG
pah
Anbei die neueste Testversion, die auch den shellyplus1 bedienen sollte.
Ok, danke, dann weiß ich Bescheid.
Mit der neuen Version lässt sich der Shelly 1 plus schalten und der Status wird auch richtig ermittelt.
Grüße,
Seli
Prima - dann sind "nur" noch diverse andere Dinge an die neue Generation anzupassen. Ich checke das gegenwärtige Ding jetzt mal ein.
LG
pah
Top, wieder einmal super Arbeit!
Danke
Guten Abend,
ich habe seit heute ein Shelly3EM Modul installiert und noch ein paar Fragen zu der Konfig. Aktuell habe ich das Device so angelegt:
defmod myShelly Shelly 10.x.x.y
attr myShelly icon measure_power_meter
attr myShelly interval 60
attr myShelly model shelly3em
im Log sehe ich bereits die korrekten Werte:
2022.04.28 22:53:34 5: [Shelly_proc1G] device myShelly has returned data {"wifi_sta":{"connected":true,"ssid":"NETZ","ip":"10.x.x.y","rssi":-71},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"22:53","unixtime":1651179213,"serial":34,"has_update":false,"mac":"MAC","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"is_valid":true,"source":"input"}],"emeters":[{"power":0.00,"pf":0.47,"current":0.06,"voltage":2.93,"is_valid":true,"total":0.0,"total_returned":0.0},{"power":12.87,"pf":0.70,"current":0.08,"voltage":234.62,"is_valid":true,"total":17.4,"total_returned":0.0},{"power":37.19,"pf":0.86,"current":0.18,"voltage":234.66,"is_valid":true,"total":70.9,"total_returned":0.0}],"total_power":50.06,"fs_mounted":true,"update":{"status":"idle","has_update":false,"new_version":"20220324-123835/v1.11.8-3EM-fix-g0014dcb","old_version":"20220324-123835/v1.11.8-3EM-fix-g0014dcb"},"ram_total":49440,"ram_free":31540,"fs_size":233681,"fs_free":157377,"uptime":2350}
Ich sehe aber keine Readings. Muss ich die Readings für emeters erst anlegen?
Aktuell sieht es so aus:
READINGS:
2022-04-28 21:47:01 cloud disabled
2022-04-28 22:05:03 firmware v1.11.8
2022-04-28 22:20:02 network connected to 10.2.2.95
2022-04-28 22:07:11 relay_0 on
2022-04-28 22:20:02 state initialized
Wäre für jede Hilfe dankbar.
lg,
Matthias
Nö, sollte von alleine gehen. Ist aber - weil ich keinen 3em habe - nicht getestet.
War aber einfach zu finden, bitte mal die anliegende Version testen.
LG
pah
Vielen Dank. Die Zeile mit
< my $version = "4.01;
habe ich auf
< my $version = "4.01";
geändert. Dann kamen keine Fehlermeldungen beim Restart.
Danach hatte ich die Readings energy_0, energy_1, energy_2, aber die Readings blieben immer auf 0.
Ich habe dann Zeile 1139 auch noch korrigiert:
my $metern = ($model =~ /shellyem.?/)?"emeters":"meters";
auf
my $metern = ($model =~ /shelly.?em/)?"emeters":"meters";
und bekomme nun die Werte angezeigt!
Danke nochmals!
lg,
Matthias
1145 war auch zu ändern. Das Ding ist jetzt eingecheckt.
LG
pah
Dankeschön.
Hi zusammen,
nachdem Beta-User (warum denke ich da immer an Beta-Teilchen? :D) meinte ich wäre hier besser aufgehoben stelle ich halt nochmal hier meine Fragen.
Ich habe zwei Shelly1 mir besorgt und mit einem Reed-Switch versehen. In der Shelly-App klappt auch alles 1a. In Fhem bekommt ich leider den Status des Reed-Switch nicht angezeigt.
1. Unter welchem Attribut sollte der Reedswitch mir angezeigt werden?
2. Fhem soll den Switch wie ein Taster nur anzeigen geht das in dem Modul?
Meine 3te Frage (lösen von der Cloud) hat sich mittlerweile erledigt. Anscheinend war mein Shelly defekt den mit dem anderen Shelly geht alles (habe mir einen Shelly im DuaPack bestellt und der eine war Defekt).
Grüße
Michael
Erstens werden Status nicht als "Attribut" angezeigt.
Zweitens ist das mit dem externen Switch relativ neu und wird im Modul 36_Shelly.pm derzeit nicht verarbeitet.
LG
pah
Guten Morgen,
Okay. Wird es in naher Zukunft implementiert? Der shelly 1 hatte das doch schon immer wie ich gehört habe und so jung ist das Modul ja auch nicht wenn ich aber wieviel seiten der thread hat.
Grüße
Michael
ZitatWird es in naher Zukunft implementiert?
Nö.
LG
pah
Hallo pah,
ich habe festgestellt das bei dem shellypro4pm die Reading energy nicht kommen.
Wenn ich richtig im Code geguckt habe wird nach energy im string des shellys gesucht.
Bei der zweiten Generation der Api soll es aenergy heißen.
Ich habe das bei mir in der 36_Shelly.pm angepasst und die readings energy sind nun vorhanden.
Viele Grüße
Alex
Kann ich gerne übernehmen, welche Zeile ist das ?
LG
pah
Hallo
Es ist Zeile 1421.
VG Alex
Hallo,
ich habe den Shelly Plus 2PM bei mir verbaut.
Da dieser noch nicht in der Geräteliste aus wählbar ist, habe ich diesen wie folgt eingebunden:
Model: shellypro4pm
Dann set xtrachannels
Da der Shelly nur 2 Kanäle hat, von den 4 angelegten die 2 nicht benutzten gelöscht.
Funktioniert bei mir korrekt, mit aktueller Verbrauchsanzeige.
@ PAH: Kann das so von Dir in das Modul übernommen werden?
Kann ich machen - genau solche Hinweise brauche ich, da ich fast keine Geräte aus der 2nd Generation besitze. Wird aber heute vermutlich nichts mehr.
LG
pah
Meine Frage betrifft die neuen Module, ich habe 2 Shelly 2 Pro die sind nicht unter Geräteliste/model zu finden.
ShellyPro2-30C6F784B224 so sieht der Shelly in der Weboberfläche aus.
Ich werde das jetzt ersteinmal mit dem Pro 4 ausprobieren.
Geht nicht er zeigt error an
Shelly selber hat den Rollladenmodus (Roller) noch nicht eingepflegt, soll laut Support noch kommen, ist nur die Frage wann.
Ich wollte damit eine Markise steuern und weiß nicht ob es dann funktioniert.
Ich hatte vorher den Shelly2.5, da ich aber erhebliche Probleme mit dem WLAN auf dem Dachboden hatte wo der Shelly sitzt habe ich jetzt die Pro Variante mit Netzwerkanschluss.
ZitatShelly 2 Pro die sind nicht unter Geräteliste/model
Richtig, aber das hat auch keiner behauptet.
Die neue Gerätegeneration wird nach und nach ins Modul eingebaut, weil ich selbst außer einem 4Pro keine Geräte der neuen Generation habe.
Also Gemach: In den nächsten Tagen kann ich mal eine neue Version des Moduls zum Testen bereitstsellen, die eventuell einen 2Pro unterstützt. Zum Schalten, wohlgemerkt - für einen noch nicht implementierten Roller-Mode etwas zu entwickeln, wäre Arbeit für den Papierkorb.
LG
pah
Ja sehr gern.... Ich habe Zeit also keine Eile.
Das mit dem Rollermodus werde ich dann anders lösen, evtl mit einem DOIF.
Wer weiß wann Alterco das implementiert
OK, hier mal eine Testversion, die alle 2nd Generation Devices unterstützen sollte. Noch ohne Roller Mode
LG
pah
Danke pah für das Modul.
Habe es heute mal eingerichtet. Ich kann aber kein set Befehl absetzen da set überhaupt nicht erscheint.
Ich nutze das neue Shelly 2Pro
Ich mache hier mal ein paar Angaben die evtl. weiterhelfen könnten.
Die Schaltbefehle per http:// die bei mir funktionieren:
http://10.0.0.167/rpc/Switch.Set?id=0&on=true
http://10.0.0.167/rpc/Switch.Set?id=0&on=false
http://10.0.0.167/rpc/Switch.Set?id=1&on=true
http://10.0.0.167/rpc/Switch.Set?id=1&on=false
Das list:
Internals:
DEF 10.0.0.167
DURATION 0
FUUID 62a1f1a5-f33f-b063-a6be-ac7b0b6bb84082e2
INTERVAL 60
NAME AU_Test
NR 1499
STATE OK
TCPIP 10.0.0.167
TYPE Shelly
eventCount 32
READINGS:
2022-06-09 16:20:10 inttemp 31.3
2022-06-09 16:11:07 network <html>connected to <a href="http://10.0.0.167">10.0.0.167</a></html>
2022-06-09 16:21:11 state OK
Attributes:
mode relay
model shellypro2
room AutomationTest,MQTT2_DEVICE
http://10.0.0.167/rpc/Shelly.GetStatus
{
"ble": {},
"cloud": {
"connected": false
},
"eth": {
"ip": "10.0.0.167"
},
"input:0": {
"id": 0,
"state": false
},
"input:1": {
"id": 1,
"state": null
},
"mqtt": {
"connected": true
},
"switch:0": {
"id": 0,
"source": "WS_in",
"output": false,
"temperature": {
"tC": 30.2,
"tF": 86.3
}
},
"switch:1": {
"id": 1,
"source": "WS_in",
"output": false,
"temperature": {
"tC": 35.1,
"tF": 95.3
}
},
"sys": {
"mac": "30C6F784B224",
"restart_required": false,
"time": "15:49",
"unixtime": 1654782581,
"uptime": 2445,
"ram_size": 239152,
"ram_free": 145492,
"fs_size": 524288,
"fs_free": 290816,
"cfg_rev": 62,
"available_updates": {}
},
"wifi": {
"sta_ip": null,
"status": "disconnected",
"ssid": null,
"rssi": 0
}
}
ich habe jetzt nochmal verbose 5 eingestellt und ein paar Logeinträge kann ich hier einstellen
2022.06.09 16:41:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":0, "source":"WS_in", "output":false,"temperature":{"tC":31.3, "tF":88.4}}
2022.06.09 16:41:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":1, "source":"WS_in", "output":false,"temperature":{"tC":36.1, "tF":97.0}}
2022.06.09 16:41:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=1
2022.06.09 16:41:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=0
2022.06.09 16:40:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":0, "source":"WS_in", "output":false,"temperature":{"tC":31.3, "tF":88.4}}
2022.06.09 16:40:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":1, "source":"WS_in", "output":false,"temperature":{"tC":36.2, "tF":97.2}}
2022.06.09 16:40:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=1
2022.06.09 16:40:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=0
2022.06.09 16:39:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":0, "source":"WS_in", "output":false,"temperature":{"tC":31.2, "tF":88.2}}
2022.06.09 16:39:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":1, "source":"WS_in", "output":false,"temperature":{"tC":36.1, "tF":97.0}}
2022.06.09 16:39:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=1
2022.06.09 16:39:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=0
2022.06.09 16:38:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":0, "source":"WS_in", "output":false,"temperature":{"tC":31.1, "tF":88.0}}
2022.06.09 16:38:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":1, "source":"WS_in", "output":false,"temperature":{"tC":36.1, "tF":96.9}}
2022.06.09 16:38:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=1
2022.06.09 16:38:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=0
2022.06.09 16:37:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":0, "source":"WS_in", "output":false,"temperature":{"tC":31.1, "tF":88.0}}
2022.06.09 16:37:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":1, "source":"HTTP", "output":false,"temperature":{"tC":36.1, "tF":96.9}}
2022.06.09 16:37:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=1
2022.06.09 16:37:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=0
2022.06.09 16:36:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":0, "source":"WS_in", "output":false,"temperature":{"tC":31.2, "tF":88.2}}
2022.06.09 16:36:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":1, "source":"HTTP", "output":false,"temperature":{"tC":36.0, "tF":96.8}}
2022.06.09 16:36:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=1
2022.06.09 16:36:12 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=0
2022.06.09 16:35:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":0, "source":"WS_in", "output":false,"temperature":{"tC":31.0, "tF":87.7}}
2022.06.09 16:35:12 5: [Shelly_proc2G] device AU_Test has returned data {"id":1, "source":"WS_in", "output":false,"temperature":{"tC":35.8, "tF":96.4}}
2022.06.09 16:35:11 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=1
2022.06.09 16:35:11 5: [Shelly_status] issue a non-blocking call to http://10.0.0.167/rpc/Switch.GetStatus?id=0
OK, das sollte helfen, etwas mehr herauszufinden. Muss aber bis Montag warten.
LG
pah
Alles OK, super das du daran weiter arbeitest ;)
Ich habe es doch früher geschafft, anbei eine neue Testversion.
LG
pah
Vielen Dank pah ;), ich habe das heute mal eingebaut und es funktioniert hervorragend.
Ich habe dabei die Option genutzt "set AU_markise xtrachannels"
Somit hat er mir zwei weitere device angelegt
AU_markise_0
AU_markise_1
Diese nutze ich jetzt erst einmal zum schalten meiner Markise mit Hilfe eines DOIF, bis du den "roller" Modus eingesetzt hast.
Ist mit einem DOIF jetzt nicht ganz so wie es soll (etwas ungutes Gefühl), aber funktioniert erst einmal.
list DOIF:
Internals:
CFGFN
DEF ([HM_RC_12_Btn_09:"Short"]) (set AU_markise_0 off, set AU_markise_1 on) DOELSEIF ([HM_RC_12_Btn_10:"Short"]) (set AU_markise_1 off, set AU_markise_0 on) DOELSEIF ([HM_RC_12_Btn_11:"Short"]) (set AU_markise_1 off, set AU_markise_0 off)
FUUID 62a34700-f33f-a6c6-8814-80f1118ae431920b
MODEL FHEM
NAME di_markisen_automatik
NOTIFYDEV HM_RC_12_Btn_10,global,HM_RC_12_Btn_09,HM_RC_12_Btn_11
NR 8476
NTFY_ORDER 50-di_markisen_automatik
STATE cmd_1
TYPE DOIF
VERSION 26020 2022-05-03 16:28:02
eventCount 12
READINGS:
2022-06-10 15:31:41 Device HM_RC_12_Btn_09
2022-06-10 15:31:41 cmd 1
2022-06-10 15:31:41 cmd_event HM_RC_12_Btn_09
2022-06-10 15:31:41 cmd_nr 1
2022-06-10 15:31:41 e_HM_RC_12_Btn_09_events Short 1_238 (to broadcast),trigger: Short_238,trigger_cnt: 238
2022-06-10 15:31:37 e_HM_RC_12_Btn_10_events Short 1_47 (to broadcast),trigger: Short_47,trigger_cnt: 47
2022-06-10 15:31:40 e_HM_RC_12_Btn_11_events Short 1_47 (to broadcast),trigger: Short_47,trigger_cnt: 47
2022-06-10 15:30:15 mode enabled
2022-06-10 15:31:41 state cmd_1
Regex:
accu:
collect:
cond:
HM_RC_12_Btn_09:
0:
&STATE ^HM_RC_12_Btn_09$
HM_RC_12_Btn_10:
0:
1:
&STATE ^HM_RC_12_Btn_10$
HM_RC_12_Btn_11:
0:
1:
2:
&STATE ^HM_RC_12_Btn_11$
attr:
cmdState:
wait:
waitdel:
condition:
0 ::EventDoIf('HM_RC_12_Btn_09',$hash,'Short',1)
1 ::EventDoIf('HM_RC_12_Btn_10',$hash,'Short',1)
2 ::EventDoIf('HM_RC_12_Btn_11',$hash,'Short',1)
do:
0:
0 set AU_markise_0 off, set AU_markise_1 on
1:
0 set AU_markise_1 off, set AU_markise_0 on
2:
0 set AU_markise_1 off, set AU_markise_0 off
3:
helper:
NOTIFYDEV HM_RC_12_Btn_10,global,HM_RC_12_Btn_09,HM_RC_12_Btn_11
event Short 1_238 (to broadcast)
globalinit 1
last_timer 0
sleeptimer -1
timerdev HM_RC_12_Btn_09
timerevent Short 1_238 (to broadcast)
triggerDev HM_RC_12_Btn_09
timerevents:
Short 1_238 (to broadcast)
trigger: Short_238
trigger_cnt: 238
timereventsState:
state: Short 1_238 (to broadcast)
trigger: Short_238
trigger_cnt: 238
triggerEvents:
Short 1_238 (to broadcast)
trigger: Short_238
trigger_cnt: 238
triggerEventsState:
state: Short 1_238 (to broadcast)
trigger: Short_238
trigger_cnt: 238
internals:
readings:
trigger:
all HM_RC_12_Btn_09 HM_RC_12_Btn_10 HM_RC_12_Btn_11
uiState:
uiTable:
Attributes:
room Draußen
Habe gerade mal deine Version mit einem Shelly 1 Plus PM in Betrieb genommen. Sieht erstmal gut aus.
Allerdings geht jetzt mein 2.5er nicht mehr:
2022.06.13 10:39:19.039 1: PERL WARNING: Use of uninitialized value $channel in concatenation (.) or string at ./FHEM/36_Shelly.pm line 629.
2022.06.13 10:39:19.040 1: [Shelly_Set] Error: wrong channel given and defchannel attribute not set properly for device Rollo1.Shelly
attr Rollo1.Shelly mode roller
attr Rollo1.Shelly model shelly2.5
Seh ich mir an, sollte einfach zu beheben sein.
LG
pah
Hallo,
ich bin auch Besitzer eines shellyplus2pm. Daher habe ich mir das Shelly Module aus Antwort #163 runtergeladen.
Aus einen mit unerfindlichen Grund tut sich aber beim Absetzen des set Befehls rein gar nichts
set ShellyJanRollade open
Setze ich im Browser einen HTTP Befehl ab, reagiert der Rolladen.
http://192.168.178.67/roller/0?go=open
Das List sieht wie folgt aus:
Internals:
CFGFN ./rolladen.cfg
DEF 192.168.178.67
DURATION 0
FUUID 62a5e548-f33f-144e-411a-c69c4bc12876ddcc
INTERVAL 60
NAME ShellyJanRollade
NR 408
STATE OK
TCPIP 192.168.178.67
TYPE Shelly
eventCount 5
READINGS:
2022-06-13 18:27:15 network <html>connected to <a href="http://192.168.178.67">192.168.178.67</a></html>
2022-06-13 18:27:19 state OK
Attributes:
mode roller
model shellyplus2pm
room Rolladen
verbose 5
Die Ausgabe im Log File ist trotz verbose 5 recht sperrlich.
2022-06-13_18:36:19 ShellyJanRollade OK
2022-06-13_18:36:20 ShellyJanRollade OK
2022-06-13_18:37:20 ShellyJanRollade OK
...
Jemand eine Idee. Ist bestimmt etwas total dämliches, bei dem alle mit dem Kopf schütteln. ::)
Danke und Gruß,
Rainer
Zitat von: Prof. Dr. Peter Henning am 13 Juni 2022, 13:46:27
Seh ich mir an, sollte einfach zu beheben sein.
LG
pah
Habe gerade mal selbst reingeschaut :-)
Die Regexp in Zeile 587 funktioniert für den Shelly2.5 im Roller Mode nicht richtig, so dass der Code Teil betreten wird
if( ($model =~ /shelly(plus)?\d.*/) || ($model eq "shellyuni") || ($model =~ /shelly(pro)?\d(pm)?/) || ($model eq "shellyplug") || (($model =~ /shelly2.*/) && ($mode eq "relay")) ){
Zitat von: XBuschman am 13 Juni 2022, 18:44:21
Hallo,
ich bin auch Besitzer eines shellyplus2pm. Daher habe ich mir das Shelly Module aus Antwort #163 runtergeladen.
Aus einen mit unerfindlichen Grund tut sich aber beim Absetzen des set Befehls rein gar nichts
set ShellyJanRollade open
Setze ich im Browser einen HTTP Befehl ab, reagiert der Rolladen.
http://192.168.178.67/roller/0?go=open
Das List sieht wie folgt aus:
Internals:
CFGFN ./rolladen.cfg
DEF 192.168.178.67
DURATION 0
FUUID 62a5e548-f33f-144e-411a-c69c4bc12876ddcc
INTERVAL 60
NAME ShellyJanRollade
NR 408
STATE OK
TCPIP 192.168.178.67
TYPE Shelly
eventCount 5
READINGS:
2022-06-13 18:27:15 network <html>connected to <a href="http://192.168.178.67">192.168.178.67</a></html>
2022-06-13 18:27:19 state OK
Attributes:
mode roller
model shellyplus2pm
room Rolladen
verbose 5
Die Ausgabe im Log File ist trotz verbose 5 recht sperrlich.
2022-06-13_18:36:19 ShellyJanRollade OK
2022-06-13_18:36:20 ShellyJanRollade OK
2022-06-13_18:37:20 ShellyJanRollade OK
...
Jemand eine Idee. Ist bestimmt etwas total dämliches, bei dem alle mit dem Kopf schütteln. ::)
Danke und Gruß,
Rainer
Der Rollermode ist noch nicht integriert, dass wollte Pah erst die Tage machen wenn Zeit ist.
Also etwas Geduld
Sicher, dass das Ding ein Shelly2.5PM ist ? Der Shelly2.5 hat schon Leistungsmessung gehabt - und ein Modell Shelly2.5PM gibt es im API gar nicht.
Sollte also einfach Shelly2.5 draufstehen. Anbei eine Version, die das o.a. Problem vermeidet
LG
pah
@XBushman: Rollladen, mit 3 "l". Auch wenn die Google Spracherkennung das noch nicht kapiert.
Ja sorry, ist natürlich ein Shelly2.5.
Die Anpassung funktioniert leider nicht, es kommt immer noch die gleiche Fehlermeldung.
2022.06.14 14:15:40.440 1: PERL WARNING: Use of uninitialized value $channel in concatenation (.) or string at ./FHEM/36_Shelly.pm line 629.
2022.06.14 14:15:40.441 1: [Shelly_Set] Error: wrong channel given and defchannel attribute not set properly for device Rollo1.Shelly
Hallo pah,
ich habe hier neu einen Shellydimmer 2 mit der Firmware 1.11.7.
mit der Modulversion
36_Shelly.pm 26017 2022-05-02 07:04:23Z phenning
Das List:
Internals:
CFGFN
DEF 192.168.2.67
DURATION 0
FUUID 62a885e1-f33f-8873-3068-553f2f7de1c4ae48
INTERVAL 30
NAME dimmerTest
NR 740248
SHELLYID shellydimmer2-C45BBE576AB9
STATE off
TCPIP 192.168.2.67
TYPE Shelly
READINGS:
2022-06-14 14:58:09 cloud disabled
2022-06-14 14:59:14 energy 0.1
2022-06-14 14:58:09 firmware v1.11.7
2022-06-14 14:58:09 network <html>connected to <a href="http://192.168.2.67">192.168.2.67</a></html>
2022-06-14 15:24:52 pct 4
2022-06-14 14:59:14 power 0
2022-06-14 15:22:52 state off
Attributes:
interval 30
model shellydimmer
room Shelly
Damit bekomme ich im Log folgendes Warning:
022.06.14 15:10:33 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4979.
2022.06.14 15:10:33 1: stacktrace:
2022.06.14 15:10:33 1: main::__ANON__ called by fhem.pl (4979)
2022.06.14 15:10:33 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (1236)
2022.06.14 15:10:33 1: main::Shelly_proc1G called by ./FHEM/36_Shelly.pm (1058)
2022.06.14 15:10:33 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (1045)
2022.06.14 15:10:33 1: main::__ANON__ called by FHEM/HttpUtils.pm (720)
2022.06.14 15:10:33 1: main::__ANON__ called by fhem.pl (778)
Das dürfte daran liegen, dass es in der Firmware kein Overpower gibt.
Ich habe im Modul die Zeile 1236
readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower)
ergänzt zu
readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower)
if($overpower);
Damit ist die Fehlermeldung weg.
Norbert
Edit:
Es gibt noch ein weiteres Warning bei
get <device> registers
2022.06.14 15:45:23 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_Shelly.pm line 466.
2022.06.14 15:45:23 1: stacktrace:
2022.06.14 15:45:23 1: main::__ANON__ called by ./FHEM/36_Shelly.pm (466)
2022.06.14 15:45:23 1: main::Shelly_Get called by fhem.pl (3948)
2022.06.14 15:45:23 1: main::CallFn called by fhem.pl (2021)
2022.06.14 15:45:23 1: main::CommandGet called by fhem.pl (1273)
2022.06.14 15:45:23 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2802)
2022.06.14 15:45:23 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (982)
2022.06.14 15:45:23 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (608)
2022.06.14 15:45:23 1: main::FW_Read called by fhem.pl (3948)
2022.06.14 15:45:23 1: main::CallFn called by fhem.pl (781)
Als Ausgabe erfolgt:
Set/Get these registers by calling set/get dimmerTest config <registername> <value> [<channel>]
Nächster Versuch ...
LG
pah
Vielen Dank!
jetzt passt es für den Shelly 2.5 im Roller Mode und auch der Shelly Plus 1 PM schaltet noch richtig.
Na, dann kann ich das ja offiziell freigeben ;-)
Btw: Ich habe etliche Shelly 2.5 kostengünstig abzugeben. Da die bei mir zu viert in gut isolierten Dosen verbaut waren, sind sie zu warm geworden. Das war mir auf Dauer zu riskant.
LG
pah
Ist der Rollermode jetzt mit drin.?
Für die 2er und 2.5er (=1st Generation) war er das schon vor mehr als einem Jahr. Noch nicht drin lediglich für Shelly Plus 2PM und Shelly Pro 2PM (=2nd Generation), weil das dort ziemlich anders funktioniert.
LG
pah
Danke für die Rückmeldung, dann warte ich noch geduldig ;)
Geht ja erstmal mit dem DOIF, kann nur eben nicht öffnen nach Prozenten was ich bei einer bestimmten Temperatur immer gemacht habe, oder besser es funktionierte automatisch.
Hallo pah,
ich habe ein ziemlich merkwürdiges Verhalten mit meinem Pro 4 PM. Der Aktor war eine Woche lang ohne FHEM Anbindung im Einsatz, ohne Probleme. Nun habe ich ihn seit gestern über FHEM eingebunden und die folgende reproduzierbare Situation. Sobald ich mit FHEM die Devices (in meinem Fall vier) verbinde, friert der Pro 4 PM nach einer kurzen Zeit ein. Über die Taster ist das Gerät dann nicht mehr zu bedienen, er antwortet nicht mehr auf Pings und in FHEM geht das Device in ERROR. Über das Webinterface des Shellys ist er etbenfalls nicht erreichbar.
Logs:
[Shelly_configure] invalid JSON data for device abc
[Shelly_proc2G] device abc has error read from http://10.1.4.12:80 timed out
[Shelly_proc2G] device bca has error read from http://10.1.4.12:80 timed out
Anschließend ist das Gerät mal erreichbar (PING, Webfrontend, FHEM), die meiste Zeit antwortet es jedoch nicht. Das Problem besteht über LAN und WLAN und tritt sowohl bei der derzeit eingecheckten Modulversion als auch mit der letzten Version hier aus dem Thread auf. Der einzige Unterschied zwischen den Versionen ist, dass in der Version hier aus dem Thread die Leistungsdaten (energy) nicht mehr aktialisiert werden.
Wenn ich die Devices auf eine nicht vorhandene IP-Adresse konfiguriere und den Shelly neu starte, funktoniert er wieder fehlerfrei, antwortet auf alle PINGs, etc. Ich kann ihn dann nur nicht über FHEm bedienen. Hast Du irgendeine Idee?
Andere Shellys (2.5, 1 PM, RGB) funktionieren tadellos.
Gruß
Lars
ich tappe im Dunkel. Noch.
LG
pah
Helfen weitere Logs?
ZitatNächster Versuch ...
LG
pah
Falls es noch keiner gestestet hat, die modulversion 4.02d funktioniert für eine shellyplus2pm, wenn 2 Lampen angeschlossen sind.
Danke
habe gerade die Shelly Beta 1 von 0.11 getestet, nach Changelog sind darin einige Härtungen. Verbessert aber leider nicht die Situation.
Scripts: Script causing device crashes are detected and disabled automatically.
Power values oscillation between 0W and 1W on Plus1PM
Crash when calling Shelly.Update without parameters
Wrong aenergy values with low-power loads on Pro devices
Validation of cid and event parameters of Webhook.Create, Webhook.Update
Crash due to race-conditions between TCP errors and queued callbacks
Poor device responsiveness during HTTPS webhooks execution
melde mich jetzt auch nochmal, weil ich Probleme mit dem Modul habe.
EDIT:// ich sehe gerade im device das Shellypro2 gar nicht mehr als model anwählbar ist...!
gestern habe ich ein Update in Fhem gemacht, da habe ich gesehen das das Shellymodul dabei war.
Heute nun wollte ich meine Markise fahren und es funktioniert nicht mehr.
Über den Shelly Webserver kann ich die Markise steuern, über Fhem nicht.
Im Log sehe ich keine weiteren Fehler
Die Markise zeigt auch einen Error im device.
list von AU_markise
Internals:
DEF 10.0.0.166
DURATION 0
FUUID 62a33e9d-f33f-a6c6-f784-434504772be7f065
INTERVAL 60
NAME AU_markise
NR 6087
STATE Error
TCPIP 10.0.0.166
TYPE Shelly
eventCount 39
READINGS:
2022-07-17 00:25:35 inttemp 34.9
2022-07-17 01:11:07 network <html>connected to <a href="http://10.0.0.166">10.0.0.166</a></html>
2022-07-16 21:38:52 relay_0 off
2022-07-16 21:38:52 relay_1 on
2022-07-17 15:33:26 state Error
Attributes:
defchannel 2
group Terrassen Markise
icon awning@blue
mode relay
model shellypro2
room Draußen
mehr wird gerade nicht angezeigt, was kann ich noch tun zur Fehlerfindung.? Device nochmals anlegen..? oder ist der Rollermode schon eingebaut.?
ich habe jetzt das Modul vom 14.06. wieder eingesetzt, nun funktioniert es erst einmal wieder.
Version 4.02d
Hallo,
habe ein Shelly 3 EM in meinen Zählerkasten montiert und funktioniert soweit.
Über das Web-Interface (192.168.33.43) wird mir der aktuelle Stromverbrauch angezeigt und kann auch auf die Einstellungen zugreifen.
Möchte jetzt den Stromverbrauch mit FHEM aufzeichnen lassen.
Weil ich nicht wusste, ob ich MQTT2 benötige oder MQTT (1) gemeinsamt nutzen kann (weil ich dies bereits anderweitig zur Rollo-Steuerung nutze), habe ich im folgenden Thread bereits Hilfe erhalten.
Deshalb habe ich folgende Definition in FHEM angelegt:
defmod myShelly3EM Shelly 192.168.33.43
attr myShelly3EM event-on-change-reading .*
attr myShelly3EM icon measure_power
attr myShelly3EM interval 10
attr myShelly3EM model shelly3em
Leider wird mir aber in diesen Device als state: "Error" angezeigt.
Wo liegt hier der Fehler?
Das Anlegen hat ohne Probleme funktioniert.
Hier das List vom Device myShelly3EM
Internals:
CFGFN
DEF 192.168.33.43
DURATION 0
FUUID 62d482b6-f33f-194f-8799-63d36cf87bf813a5
INTERVAL 10
NAME myShelly3EM
NR 233111
SHELLYID shellyem3-BCFF4DFD1A0D
STATE Error
TCPIP 192.168.33.43
TYPE Shelly
Helper:
DBLOG:
state:
DbLog:
TIME 1658107248.58969
VALUE Error
READINGS:
2022-07-18 09:17:12 cloud enabled(connected)
2022-07-17 23:47:44 firmware v1.11.8
2022-07-18 03:20:58 network <html>connected to <a href="http://192.168.33.43">192.168.33.43</a></html>
2022-07-18 03:20:48 state Error
Attributes:
event-on-change-reading .*
icon measure_power
interval 10
model shelly3em
room Flur
bei mir war das mit dem state beim anlegen des device, ebenfalls so.
Beim ersten betätigen war dieser Error verwschwunden, ich nutze allerdings ein Shelly2pro, weiß jetzt nicht ob man das vergleichen kann.
Erhälst du erste Werte und der Error bleibt bestehen, dann kann pah sicher was dazu sagen
Ich erhalte nur die Werte, welche im gezeigten List bei Readings aufgeführt ist.
Was meinst Du mit "ersten Betätigen"?
Neugestartet habe ich das ShellyEM3 bereits; aber ohne Veränderung.
Mir ist gerade aufgefallen, dass ich beim Anlegen folgendes eingegeben habe
attr myShelly3EM model shelly3em
Das Shelly heißt aber eigentlich shellyEM3. Kann hier der Fehler liegen und ich sollte es mal mit folgenden versuchen?
attr myShelly3EM model shellyem3
Wobei es auf der Homepage von Shelly trotzdem Shelly3EM heißt (EM3 heißt es im Webinterface).
Also wird es daran auch nicht liegen.
Zitat von: Ruggy am 18 Juli 2022, 14:17:25
Was meinst Du mit "ersten Betätigen"?
Neugestartet habe ich das ShellyEM3 bereits; aber ohne Veränderung.
damit meine ich in meinem Fall das ich es einmal geschaltet habe, bei dir wäre es ja dann wenn die ersten Werte verfügbar sind.
Na warten wir mal was pah sagt, ich habe ja mit dem aktuellen Modul auch Probleme und habe deshalb eine ältere Version zurück kopiert
Zitat von: moonsorrox am 18 Juli 2022, 14:59:00
Na warten wir mal was pah sagt, ich habe ja mit dem aktuellen Modul auch Probleme und habe deshalb eine ältere Version zurück kopiert
Evlt. hat es ja auch damit zu tun.
Hoffe es gibt ne Lösung.
Wie kann man eine ältere Version zurück kopieren?
Mal ganz was anderes...
Angenommen ein Shelly 2.5 (Rollo) hat schlechten WLAN Empfang und verpasst einen Fahrbefehl.
Wenn er sich dann wieder verbindet fährt er den Befehl nicht ab. Das Modul müsste aber eigentlich wissen wo er stehen müsste.
Wie bekomme ich ihn denn dazu den Befehl dann auszuführen?
möchte ungern einen Dummy dazwischen schalten und den Shelly damit nochmal triggern.
Hallo zusammen,
habe auf der Suche nach dem ADC Voltage Parameter für den Shelly Uni einen kleinen Typo im Modul gefunden (sub Shelly_proc1G):
Es fehlt das "y" bei Shelly ;-)
if ($model eq "shelluni") {
my $voltage = $jhash->{'adcs'}[0]{'voltage'};
readingsBulkUpdateIfChanged($hash,"voltage",$voltage);
}
EDIT:
scheint nach wie vor trotzdem keine Werte auszugeben, habe auch schon das Device neu angelegt.
Wäre super wenn hier jemand mit mehr Code-Erfahrung mal drüber schauen könnte! Evtl ist es ja nur eine Kleinigkeit
EDIT2:
Hat sich erledigt - mit einem "reload 36_Shelly.pm" wurden die Änderungen übernommen --> voltage wird jetzt mit ausgegeben!
Zitat von: moonsorrox am 17 Juli 2022, 22:35:08
ich habe jetzt das Modul vom 14.06. wieder eingesetzt, nun funktioniert es erst einmal wieder.
Version 4.02d
ich habe heute ein Update gemacht und das aktuelle Shelly Modul arbeitet noch immer nicht mit meinem Shelly2pro zusammen.
Wie schon mal geschrieben kann ich auch das device shellypro2 nicht mit dem aktuellen Shelly Modul anwählen.
Ist da was in Arbeit momentan.?
Bei mir funktioniert das Shelly 3EM immer noch nicht (Problematik; siehe Antwort #186).
Es wird immer noch folgendes angezeigt.
state: "Error"
Hat jemand eine Idee an was es liegen könnte oder wie man den Fehler eingrenzen könnte?
Zitat von: Ruggy am 18 Juli 2022, 14:20:17
Mir ist gerade aufgefallen, dass ich beim Anlegen folgendes eingegeben habe
attr myShelly3EM model shelly3em
Das Shelly heißt aber eigentlich shellyEM3. Kann hier der Fehler liegen und ich sollte es mal mit folgenden versuchen?
attr myShelly3EM model shellyem3
Das Attribut model liefert eine Drop-down-Auswahlliste, aus der man das Modell
auswählt, da wird nichts eingetragen.
Das Reading steht bei mir auf OK. Es wird nicht zyklisch verändert. Ich nehme an, dass es nur nach dem Starten des Shelly gesendet wird. Den Shelly neustarten hast zu sicher versucht, ebenfalls das Relais ein- und auszuschalten.
Vielleicht könntest du Screenshot von den Shelly-Einstellungen senden; vielleicht sieht dann jemand mit mehr Kenntnissen als du und ich etwas.
Viele Grüße Gisbert
@Gisbert
Hast recht, beim Attribut ist ein Dropdown und das richtige ausgewählt.
Einen Neustart habe ich gemacht aber ändert nichts am Error.
Wo bzw. wie kann ich ein Relais einschalten?
Der Raspberry mit FHEM hat die IP 192.168.33.41:8084
Ich verwende MQTT (1).
Hierzu habe ich bereits einen Thread gestartet ob MQTT 1 oder besser 2 (MQTT nutze ich bisher zum steuern von Rollläden).
https://forum.fhem.de/index.php/topic,128427.0.html
Dort im Thread befinden sich auch Lists von ein paar Devices.
Hier mal die Screenshots von den Einstellungen vom ShellyEM3:
ZitatWenn er sich dann wieder verbindet fährt er den Befehl nicht ab. Das Modul müsste aber eigentlich wissen wo er stehen müsste.
Wie bekomme ich ihn denn dazu den Befehl dann auszuführen?
Versteh ich nicht - das Modul bekommt doch den Status von Shelly, und damit nach der ersten Aktualisierung den aktuellem Stand?
@CaptainSlow: Änderung wird übernommen.
@Ruggy: Ich verstehe nicht so ganz, was hier das Problem ist - mal ist die Rede von MQTT, dann wieder vom Shelly-Modul. Bitte etwas deutlicher beschreiben.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 29 Juli 2022, 15:19:11
Versteh ich nicht - das Modul bekommt doch den Status von Shelly, und damit nach der ersten Aktualisierung den aktuellem Stand?
Hallo Peter,
wenn man den Shelly nur per FHEM steuert, also nicht über lokale Taster, dann nimmt das Modul den Fahrbefehl erst gar nicht an wenn der Shelly da gerade offline ist.
Und als Folge daraus wird der Befehl auch nicht ausgeführt wenn er wieder online kommt.
Grüße
Frank
ich melde mich auch nochmals zu meinem Problem das ich den Shelly (shellypro2) gar nicht mehr in der Auswahlliste habe. Ich kopiere immer das ältere Modul Version 4.02d wieder zurück mit dem es funktioniert
@Ruggy,
für das Shelly-Modul von pah wird MQTT nicht benötigt.
Viele Grüße Gisbert
Zitatwenn man den Shelly nur per FHEM steuert, also nicht über lokale Taster, dann nimmt das Modul den Fahrbefehl erst gar nicht an wenn der Shelly da gerade offline ist.
Und als Folge daraus wird der Befehl auch nicht ausgeführt wenn er wieder online kommt.
Ja, richtig. So soll es auch sein, FHEM bietet nur an ganz wenigen Stellen Puffer für nicht ausgeführte Befehle.
LG
pah
Hm, einen
Zitatshellypro2
gibt es in der Auswahlliste des aktuellen Moduls sehr wohl.
LG
pah
@Prof. Dr. Peter Henning
@Gisbert
Bringe es anscheinend immer noch durcheinander bzgl. MQTT und dem Modul von pah.
Aufgrund folgenden Threads https://forum.fhem.de/index.php/topic,128427.0.html habe ich folgenden Code von @Gisbert (für das Modul von pah) verwendet.
defmod myShelly3EM Shelly 192.168.33.43
attr myShelly3EM event-on-change-reading .*
attr myShelly3EM icon measure_power
attr myShelly3EM interval 10
attr myShelly3EM model shelly3em
Also nutze ich demnach MQTT gar nicht?
Wie bereits geschrieben wird im Device myShelly3EM state Error angezeigt
List vom myShelly3EM
Internals:
DEF 192.168.33.43
DURATION 0
FUUID 62d482b6-f33f-194f-8799-63d36cf87bf813a5
INTERVAL 10
NAME myShelly3EM
NR 593
SHELLYID shellyem3-BCFF4DFD1A0D
STATE Error
TCPIP 192.168.33.43
TYPE Shelly
Helper:
DBLOG:
state:
DbLog:
TIME 1658560137.48082
VALUE Error
READINGS:
2022-07-29 06:49:31 cloud disabled
2022-07-17 23:47:44 firmware v1.11.8
2022-07-27 20:46:14 network <html>connected to <a href="http://192.168.33.43">192.168.33.43</a></html>
2022-07-27 20:46:04 state Error
Attributes:
event-on-change-reading .*
icon measure_power
interval 10
model shelly3em
room Flur
Im Shelly Webserver habe ich "Enable MQTT" mal aktiviert und auch mal deaktiviert.
Der Fehler wird aber immer noch angezeigt.
Die Einstellungen vom Webserver kann man in den Screenshots sehen.
Auf den Webserver von Shelly kann ich über die IP Adresse 192.168.33.43 zugreifen.
Zitat von: Prof. Dr. Peter Henning am 29 Juli 2022, 16:12:21
Ja, richtig. So soll es auch sein, FHEM bietet nur an ganz wenigen Stellen Puffer für nicht ausgeführte Befehle.
schade. es würde schon reichen wenn das Modul den Befehl annimmt und den Status setzt während offline.
dann könnte ich auf das online kommen reagieren und den pct nochmal schicken.
als Workaround bin ich am überlegen einen dummy vorzuschalten um die Werte zu puffern um dann im offline/online Fall den Befehl nachzuholen.
Zitat von: Prof. Dr. Peter Henning am 29 Juli 2022, 16:18:57
Hm, einen gibt es in der Auswahlliste des aktuellen Moduls sehr wohl.
LG
pah
mit dem angehängten Modul funktioniert es wieder..! Danke pah
Ich hatte vor 2 Tagen ein Fhem Update gemacht, damit ging es leider nicht.
Nutze die Markise gerade jetzt wegen der Sonne jeden Tag, daher kann ich es ganz gut nachvollziehen.
Beim Anlegen des Devices (siehe oben) habe ich folgendes Attribut festgelegt (nicht über Dropdown sondern über die Befehlszeile).
attr myShelly3EM model shelly3em
Habe jetzt beim Device im Dropdownmenü bei den Attributen gesehen, dass dort als Model nur shellyem3 also die 3 hinten ausgewählt werden kann.
Habe jetzt das im Dropdown angebotene shellyem3 ausgewählt.
Angezeigt wird aber trotzdem noch der Error bei state
Habe jetzt das Device myShelly3EM gelöscht und nochmal neu angelegt.
Diesmal nicht über die Befehlszeile sondert alle (bis aufs anlegen) über dropdown.
Jetzt wird state initialized angezeigt.
Readings werden aber keine weiteren außer cloud, firmware, network und state angezeigt.
Wird hier nicht der Stromverbrauch z.B. Watt oder Ampere angezeigt?
Habe ich es falsch verstanden?
Hallo Ruggy,
auf dem Homebildschirm des Shelly 3EM ist ein Switch mit An-/Ausschalter vorhanden. Betätige diesen mal und warte mindestens das eingestellte Intervall ab, dann müsste das reading relay von off auf on (oder umgekehrt) wechseln.
Berichte mal, was im Fhem-Device ankommt.
Viele Grüße Gisbert
Hallo Gisbert,
habe den Switch an- und ausgeschalten. Es hat sich bei den readings nichts verändert. Das reading relay habe ich auch gar nicht.
Habe nur cloud, firmware, network und state.
Habe jetzt noch auf dem Homebildschirm vom Shelly die Uhrzeit und Datum eingestellt, das Gerät und die drei Kanäle benannt.
Danach einen Neustart gemacht und später auch nochmal den An- und Ausschalter betätigt.
Es ändert sich aber trotzdem nichts.
Welche readings werden denn bei Dir an gezeigt?
Danke für Dein Bemühen.
Viele Grüße
Ruggy
Hallo Ruggy,
ich kann gerade kein list meines Devices kopieren, hab im Moment nur das Handy in Reichweite, und da krieg das Kopieren des list nicht hin.
An Readings hab ich alles mögliche, was der Shelly bereithält: für jede Phase die Spannung, Leistung, Energie und noch ein paar weitere.
Ich benutze keine Cloud von Shelly, warum auch, ich hab ja Fhem. Vielleicht macht dies den Unterschied.
Viele Grüße Gisbert
Kein Problem. Zumindes weiß ich, dass es noch andere readings anzeigen sollte.
Evlt. hat ja noch jemand anderes eine Idee oder auch pah.
Die Cloud habe ich aber auch deaktiviert und wollte es deshalb mit FHEM versuchen.
Oder ich versuche es doch mal mit MQTT.
Von einem MQTT-Device in Fhem, dass Daten vom Shelly empfängt, kann ich nur abraten. Das hat bei mir jedenfalls ganz schön Ressourcen des Servers beansprucht, das war nicht mehr feierlich.
ZitatUhrzeit und Datum eingestellt,
Wieso das denn? Die holt er sich aus dem Netz.
Außerdem einfach im FHEM-Device mal "get ... status" abfragen.
Vorher verbose auf 5 und nachher schauen, was im Log steht.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 30 Juli 2022, 11:45:53
Wieso das denn? Die holt er sich aus dem Netz.
Ich kenne mich leider nicht so gut aus und ich hoffte, dass es dann evlt. funktioniert.
Dachte mir, dass ich das Gerät, Kanäle und halt Datum und Uhrzeit erst benennen bzw. einstellen muß, damit fhem etwas holen kann.
Hoffe es war so gemeint und habe jetzt im Device myShelly3EM Verbose 5 als Attribut hinzugefüht.
Hier dann ein Ausschnitt aus dem Logfile. Diese beiden wurden zur selben Uhrzeit geloggt.
Nach diesem müssten aber die Werte geliefert werden. Aber im Gerät werden sie nicht angezeigt.
2022.07.30 14:52:21 5: [Shelly_status] Issue a non-blocking call to http://192.168.33.43/status
2022.07.30 14:52:21 5: [Shelly_status] has obtained data {"wifi_sta":{"connected":true,"ssid":"XXXXXXX","ip":"192.168.33.43","rssi":-61},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"14:52","unixtime":1659185540,"serial":13926,"has_update":false,"mac":"BCEE4DF4rA0D","cfg_changed_cnt":6,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"is_valid":true,"source":"http"}],"emeters":[{"power":110.58,"pf":0.80,"current":0.62,"voltage":224.70,"is_valid":true,"total":155579.3,"total_returned":0.0},{"power":14.64,"pf":0.75,"current":0.09,"voltage":226.77,"is_valid":true,"total":95594.4,"total_returned":0.0},{"power":18.35,"pf":0.58,"current":0.14,"voltage":225.85,"is_valid":true,"total":99490.3,"total_returned":0.0}],"total_power":143.57,"fs_mounted":true,"update":{"status":"idle","has_update":false,"new_version":"20220324-123835/v1.11.8-3EM-fix-g0014dcb","old_version":"20220324-123835/v1.11.8-3EM-fix-g0014dcb"},"ram_total":49440,"ram_free":31412,"fs_size":233681,"fs_free":157126,"uptime":61577}
Hier noch ein List vom Device und ein Screenshot davon:
Internals:
CFGFN
DEF 192.168.33.43
DURATION 0
FUUID 62e40cd8-f33f-194f-56f0-f2b9dcf9fc236621
INTERVAL 10
NAME myShelly3EM
NR 28259
SHELLYID shellyem3-BCFF4DFD1A0D
STATE initialized
TCPIP 192.168.33.43
TYPE Shelly
Helper:
DBLOG:
state:
DbLog:
TIME 1659112664.92758
VALUE initialized
READINGS:
2022-07-29 18:37:45 cloud disabled
2022-07-29 18:37:45 firmware v1.11.8
2022-07-29 18:37:44 network <html>connected to <a href="http://192.168.33.43">192.168.33.43</a></html>
2022-07-29 18:37:44 state initialized
Attributes:
event-on-change-reading .*
icon measure_power
interval 10
mode relay
model shellyem3
room Flur
verbose 5
Ich kann eigentlich nur den Kopf schütteln. Ich wette mal, dass ein "get ... version" eine Uraltversion anzeigt.
Schon seit längerer Zeit (!) muss das model-Attribut für dieses Gerät auf shelly3em gesetzt werden, nicht auf shellyem3
Und nichts anderes wird im Auswahlmenü angeboten.
Der Hersteller ist bei den Benennungen absolut chaotisch vorgegangen, ich habe versucht, das minimal zu systematisieren. Fehlt zwar noch in der CommandRef dieser Beta-Version, im Modul selber aber läuft es.
LG
pah
Version wird 3.4 angezeigt.
Als Auswahl habe ich aber nur shellyem3 und das habe ich ausgewählt (siehe Screenshot).
Als Firmware habe ich laut Shelly die aktuellste (siehe Screenshot).
Oder ist die Version 3.4 die vom Shelly Modul und ich sollte beim FHEM ein Update machen.
Bin hierbei bisher vorsichtig umgegangen, weil ich nach einem Update schon mal Probleme hatte.
Wenns daran liegt, mache ich aber eines.
Ich muß mich bei allen entschuldigen, welche ich mit meinem Problem belästigt habe.
Es lag an mir und dass ich von den Shelly Modul eine alte Version installiert hatte.
Ich habe jetzt nur für das Modul 36_Shelly.pm ein Update gemacht (habe bisher gedacht, dass ich nur alles auf einmal updaten kann).
Dann habe ich das Device gelöscht und neu angelegt (weiß nicht, ob ich das hätte machen müssen).
Jetzt zeigt es alle readings an.
Danke für Euere Geduld.
Kein Problem.
Erkenntnisgewinn ergibt sich nur durch Falsifikation von Hypothesen. Wir lernen also aus Fehlern.
LG
pah
ZitatIch habe jetzt nur für das Modul 36_Shelly.pm ein Update gemacht (habe bisher gedacht, dass ich nur alles auf einmal updaten kann).
Ich mache
jede Woche ein Fhem-Update (automatisch mit einem DOIF), manchmal auch noch zwischendurch, wenn ich an einem Update eines Moduls interessiert bin. Ebenso halte ich Linux und Perl up to date. Ich mache das schon etliche Jahre so und hab noch nie Nachteile bemerkt. Es kann schon sein, dass ein Modul eine Macke hat, die aber schnell gefixt wird.
Man kann auch ein Modul auch vom Update ausschließen, wenn man mit einer Neuerung nicht einverstanden ist.
Viele Grüße Gisbert
Dann werde ich mich mal demnächst an ein Update wagen und dies auch regelmäßiger durchführen.
Ich dachte hier nur an die "Weisheit" "never touch a running system"
Hallo Ruggy,
"never touch a running system" stimmt schon, solange alles läuft, gibt es keine Notwendigkeit etwas zu ändern.
Das hast du aber gerade nicht getan, indem du ein Modul benutzt hast, das vorher (vermutlich) nicht im Einsatz war. Ich würde es nicht bei einem Fhem-Update belassen, sondern Linux und ggf. Perl (cpan, falls du dies benutzt) auch updaten. Generell ist es klug Backups vorher zu machen. Manche Updates fragen sogar bei Linux nach, ob man ein Backup hat. Bevor ich mich auf fremdes Terrain begebe (also fast immer) frag ich mich, was machst du, wenn es schief geht. Das mindeste ist mal, dass ich genügend Zeit und Muße für eine Reparatur habe.
Bei verbauten ESP8266/32 mit Tasmota/ESPEasy halte ich mich mit OTA in der Regel mit Firmware-Updates zurück, es sei denn ich weiß, dass ich an das Teil eh ran muss. Dann probier ich gerne aus, ob OTA funktioniert, was es oft nicht tut.
Viele Grüße Gisbert
Naja, Du hast schon recht. Ein Update hätte bei der Shelly viel Ärger erspart.
Backup mache ich und das Update muß noch etwas warten.
Derzeit hätte ich wenig Zeit mit Fehlersuche. Und wenn ich nicht weiter komme müsste ich wieder das Forum bemühen.
Viele Grüße
Ruggy
ZitatUnd wenn ich nicht weiter komme müsste ich wieder das Forum bemühen.
Dafür ist das Forum da, nur Mut.
Hallo,
ich habe bei mir verschiedene Shelly-Module im Einsatz. Die Shelly1 tauchen im FHEM zum Beispiel auch "problemlos" auf und lassen sich bedienen.
Allerdings bei den RGBW-Controllern ("4-Farb"-Modus) habe ich das Problem, dass im FHEM Interface keine Steuermöglichkeit angezeigt wird. Es gibt lediglich den Hinweis "Initialized" bzw. "Error", aber es gibt z.B. keine set-Methoden.
SHELLYID
shellyrgbw2-4E39B3
STATE
initialized
TCPIP
192.168.178.32
TYPE
Shelly
eventCount
2
Readings
cloud
disabled
firmware
v1.11.8
network
connected to 192.168.178.32
state
initialized
Attributes
model
shellyrgbw
Ist das Verhalten so iO?
(Wo) Gibt es eine Doku, wie die Shelly RGBW Controller anzusteuern sind?
Bitte die CommandRef lesen. Es fehlt das mode-Attribut.
LG
pah
Hallo,
da mich die WLAN-Empfangsstärke der Module interessiert hat, habe ich hierfür ein Reading "wlan_rssi" erzeugt, das den wert enthält.
Das Diff bezieht sich auf die aktuelle Version nach update.
diff /opt/fhem/FHEM/36_Shelly.pm 36_Shelly.pm
1115a1116,1119
> #-- for all models set internal rssi reading
> if ($jhash->{'wifi_sta'}{'rssi'}) {
> readingsBulkUpdateIfChanged($hash,"wlan_rssi",$jhash->{'wifi_sta'}{'rssi'});
> }
Vielleicht kann das jemand brauchen.
Gruß
Stefan
Das werde ich nicht in das veröffentlichte Modul einbauen.
LG
pah
Hallo miteinander,
seit ich jüngst mein neues Shelly Plus 1PM in FHEM eingebunden habe, bekomme ich im 5-Minuten-Rhythmus (->attr interval 300) diese Fehlermeldungen im Log:
PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4981.
stacktrace:
main::__ANON__ called by fhem.pl (4981)
main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (1426)
main::Shelly_proc2G called by ./FHEM/36_Shelly.pm (1071)
main::__ANON__ called by FHEM/HttpUtils.pm (720)
main::__ANON__ called by fhem.pl (778)
Welche Informationen müsste ich noch liefern, um der Sache auf die Spur zu kommen?
(fhem.pl:26248/2022-07-19 perl:5.024001 os:linux - läuft auf einem RasPi)
Das sind keine Fehlermeldungen, sondern nur Warnungen. Kann man ignorieren.
Und ohne dass ich weiß, welche Modulversion benutzt wird, kann ich das auch nicht in einem der nächsten Releases beheben.
LG
pah
Hallo in die Runde, ich hoffe, ich bin mit der Frage richtig im Support-Thread für Shelly:
Ich habe zahlreiche Shelly Plug S (model shellyplug) im Einsatz, und die scheinen soweit auch gut zu funktionieren.
(Zuvor hatte ich Fritz!DECT und Homemmatic am Start.)
Was ich vermisse, sind Nachrichten im Log.
Ich würde mir wünschen, dass im Log das Ein- und das Ausschalten geloggt werden kann.
Dazu habe ich mein Glück mit verschiedenen Werten des Attributs "verbose" versucht. (event-on-update-reading hat "status,power,energy,etc.)
Bei 0-4 passiert meiner Wahrnehmung nach im Log genau nichts.
Bei 5 oder 6 wird das Log sehr großzügig und periodisch geflutet.
1.) Gibt es etwas dazwischen?
2.) Wie erreiche ich das?
Danke vorab für Euer Hirnschmalz!
FrankSausF
Zitat von: Gisbert am 31 Juli 2022, 19:13:15
Dafür ist das Forum da, nur Mut.
Ich bin jetzt mal mutig und möchte mich mit einer weiteren Frage an euch wenden. ;-)
Nach den "Startschwierigkeiten" funktioniert die Shelly3em mit den ShellyModul ohne Probleme.
Es werden u.a. die Readings Power_0 bis Power_2 (aktueller Verbrauch in Watt) und energy_0 bis energy_2 (Gesamtverbrauch über gesamten Zeitraum) angezeigt.
Diese Readings lasse ich mir derzeit in zwei SVG-Plots anzeigen.
Den Plot mit dem Verbrauch finde ich ganz Praktisch um die täglichen Schwankungen zu sehen.
Aus dem Plot mit dem Gesamtverbrauch kann man wenig herauslesen. Die drei Graphen für die drei Phasen steigen halt immer mehr an.
Wie kann ich FHEM konfigurieren, um den (täglichen, wöchentlichen) monatlichen und jährlichen Verbrauch in Zahlen und in einer Balkengrafik darstellen zu können.
Habe auch von der "Problematik" gelesen, dass z.B. nach einen Stromausfall die Messwerte der Shelly3em wieder auf Null zurück gesetzt werden.
Vielen Dank
Grüße
Ruggy
Zitat von: Ruggy am 16 August 2022, 09:41:34
Wie kann ich FHEM konfigurieren, um den (täglichen, wöchentlichen) monatlichen und jährlichen Verbrauch in Zahlen und in einer Balkengrafik darstellen zu können.
Habe auch von der "Problematik" gelesen, dass z.B. nach einen Stromausfall die Messwerte der Shelly3em wieder auf Null zurück gesetzt werden.
Hi,
schau die mal das Statistics Modul an. Denke das ist das was Du suchst.
https://wiki.fhem.de/wiki/Statistics
/Frank
Habe mir das Statistic Modul mal angesehen und es auch getestet.
Die Shelly3em stellt ja Readings für die drei Phasen zur Verfügung (energy_0, energy_1 und energy_2).
Habe jetzt im Statistik Modul diese drei Readings bei deltareadings eingetragen und auch bei singularReadings
Im Shelly3em Device werden aber nur die Readings (statEnergy_0) im Zusammenhang mit Energy_0 aktualisiert.
Kann ich diese Readings so nicht zusammenfassend eintragen?
Hier das List vom Shelly3em und von dem eben angelegten myStatDevice:
Internals:
DEF 192.168.33.43
DURATION 0
FUUID 62e55f01-f33f-194f-c60d-526add52254d1b91
INTERVAL 20
NAME myShellyEM3
NR 601
SHELLYID shellyem3-BCFF4DFD1A0D
STATE OK
TCPIP 192.168.33.43
TYPE Shelly
Helper:
DBLOG:
energy_0:
DbLog:
TIME 1660645203.14565
VALUE 190123.7
energy_1:
DbLog:
TIME 1660645203.14565
VALUE 121982.5
energy_2:
DbLog:
TIME 1660645203.14565
VALUE 121419.1
power_0:
DbLog:
TIME 1660645243.36178
VALUE 51.7
power_1:
DbLog:
TIME 1660645243.36178
VALUE 110.12
power_2:
DbLog:
TIME 1660645243.36178
VALUE 29.09
state:
DbLog:
TIME 1660644639.3385
VALUE OK
READINGS:
2022-07-30 18:40:34 cloud disabled
2022-08-16 12:20:03 energy_0 190123.7
2022-08-16 12:20:03 energy_1 121982.5
2022-08-16 12:20:03 energy_2 121419.1
2022-07-30 18:40:34 firmware v1.11.8
2022-08-16 12:10:34 network <html>connected to <a href="http://192.168.33.43">192.168.33.43</a></html>
2022-07-30 18:41:55 overpower 0
2022-08-16 12:20:43 power_0 51.7
2022-08-16 12:20:43 power_1 110.12
2022-08-16 12:20:43 power_2 29.09
2022-07-30 18:54:36 relay on
2022-08-16 12:03:39 statEnergy_0 Hour: 8.7 Day: 8.7 Month: 8.7 Year: 8.7 (since: 2022-08-16_11:59:38 )
2022-08-16 12:03:39 statEnergy_0Day 8.7
2022-08-16 12:03:39 statEnergy_0Hour 8.7
2022-08-16 11:59:55 statEnergy_0Last Hour: 0.0 Day: - Month: - Year: - (since: 2022-08-16_11:59:38 )
2022-08-16 12:03:39 statEnergy_0Month 8.7
2022-08-16 12:03:39 statEnergy_0Year 8.7
2022-08-16 12:03:59 statEnergy_1 Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2022-08-16_12:03:59 )
2022-08-16 12:04:19 statEnergy_2 Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2022-08-16_12:04:19 )
2022-08-16 12:20:43 statStateDay OK: 00:47:57 OK_Count: 1 (since: 2022-08-16_11:32:46)
2022-08-16 12:20:43 statStateMonth OK: 00:47:57 OK_Count: 1 (since: 2022-08-16_11:32:46)
2022-08-16 12:20:43 statStateYear OK: 00:47:57 OK_Count: 1 (since: 2022-08-16_11:32:46)
2022-08-16 12:10:39 state OK
2022-08-16 12:20:43 voltage_0 228.83
2022-08-16 12:20:43 voltage_1 227.11
2022-08-16 12:20:43 voltage_2 226.46
helper:
_98_statistics myStatDevice
Attributes:
event-on-change-reading .*
icon measure_power
interval 20
model shelly3em
room Flur
Internals:
DEF myShellyEM3
DEV_REGEXP myShellyEM3
FUUID 62fb643b-f33f-194f-2bd3-3447dfa3379f9ed5
NAME myStatDevice
NOTIFYDEV global,myShellyEM3
NR 611
NTFY_ORDER 10-myStatDevice
PREFIX stat
STATE Updated stats for: myShellyEM3
TYPE statistics
Helper:
DBLOG:
state:
DbLog:
TIME 1660645283.67563
VALUE Updated stats for: myShellyEM3
READINGS:
2022-08-16 12:10:39 monitoredDevicesShelly myShellyEM3
2022-08-16 12:10:45 nextPeriodChangeCalc 2022-08-16 12:59:55
2022-08-16 12:21:23 state Updated stats for: myShellyEM3
fhem:
modulVersion $Date: 2022-07-12 07:25:06 +0200 (Tue, 12 Jul 2022) $
nextPeriodChangeTime 1660647595
Attributes:
deltaReadings energy_0|energy_1|energy_2
room Plots
singularReadings myShellyEM3:energy_0:Delta:Hour|myShellyEM3:energy_0:Delta:Day|myShellyEM3:energy_0:Delta:Month|myShellyEM3:energy_0:Delta:Year|myShellyEM3:energy_1:Delta:Hour|myShellyEM3:energy_1:Delta:Day|myShellyEM3:energy_1:Delta:Month|myShellyEM3:energy_1:Delta:Year|myShellyEM3:energy_2:Delta:Hour|myShellyEM3:energy_2:Delta:Day|myShellyEM3:energy_2:Delta:Month|myShellyEM3:energy_2:Delta:Year
Zitat von: Ruggy am 16 August 2022, 12:22:15
Habe mir das Statistic Modul mal angesehen und es auch getestet.
Die Shelly3em stellt ja Readings für die drei Phasen zur Verfügung (energy_0, energy_1 und energy_2).
Habe jetzt im Statistik Modul diese drei Readings bei deltareadings eingetragen und auch bei singularReadings
Im Shelly3em Device werden aber nur die Readings (statEnergy_0) im Zusammenhang mit Energy_0 aktualisiert.
Kann ich diese Readings so nicht zusammenfassend eintragen?
Hi Ruggy,
mein Shelly hat zudem weitere Readings:
emeter_total
emeter_total_net
emeter_total_returned
Dazu steht im Attribut "userreadings" (Zeilenumbrüche ggf. wegnehmen, die habe ich hier zur besseren Übersicht eingefügt):
emeter_0_energy_total:emeter_0_energy:.* monotonic {ReadingsNum("$name","emeter_0_energy",0)}, emeter_1_energy_total:emeter_1_energy:.* monotonic {ReadingsNum("$name","emeter_1_energy",0)}, emeter_2_energy_total:emeter_2_energy:.* monotonic {ReadingsNum("$name","emeter_2_energy",0)},
totalpower:(emeter_0_power:.*|emeter_1_power:.*|emeter_2_power:.*) {ReadingsNum("$name","emeter_2_power",0)+ReadingsNum("$name","emeter_1_power",0)+ReadingsNum("$name","emeter_0_power",0)},
emeter_total:(emeter_0_total:.*|emeter_1_total:.*|emeter_2_total:.*) {ReadingsNum("$name","emeter_2_total",0)+ReadingsNum("$name","emeter_1_total",0)+ReadingsNum("$name","emeter_0_total",0)}, emeter_total_returned:(emeter_0_total_returned:.*|emeter_1_total_returned:.*|emeter_2_total_returned:.*) {ReadingsNum("$name","emeter_2_total_returned",0)+ReadingsNum("$name","emeter_1_total_returned",0)+ReadingsNum("$name","emeter_0_total_returned",0)},
emeter_total_net:(emeter_0_total:.*|emeter_1_total:.*|emeter_2_total:.*|emeter_0_total_returned:.*|emeter_1_total_returned:.*|emeter_2_total_returned:.*) {ReadingsNum("$name","emeter_2_total",0)+ReadingsNum("$name","emeter_1_total",0)+ReadingsNum("$name","emeter_0_total",0)-ReadingsNum("$name","emeter_2_total_returned",0)-ReadingsNum("$name","emeter_1_total_returned",0)-ReadingsNum("$name","emeter_0_total_returned",0)}
Wenn Du auf diese Readigns die Statistik machst, müsste das eigentlich wie von Dir gewünscht klappen.
Bei mir tut's das.
Ich hab' dann aber immer noch ein Dummy-Device am Start, um den in HT/NT arbeitenden offiziellen Elektrozähler abzubilden.
Etwas Vorsicht bei den Logs: Der Shelly ballert ein einfaches Filelog gnadenlos zu, da mußt Du, damit Deine SVGs performant bleiben, die zu loggenden Readings / Events stark ausdünnen.
Ich hab' zum Beispiel für die Werte der letzten Tage, Wochen, Monate ein "Yesterlog", in das nur die LAST-Werte der Statistics geloggt werden.
Weiterer Tipp zum SVG: Wenn Du Statistics normal laufen lässt, werden die Werte NACH Mitternacht erhoben. Genau genommen für einen "LAST" Wert richtig. Du willst ihn aber im Graphen nicht am Tag, sondern am Vortag sehen. Also stell' bei den Statistics ein, dass die Statistik 5 Sekunden vor Mitternacht gemacht wird...
@FSausF
Die Readings emeter_total usw. habe ich bei mir nicht. Das mit den "userreadings" habe ich nicht so ganz verstanden.
Deshalb habe ich jetzt in Ruhe nochmal "statistics" angesehen und Fehler gefunden.
Beim folgenden Reading mussten die Readings mit "," getrennt werden
deltaReadings energy_0,energy_1,energy_2
Das andere Reading habe ich etwas zusammengefasst
singularReadings myShellyEM3:energy_0:Delta:(Hour|Day|Month|Year)|myShellyEM3:energy_1:Delta:(Hour|Day|Month|Year)|myShellyEM3:energy_2:Delta:(Hour|Day|Month|Year)
Jetzt werden zumindest die verschiedenen Werte im Device myShellyEM3 angezeigt.
Wie Du bereit geschrieben hast, sind dies viele Werte, welche jetzt ins Log geschrieben werden. Ich weiß auch nicht, ob jetzt durch die zwei genannten Attribute die Werte doppelt erfasst werden oder nur einmal, weil es ja eigentlich die selben Werte wären.
Evlt. könnte ich auch das Attribut singularReadings komplett weg lassen, weil diese Werte ja auch im deltaReadings vorhanden sind?
Das nächste ist, dass ich ja den Gesamtverbrauch von allen drei Phasen zusammen pro Tag, Monat, Jahr haben möchte.
Wie kann ich diese zusammenrechnen und dann z.B. in einen SVG Plot als einen "Wert" anzeigen lassen? Oder auch als Zahl?
Habe ich das Problem bzgl. der "LAST-Werte" trotzdem auch?
Ich denke mein "Problem" mit der Darstellung ist hier wahrscheinlich etwas OffTopic, weil es nichts mit dem Modul 36_Shelly zu tun hat.
Habe hierzu einen anderern Thread eröffnet.
Zitat von: Ruggy am 16 August 2022, 16:06:31
@FSausF
Die Readings emeter_total usw. habe ich bei mir nicht. Das mit den "userreadings" habe ich nicht so ganz verstanden.
Deshalb habe ich jetzt in Ruhe nochmal "statistics" angesehen und Fehler gefunden.
Das nächste ist, dass ich ja den Gesamtverbrauch von allen drei Phasen zusammen pro Tag, Monat, Jahr haben möchte.
Wie kann ich diese zusammenrechnen und dann z.B. in einen SVG Plot als einen "Wert" anzeigen lassen? Oder auch als Zahl?
Habe ich das Problem bzgl. der "LAST-Werte" trotzdem auch?
Das emeter_total und die beiden anderen Genossen sind ja genau der Trick!
Es gibt das Attribut "userreadings". Da kannst Du eigene Readings definieren und berechnen.
Genau diese. Lies' Dir mal den Code durch, den ich oben gepostet habe. Wenn Du ihn verwenden willst, denk' dran, keine Leerzeichen oder Zeilenumbrüche.
Wenn Du die emeter_total-Werte als Userreadings gebaut hast, kannst Du darauf auch die Statistik loslassen.
Das Problem der LAST-Werte ist ein dem Statistics-Modul innewohnendes. Das kriegen wir dann.
Jetzt kriegst Du erst Mal die Readings, die Du willst.
Also: Den Inhalt Deines Userreadings-Attributs in eine Textdatei sichern, den von mir vorgeschlagenen in Erwägung ziehen.
Und alles wird gut. Nein. Besser!
Zitat von: FSausF am 15 August 2022, 18:21:39
Hallo in die Runde, ich hoffe, ich bin mit der Frage richtig im Support-Thread für Shelly:
Ich habe zahlreiche Shelly Plug S (model shellyplug) im Einsatz, und die scheinen soweit auch gut zu funktionieren.
(Zuvor hatte ich Fritz!DECT und Homemmatic am Start.)
Was ich vermisse, sind Nachrichten im Log.
Ich würde mir wünschen, dass im Log das Ein- und das Ausschalten geloggt werden kann.
Dazu habe ich mein Glück mit verschiedenen Werten des Attributs "verbose" versucht. (event-on-update-reading hat "status,power,energy,etc.)
Bei 0-4 passiert meiner Wahrnehmung nach im Log genau nichts.
Bei 5 oder 6 wird das Log sehr großzügig und periodisch geflutet.
1.) Gibt es etwas dazwischen?
2.) Wie erreiche ich das?
Danke vorab für Euer Hirnschmalz!
FrankSausF
Moin, Looidde,
hat da jemand eine Idee, mit wechlcher Extremität ich da gerade auf der Leitung stehe?
Danke!
@FSausF
Ich habe mich mal an user Readings gewagt und auch die Wiki und Comandref versucht zu verstehen. Leider hat es noch nicht klick gemacht, damit ich es verstehe.
Ich habe die beiden Attribute von gestern (singularReadings, deltaReadings) in myStatDevice gelöscht und folgendes userReadings im Device myShellyEM3 versucht auf meine Geräte und readings anzupassen.
Gesamtverbrauch.kWh:(energy_0:.*|energy_1:.*|energy_2:.*) {ReadingsNum("$name","energy_2",0)+ReadingsNum("$name","energy_1",0)+ReadingsNum("$name","energy_0",0)}
Jetzt wird ein Reading Gesamtverbrauch.kWh und ein Wert von 441756 angezeigt. Also energy_0+energy_1+energy_2 addiert.
Ist das soweit richtig?
Oder benötige ich auch die anderen userReadings wie in Deinem userReading?
Hi R
Zitat von: Ruggy am 17 August 2022, 16:36:53
@FSausF
Jetzt wird ein Reading Gesamtverbrauch.kWh und ein Wert von 441756 angezeigt. Also energy_0+energy_1+energy_2 addiert.
Ist das soweit richtig?
Oder benötige ich auch die anderen userReadings wie in Deinem userReading?
Glückwunsch zum Durchbruch!
Ob Du die weiteren brauchst, ist jetzt Deine Sache.
Wenn Du Photovoltaik am Start hast, könnte es theroretisch auch mal Einspeisung geben.
Dann wärest Du sicher auch an der Summe der Einspeisung beziehungsweise dem Netto interessiert...
Wobei das unter Umständen mit dem Zähler schwierig sein kann. Je nachdem, wie der saldiert oder auch nicht, kann es da wild werden.
Jetzt kannst Du erst Mal Statistik machen und loggen (Bau' Dir für Graphen am besten ein separates Filelog, in dem nur die Readings drin sind, die Du brauchst.).
Und dann kannst Du Dir die Frage der Tagesverschiebung anschauen.
Aber das ist dann eine Diskussion bei SVG oder Statistics.
Hoch die Tassen!
@Herrn Professor Henning: Ich habe einen Wunsch, einen weiteren relevanten Parameter in 36_Shelly.pm zu integrieren.
Modell: ShellyEM
Bedarf: das EM stellt 2 Energiewerte zur Verfügung, einen der in die Anlage geflossen ist (,energy') und ein weiterer, die die Anlage ins Netz eingespeist hat (,returned_energy'). Der zweite ist natürlich der besonders interessante und fehlt im Moment in der Implementierung. Ich sehe ihn aber im MQTT Log, er wird also geliefert.
Aus der API-DOC:
———————-
Shelly EM: MQTT
When configured for MQTT Shelly EM reports data on:
shellies/shellyem-<deviceid>/emeter/<i>/energy energy counter in Watt-minute
shellies/shellyem-<deviceid>/emeter/<i>/returned_energy energy returned to the grid in Watt-minute
———————-
VIELEN DANK, Andreas Daun.
ZitatWas ich vermisse, sind Nachrichten im Log.
Ich würde mir wünschen, dass im Log das Ein- und das Ausschalten geloggt werden kann.
Das allgemeine Logfile ist dafür gar nicht da - das sammelt im Wesentlichen Fehlermeldungen auf.
Einfach ein eigenes FileLog Device erzeugen, das kann auf beliebige Events reagieren. Und problemloserweise auch auf die Schaltvorgänge eines Shelly...
LG
pah
Zitatshellies/shellyem-<deviceid>/emeter/<i>/energy energy counter in Watt-minute
shellies/shellyem-<deviceid>/emeter/<i>/returned_energy energy returned to the grid in Watt-minute
Klingt plausibel. Ich sehe aber bei meinem gegenwärtigen Workload (Conference Chair DELFI Konferenz) keine Chance, das vor Anfang Oktober anzugehen. Geduld bitte.
LG
pah
Moin,
ich kann mich noch dran erinnern, daß hier einmal diskutiert wurde, daß die neue Generation Shellys (z.B. 1plus) zwar weiterhin ein Passwort zulassen, es aber keinen User mehr gibt. Da es im Modul mittlerweile einen Shellyplus1 gibt, ich zum Thema aber weder in der Commandref noch hier etwas gefunden habe, möchte ich mich einmal erkundigen, ob es da inzwischen eine andere Unterstützung für das PW ohne User im Modul gibt. Hintergrund ist einfach, daß ich alle "alten" Shellys via PW/User gesichert habe, und das auch beim neuen machen wollte ...
Gruß, Christoph
ich melde mich auch nochmal zu Wort, dass es immer nach dem Update bei mir kein "model" shellypro2 in der Auswahlliste gibt.
Siehe Screenshot
Das Modul zeigt auch einen Error
state: "Error"
Nach dem Update funktioniert meine Markise nicht mehr und ich muss wieder das alte Modul was ich vorher schon beschrieben habe zurück kopieren.
Was kann ich da noch machen gibt evtl. irgendwo in Fhem alte Codeschnipsel die ich löschen muss..? Ich frage deshalb weil ich schon wieder 2 Tage am suchen bin, aber nicht fündig werden.
Aktuelle Modulversion nach Fhem Update
version => 4.01
$Id: 36_Shelly.pm 26017 2022-05-02 07:04:23Z phenning $
Modulversion die bei mir funktioniert
Version 4.02d
$Id: 36_Shelly.pm 2022-04 - pahenning $
Zusatzfrage, wird der rollermode noch eingebaut.?
Aktuell - und oben irgendwor herunterladbar - ist 4.02f
Und da gibt es einen shellypro2.
Rollermode: Klar. Sobald ich Zeit habe. Noch 2 Wochen, dann ist meine DELFI-Konferenz vorbei.
LG
pah
Ich die Version 4.02c, 4.02d und 4.02e gefunden, aber keine "f" Version.
Ist jetzt kein Drama, da ja die 4.02d bei mir funktioniert.
Siehe hier
Vielen Dank werde ich ausprobieren.
Danke für das Modul, über MQTT kommen mir viel zu oft zu viele Daten ;)
Ich habe für mich noch folgende Zeilen im Modul ergänzt um die Gesamtleistung vom Shelly 3EM abzufragen, falls es jemand bauchen kann.
nach: my $metern = ($model =~ /shelly.?em/)?"emeters":"meters";
# add total_power
my $total_power = $jhash->{'total_power'};
readingsBulkUpdateIfChanged($hash,"total_power",$total_power);
Des weiteren wird beim Shelly 3EM kein SET im GUI angeboten, obwohl es z.B. für "set password" nützlich wäre, nix großes ist mir nur aufgefallen.
Allgemeine Info zur Genauigkeit des 3EM. Ich frage auch meinen Stromzähler ab und die Werte weichen bei mir maximal um 3 Watt ab.a
Hallo,
kann mit diesem Modul der Shelly 1PM Plus genutzt werden?
Hallo Christoph,
habe mit einem Sfelly1 auch das Problem mit
Shelly_status] invalid JSON data
und versuche vergeblich das aktuelle 2022 Modul 36_Shelly.pm zu down zu laden.
Bin schon etwas betagt und schwer sehbehindert und habe versucht das Modul von Github herunterzuladen -was mir nicht gelungen ist.
Wäre es Dir möglich mir das Modul auf meine email zu senden : hp.abele(@)t-online (ohne Klammer) ?
Gibt es da noch extra Hinweise bei der Installation ?
Würde mich über Deine Unterstützung sehr freuen.
LG Peter aus Calw
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM)
Danke für das Modul erstmal, funktioniert super mit meiner Shelly RGBW2.
Wäre es möglich, für die RGBW2 auch die transition (http://<shelly ip>/settings/light/0?transition=[0..5000]) und gain (http://<shelly ip>/color/0?gain=[0..100]) Befehle zu implementieren?
Das wären die einzigen Befehle, die ich bisher nur über das webinterface der Shelly senden kann und die ich in FHEM vermisse, um z.B. einfach zu dimmen oder eigene Lichteffekte in FHEM zu erstellen.
Wenn ich im Shelly Webinterface den gain runterdrehe, habe ich bisher noch keine Mögichkeit gefunden, das per FHEM wieder rückgängig zu machen.
Eine Möglichkeit, direkt in einem Befehl farbe, gain & transition zu setzen, wäre auch toll.
Über die REST API sieht der request dann z. B. so aus: http://<shelly ip>/color/0?red=0&green=0&blue=255&gain=100&transition=[0..5000] (wo transition dann als one-shot nur für diesen Befehl gesetzt wird)
Und noch ein kleiner bug, wenn ich versuche, z. B. "set shelly hsv 14,0.8,1" zu senden, bekomme ich
Undefined subroutine &Color::hsv2rgb called at ./FHEM/36_Shelly.pm line 903.
und FHEM schmiert ab.
ZitatWäre es möglich, für die RGBW2
ZitatEine Möglichkeit,...wäre auch toll.
Sicher. Aber ich bin kein Auftragsprogrammierer.
ZitatUnd noch ein kleiner bug
Sicher nicht. Fehlerhafte FHEM-Installation.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 17 September 2022, 20:19:56
Sicher. Aber ich bin kein Auftragsprogrammierer.
Das war auch nicht als Programmierauftrag gemeint, sondern eher als ein Programmiervorschlag, falls Lust & Zeit vorhanden sind. ;)
Zitat von: Prof. Dr. Peter Henning am 17 September 2022, 20:19:56
Sicher nicht.
use Color;würde helfen.
Hallo, kann ich den H&T oder die Fensterkotakte irgendwie einbinden?
Zitat von: Badflex am 18 September 2022, 14:31:01
Hallo, kann ich den H&T oder die Fensterkotakte irgendwie einbinden?
Denke nicht, siehe: https://wiki.fhem.de/wiki/Modul_Shelly
Wurde (soweit ich mich erinnere) auch hier schon mal gefragt und (mit nein) beantwortet.
EDIT: gut nicht hier, sondern wohl in einem früheren Shelly-Thread: https://forum.fhem.de/index.php/topic,93251.msg863364.html#msg863364
Per mqtt geht.
Gruß, Joachim
zu Antwort #62
Hallo liebe Entwickler,
ich habe auch gerade einen Shelly Uni erstanden, um den Wasserstand in meinem Regenwassertank zu messen. Soweit klappt:
- Einbindung Shelly ins Heimnetz
- Anschluss des Sensors
- Messung / Anzeige der Spannung in der Shelly-Oberfläche
- Einbindung Shelly in FHEM; Readings:
Readings
cloud disabled 2022-09-18 14:47:08
config adcs= [channel 0] 2022-09-18 16:34:36
energy 0 2022-09-18 16:32:52
firmware v1.12 2022-09-18 16:31:52
network connected to 192.168.0.79 2022-09-18 16:31:34
relay_0 off 2022-09-18 16:00:28
relay_1 off 2022-09-18 16:00:28
state OK 2022-09-18 16:31:52
Ich bekomme aber wie Matthes in #61 in FHEM keine Spannung angezeigt.
Gibt es dazu inzwischen ein Update des Moduls, das dies löst?
Ich möchte nicht selber in das Modul und versuchen, da selbst was anzupassen.
Schönen Gruß
Bernd
Danke für das Modul, ich verwende es für "normale" Shelly 1 und habe nun aber zur Steuerung meines Heizstabs drei Shelly Pro 1 im Einsatz. Anbindung klappt mit dem hier im Forum geposteten Modul problemlos, bis auf die neue Digest Passwort-Lösung der neuen Shellys. Gibt es dafür schon eine zeitliche Perspektive, wann das umgesetzt wird? Die Vorstellung, dass jeder in meinem WLAN mal so eben unauffällig 3kW in Bewegung bringen kann, behagt mir nicht so sehr ;)...
Zitat von: Peter aus Calw am 16 September 2022, 18:18:32
Hallo Christoph,
habe mit einem Sfelly1 auch das Problem mit
Shelly_status] invalid JSON data
und versuche vergeblich das aktuelle 2022 Modul 36_Shelly.pm zu down zu laden.
Bin schon etwas betagt und schwer sehbehindert und habe versucht das Modul von Github herunterzuladen -was mir nicht gelungen ist.
Wäre es Dir möglich mir das Modul auf meine email zu senden : hp.abele(@)t-online (ohne Klammer) ?
Gibt es da noch extra Hinweise bei der Installation ?
Würde mich über Deine Unterstützung sehr freuen.
LG Peter aus Calw
Hallo Peter,
hast Du es inzwischen herunter laden können aus dem Antwortlink von Gisbert?
Gruß, Christoph
Zitat von: freetz am 21 September 2022, 11:42:35
Danke für das Modul, ich verwende es für "normale" Shelly 1 und habe nun aber zur Steuerung meines Heizstabs drei Shelly Pro 1 im Einsatz. Anbindung klappt mit dem hier im Forum geposteten Modul problemlos, bis auf die neue Digest Passwort-Lösung der neuen Shellys. Gibt es dafür schon eine zeitliche Perspektive, wann das umgesetzt wird? Die Vorstellung, dass jeder in meinem WLAN mal so eben unauffällig 3kW in Bewegung bringen kann, behagt mir nicht so sehr ;)...
Mich würde auch interessieren, ob es Pläne gibt die
Passwort-Authentifinzierung für z.B. shellyplus1pm und shellyplus1 zu implementieren? Oder funktionierrt es vielleicht auch schon irgendiwe?
Guten Tag Community
Unterdessen habe ich praktisch alle 18 und weitere Seiten in anderen Foren durchgelesen jedoch immer noch keine Lösung zur Anbindung der Shelly Shelly2pro und Shelly1pro gefunden.
Könnte bitte jemand ein funktionierendes Template oder Konfiguration posten?
Ich wäre ausserordentlich dankbar.
Moin vic,
ich habe selber keinen Shelly-Pro, aber in der Modelauswahl sind diese auch enthalten (s. Screenshot; sind nur als ShellyPro1 usw. bezeichnet).
Also einfachach:{code}define MeinSHelly1pro Shelly <ip>
attr MeinShelly1pro model shellypro1
{/code}
Und natürlich alle weiteren notwendigen Attribute - damit sollte es dann gehen...
Gruß, Christoph
Danke für die Hilfe Christoph
Leider erhalte ich die modelle Shelly2pro und Shelly1pro wie in deinem Screenshot abgebildet nicht.
Wäre es möglich, dass du mir ein komplettes listing einer Shelly2Pro (und ev. Shelly1Pro) Konfiguration zur Verfügung stellst?
Beste Grüsse Claudio
Hm, ich vermute mal, Du hast eine ältere Version von 36_Shelly.pm im Einsatz? Meine Version ist von 04-2022 - allerdings die letzte hier im Thead angehängte Version (wobei meines Wissens nach auch die letzte "reguläre" Version die Unterstützung für pro's bereits hatte ...)
Mach doch einmal bitte ein Update und ein shutdown restart, danach sollte es funktionieren.
Gruß, Christoph
Danke für die Rückmeldung
Dies vermutete ich ebenfalls.
Meine Version scheint vom 02.05.2022 zu sein.
Grüsse Claudio
Hm, da scheint PAH in der offiziellen Version den Support für die pro's (noch) nicht mit eingebaut zu haben - wenn ich mir das Modul näher anschaue, so sind die Modelle Pro1 und Pro2 auch nur in dieser inoffiziellen Version enthalten... Wobei - die offizielle Version ist mit 4.01 von Anfang Mai gekennzeichnet, in der verlinkten Version steht 4.02f, ist aber von April ...
Diese Version kannst Du hier finden (https://forum.fhem.de/index.php/topic,118446.msg1233686.html#msg1233686) ...
Kopierst DU dann in Dein Modulverzeichnis, und nimmst vorsichtshalber vorerst das Modul aus den Updates heraus ...
Gruß, Christoph
Ich wollte eigentlich die offenen Baustellen in diesem Herbst alle schließen, aber dann kamen mir DAS VIRUS und ein paar andere Dinge dazwischen. Geduld, bitte.
LG
pah
Danke für deine Hilfe Christoph
Leider hat nichts funktioniert. Habe festgestellt, dass ca. 4 verschiedene Versionen (gemäss Zeilenanzahl) 2022-04 im Forum vorhanden sind und alle ausprobiert.
Ich komme zu keinem Ergebnis. :-[
Dann werde ich wohl warten.
@pah: ich hoffe du hattest keinen schweren Verlauf. Mich hat es das erste Mal vor 5 Wochen erwischt und ich kaue immer noch dran rum.
Freue mich mal was von euch zu hören.
Grüsse aus der Schweiz
Claudio
Hallo vic,
ich hänge Dir die v4.02f noch einmal mit an, die ich laufen habe...
Gruß, Christoph
PS:Fhem-Neustart nicht vergessen nach Einkopieren ...
Aber bleibt bei dieser Version nicht auch das Problem mit der geänderten Passwort-Abfrage bestehen? Die Shelly Pro 1 und 2 laufen ja nicht mehr mit http Auth. Ich kann damit zwar die Shellys steuern, aber nicht, wenn ich ein Passwort vergebe.
Irgendwie erschließ sich mir der Sinn nicht, in einem geschützten Netzwerk Passwörter bei Shelly-Devices zu haben...
LG
pah
Wenn man keine Kinder/Teenager im Haushalt hat, mag sich der Sinn vielleicht nicht erschließen, aber ich möchte nicht, dass mein Nachwuchs aus Forscherdrang mal mit den Heizstäben des Pufferspeichers oder dem Hausentlüftungssystem experimentiert. Ja, kann man alles irgendwie anders absichern, über VLAN oder was auch immer, aber wenn es von Haus aus eine sehr einfache Möglichkeit gibt, da einen Riegel vorzuschieben (und nein, zum Netzwerksniffen reichen die Kenntnisse nicht aus), dann fände ich das schön, wenn das von dem dazugehörigen Modul auch unterstützt würde.
Unterdessen wurden Updates des Moduls [36_Shelly.pm] und [mqtt2.template] zur Verfügung gestellt welche ich hoffnungsvoll installiert habe.
Sie scheinen jedoch leider die Problematik der ShellyPro-Versionen nicht zu betreffen. :(
Ist dies korrekt oder habe ich etwas übersehen?
Hallo zusammen,
ich habe im Log immer die Meldung, dass ich für meine Shelly 2.5 noch das maxtime Attribut setzen soll. Laut Doku ist das ein float Wert, aber es ist keine Einheit angegeben. Auch im Forum habe ich nichts gefunden.
Stellt man die Zeit in ms, s oder m ein?
VG
Torsten
Hat jemand von euch schon mal einen Shelly i4 in fhem eingebunden?
Hallo!
Wen es interessiert:
um dem shellypro1pm die Messwerte zu entlocken, habe ich im 36_Shelly.pm in der Version 4.02f die Zeile 1413 von
if( ($model =~ /shellyplus\d(pm)?/) || ($model eq "shellypro\d(pm)?") ){
auf
if( ($model =~ /shellyplus\d(pm)?/) || ($model =~ /shellypro\d(pm)?/) ){
geändert.
Ob das ev. die Funktion anderer Shelly Versionen beeinträchtigt kann ich nicht beurteilen (vermute aber "nein").
Off topic:
Verwende den shellypro1pm um die eingespeiste Leistung meines Balkonkraftwerkes zu messen.
Die aktuelle Leistung wird auch Vorzeichen-richtig angezeigt/ausgegeben, also positive Watt Zahl, wenn keine Sonne scheint (standby Verbrauch des Wechselrichters) und negative Watt Zahl bei Netzeinspeisung. Leider wird der Strom immer nur positiv angezeigt, egal ob verbraucht wird oder produziert und noch schlimmer: der Energiezähler summiert sowohl Verbrauch als auch Erzeugung auf (anstatt sie zu subtrahieren).
FW Version ist 0.11.4
Vielleicht hat jemand eine Idee dazu?
LG
Rainer
@Rainer: Soweit ich vermute kannst du die Shellies der Pro-Serie in FHEM einbinden und damit schalten.
Ich versuche dies seit einigen Monaten leider erfolglos (ShellyPro1 und ShellyPro2). Wäre es möglich, dass du mir die komplette Setlist zur Verfügung stellst. Ich wäre dir ausserordentlich dankbar.
Claudio
Hallo zusammen ich hab jetzt schon einiges hier gelesen und auch gesucht.
Könnte mir kurz jemand sagen ob die Heizungsmodule schon unterstützt werden oder ob das noch geplant ist? Ich müsste für ein Projekt ne Hardwareentscheidung treffen müssen und würd eigentlich schon gern Shelly's nehmen.
Grüße
Alex
Zitat von: DJAlex am 24 November 2022, 08:50:32
Hallo zusammen ich hab jetzt schon einiges hier gelesen und auch gesucht.
Könnte mir kurz jemand sagen ob die Heizungsmodule schon unterstützt werden oder ob das noch geplant ist? Ich müsste für ein Projekt ne Hardwareentscheidung treffen müssen und würd eigentlich schon gern Shelly's nehmen.
Grüße
Alex
Einbindung per mqtt geht bzw. ist in Arbeit: https://forum.fhem.de/index.php/topic,129394.msg1236969.html#msg1236969
Ob/wann das im Shelly Modul kommt (oder schon geht): https://wiki.fhem.de/wiki/Modul_Shelly
Gruß, Joachim
Zitat von: vic am 23 November 2022, 09:18:46
@Rainer: Soweit ich vermute kannst du die Shellies der Pro-Serie in FHEM einbinden und damit schalten.
Ich versuche dies seit einigen Monaten leider erfolglos (ShellyPro1 und ShellyPro2). Wäre es möglich, dass du mir die komplette Setlist zur Verfügung stellst. Ich wäre dir ausserordentlich dankbar.
Claudio
@vic bitte sehr:
defmod PV_WR Shelly 192.168.1.100
attr PV_WR defchannel WR
attr PV_WR devStateIcon off.*:sani_solar@gray on.*:sani_solar@orange
attr PV_WR icon sani_solar
attr PV_WR model shellypro1pm
attr PV_WR room PV,Shelly
attr PV_WR stateFormat <p algin="justify">\
relay<br>\
<br>\
state<br>\
Spannung:......voltage V ...Strom:.............current A<br>\
Leistung:..........power W ...Energie:..energy Wh<br>\
Leistungsfaktor:..pfactor ...Temperatur:......inttemp°C\
</p>
@Rainer
Vielen Dank!
Ich werde deine Angaben dieses Wochenende ausprobieren.
Liebe Grüsse
Claudio
Habe ein Frage zum Shelly1 mit addon für Schalter oder Temperatur Sensoren.
Kann ich Werte vom addon mit dem Shelly-Modul auslesen oder geht das nur über MQTT?
Geht mit dem Modul, mache ich auch.
LG
pah
Prof. könntest du mir auch verraten wie.
Habe schon vieles getestet ,aber habe es leider nicht heraus finden können. Würde gerne meine Garagentorstellung damit abfragen mit dem Addon Eingang.
defmod Garagenoeffner Shelly 192.168.178.27
attr Garagenoeffner group Garagentor
attr Garagenoeffner interval 10
attr Garagenoeffner mode roller
attr Garagenoeffner model shelly1
attr Garagenoeffner room System->Test
Liebe Nutzer,
ich suche einen Nachfolger als Maintainer des Shelly-Moduls 36_Shelly.pm.
Grund: Ich habe alle Shellys in Betrieb, die ich brauche. Die ganzen neueren Modelle sind im Modul immerhin rudimentär implementiert, da ist aber noch Einiges zu tun.
Aber: Ich kann nicht ohne Ende Hardware kaufen, die ich dann nicht benutze. Und das Testen mit hilfsbereiten anderen Usern kostet viel Zeit, die ich lieber in innovative neue Projekte investiere.
Nun könnte man argumentieren, dass ja alle Shellys mit MQTT laufen und somit dieses einfache Modul überflüssig ist. Das sehe ich anders: Gerade Anfänger tun sich mit der Komplexität von MQTT schwer. Die Verfügbarkeit der preiswerten Shellys hat viele Menschen erst zur Hausautomatisierung hingezogen, die jetzt überzeugte FHEM-Nutzer geworden sind.
Freiwillige vor !
LG
pah
<offtopic>
Ist geplant, dass FHEM irgendwann auf github/gitlab geht?
Hintergrund: ich bin jemand, der FHEM seit vielen Jahren benutzt, zwei - drei kleine(!) Patches beigesteuert hat und auch bei 36_Shelly.pm gerne ein paar Kleinigkeiten beisteuern würde/könnte (z.B. Shelly 2 Plus Unterstützung). Ich glaube, dass FHEM viele Verbesserungen entgehen, weil das aktuelle, "klassische" Entwicklungsmodell das Einreichen von Patches unnötig arbeitsaufwändig macht. Der Workflow auf github bzw. gitlab dafür ist deutlich komfortabler und schneller. Ich hätte in der Vergangenheit mehr beigetragen, wenn das Entwicklungsmodell ein anderes wäre und vermute, dass es nicht nur mir so geht.
</offtopic>
Zitat von: Prof. Dr. Peter Henning am 02 Dezember 2022, 16:09:53
Die ganzen neueren Modelle sind im Modul immerhin rudimentär implementiert, da ist aber noch Einiges zu tun.
Ich werde in den nächsten Tagen an dieser Stelle eine neue Version veröffentlichen, welche den Shelly Plus2PM weitergehend berücksichtigt.
Vielen Dank für die Hilfe
Zitat von: gamauf am 24 November 2022, 14:40:04
@vic bitte sehr:
defmod PV_WR Shelly 192.168.10.100
attr PV_WR defchannel WR
attr PV_WR devStateIcon off.*:sani_solar@gray on.*:sani_solar@orange
attr PV_WR icon sani_solar
attr PV_WR model shellypro1pm
attr PV_WR room PV,Shelly
attr PV_WR stateFormat <p algin="justify">\
relay<br>\
<br>\
state<br>\
Spannung:......voltage V ...Strom:.............current A<br>\
Leistung:..........power W ...Energie:..energy Wh<br>\
Leistungsfaktor:..pfactor ...Temperatur:......inttemp°C\
</p>
Ich habe versucht den Code zu übernehmen
define Switch_00001 Shelly 192.168.1.100
attr Switch_00001 devStateIcon off.*:sani_solar@gray on.*:sani_solar@orange
attr Switch_00001 room MQTT2_DEVICE
attr Switch_00001 stateFormat <p algin="justify">\
relay<br>\
<br>\
state<br>\
Spannung:......voltage V ...Strom:.............current A<br>\
Leistung:..........power W ...Energie:..energy Wh<br>\
Leistungsfaktor:..pfactor ...Temperatur:......inttemp°C\
</p>
Leider scheint dies mit dem ShellyPro1 (ohne pm) nicht zu funktionieren.
Der Shelly lässt sich mit on und off schalten. Die Rückmeldung steht jedoch immer auf Error.
Bin ich denn der einzige, der mit den Pro-Shellies Probleme hat?
Danke für eure Hilfe
Hallo vic!
- in deinem List sehe ich das Attribut "model" nicht
- hast du, wie von mir hier erwähnt https://forum.fhem.de/index.php/topic,118446.msg1247122.html#msg1247122 (https://forum.fhem.de/index.php/topic,118446.msg1247122.html#msg1247122), die Datei 36_Shelly.pm angepasst?
Schönen Sonntag
Rainer
attr Switch_00001 model shellypro1
PS.: bitte poste die vollständige Ausgabe von
list Switch_00001
sonst muss man zu viele Annahmen treffen um dir zu helfen!
Vielen Dank gamauf
Anbei das Listing.
Internals:
DEF 192.168.11.157
DURATION 0
FUUID 639ef6f2-f33f-c333-c80d-e3eb6acf71122189f
INTERVAL 60
NAME Switch_00001
NR 2915
STATE OK
TCPIP 192.168.11.157
TYPE Shelly
eventCount 483
READINGS:
2022-12-18 14:59:36 inttemp 23.8
2022-12-18 12:22:49 network <html>connected to <a href="http://192.168.11.157">192.168.11.157</a></html>
2022-12-18 14:59:35 relay_0 off
2022-12-18 12:32:53 relay_1 off
2022-12-18 14:59:36 state OK
Attributes:
defchannel 0
icon sani_solar
model shellypro2
room MQTT2_DEVICE
Unterdessen habe ich ein paar Anpassungen vorgenommen. Der Shelly ist ein ShellyPro 2. (Nicht 1)
Nun wäre es schön, wenn ich mit dem Icon schalten könnte. Es erscheint OK. Mit klick auf OK kann ich ein- jedoch nicht mehr ausschalten.
Danke für eure Hilfe. Früher war es mit den vorbereiteten Templates viel einfacher...
ZitatFrüher war es mit den vorbereiteten Templates viel einfacher
Aber nicht mit diesem Modul.
Und Danke an Starktrombastler für das Weiterarbeiten.
LG
pah
Ich habe mir jetzt erst einmal ein Setup aus einer alten Logo! und ein paar Glühbirnen aufgebaut, um einen Rolloantrieb zu simulieren. Ein echter Rollo stirbt nämlich bei der vielen Testerei ganz schnell den Hitzetod.
Für alle Interessierten heißt das: Bitte noch etwas Geduld :)
Hallo zusammen,
ich wollte mal nachfragen, ob es zu Shelly TRV in der Zwischenzeit war neues gibt.
Meine Fhem Shelly hat aktuell den Stand
##########################################################
#
# Shelly.pm
#
# FHEM module to communicate with Shelly switch/roller actor devices
# Prof. Dr. Peter A. Henning, 2022
#
# $Id: 36_Shelly.pm 26017 2022-05-02 07:04:23Z phenning $
#
##########################################################
Ich würde mich über jeder Antwort freuen und schon jetzt vielen Dank
Matze
Zitat von: Lichti6 am 22 Dezember 2022, 16:35:44
Hallo zusammen,
ich wollte mal nachfragen, ob es zu Shelly TRV in der Zwischenzeit war neues gibt.
Meine Fhem Shelly hat aktuell den Stand
##########################################################
#
# Shelly.pm
#
# FHEM module to communicate with Shelly switch/roller actor devices
# Prof. Dr. Peter A. Henning, 2022
#
# $Id: 36_Shelly.pm 26017 2022-05-02 07:04:23Z phenning $
#
##########################################################
Ich würde mich über jeder Antwort freuen und schon jetzt vielen Dank
Matze
Mit dem Shelly-Modul mWn (noch) nicht, siehe: https://forum.fhem.de/index.php/topic,118446.msg1247500.html#msg1247500
(ist ja gar nicht sooo weit weg von hier ;) )
Und fraglich, ob (wann) das kommt: https://forum.fhem.de/index.php/topic,118446.msg1248978.html#msg1248978
Gruß, Joachim
Hallo,
Klasse, dass es mit dem ShellyPlus2PM weitergeht.
Zu
Zitat
ich wollte mal nachfragen, ob es zu Shelly TRV in der Zwischenzeit war neues gibt.
und um das von Prof. Dr. Henning genannte Problem
Zitat
Ich kann nicht ohne Ende Hardware kaufen, die ich dann nicht benutze.
zu entschärfen, wäre ich bereit einen Shelly TRV zu kaufen und diesen ein paar Monate Starkstrombastler zur Verfügung zu stellen.
@ Starkstrombastler:
Wenn das für Dich in Ordnung ist, brauchst Du mir nur Deine Adresse am besten über das Forum-Mitteilungssystem zu senden.
Xaneu
Hi,
Zitat von: freetz am 31 Oktober 2022, 13:16:40
Aber bleibt bei dieser Version nicht auch das Problem mit der geänderten Passwort-Abfrage bestehen? Die Shelly Pro 1 und 2 laufen ja nicht mehr mit http Auth. Ich kann damit zwar die Shellys steuern, aber nicht, wenn ich ein Passwort vergebe.
das Problem ist in HttpUtils.pm zu suchen. Beigefügter Patch 'rüstet' die SHA-256 Authentifizierung nach. Damit ein Shelly Plus1 damit funktioniert, muss das
shellyuser Attribut auf admin gesetzt werden (könnte man im 36_Shelly.pm automagisch erledigen...).
Grüße
Gerhard
Guten Abend,
hat jemand einen Shelly Pro 3 und dafür die richtige / passende Konfiguration gefunden/parat? Dann würde ich mich über einen Hinweis freuen.
Als Modell kann man Shelly Pro 3 nicht auswählen. Die Auswahl anderer Modelle hat mich bislang nicht zum Ziel geführt.
Internals:
CFGFN
DEF 192.168.7.41
FUUID 63b0441d-f33f-f7fe-f06c-757bf9caf7930630
INTERVAL 60
NAME GAR_Shelly
NR 15108
STATE Error
TCPIP 192.168.7.41
TYPE Shelly
eventCount 8
Helper:
DBLOG:
network:
Eventlog:
TIME 1672496157.05404
VALUE <html>connected to <a href="http://192.168.7.41">192.168.7.41</a></html>
state:
Eventlog:
TIME 1672498121.14058
VALUE Error
READINGS:
2022-12-31 15:15:57 network <html>connected to <a href="http://192.168.7.41">192.168.7.41</a></html>
2022-12-31 15:48:41 state Error
hmccu:
Attributes:
model generic
Das Log sagt
2022.12.31 15:48:20.477 1: [Shelly_configure] invalid JSON data for device GAR_Shelly
2022.12.31 15:48:41.140 1: [Shelly_proc1G] invalid JSON data for device GAR_Shelly
Die Firmware des Shelly ist die 0.12.0
Edit:
Erledigt. Hab den Shelly Pro 3 stattdessen mittels MQTT eingebunden.
Add-On zum Shelly 3EM
Modul 36_ShellyMonitor
gvzdus hat seinem Modul (ergänzt das Modul 36_Shelly hier) ein Update verpasst. Jetzt werden die Werte für "total" korrekt angezeigt und zusätzlich auch die "total_returned" ausgeggeben.
https://forum.fhem.de/index.php/topic,117805.msg1254106.html#msg1254106 (https://forum.fhem.de/index.php/topic,117805.msg1254106.html#msg1254106)
Zum 36_Shelly
Auf Basis dieses Beitrags https://forum.fhem.de/index.php/topic,118446.msg1233953.html#msg1233953 (https://forum.fhem.de/index.php/topic,118446.msg1233953.html#msg1233953)
#253 hier im Thread habe ich mal mit meinen Nichtprogrammierkünsten (echt ohne Gewähr ::) ich habe nur den 3EM und einen Plug-S) einen "Patch" auf die letzte Zwischenversion
vom 36_Shelly (4.02f https://forum.fhem.de/index.php/topic,118446.msg1233686.html#msg1233686 (https://forum.fhem.de/index.php/topic,118446.msg1233686.html#msg1233686)) hier aus dem Thread gemacht.
Damit stellt das Modul auch ohne den ShellyMonitor die Werte "total-Returned" und "current" für die drei Phasen zur Verfügung sowie das Reading für die Summenleistung "total_power" (siehe http://<IP-3EM>/status).
ab Zeile 1112
my ($subs,$ison,$overpower,$rpower,$rstate,$power,$energy,$rstopreason,$rcurrpos,$position,$rlastdir,$pct,$pctnormal);
my ($total_power,$energy_returned,$current); # Ralf Variablen fuer 3 weitere Readings des Shelly 3EM
readingsBeginUpdate($hash);
readingsBulkUpdateIfChanged($hash,"network","<html>connected to <a href=\"http://".$hash->{TCPIP}."\">".$hash->{TCPIP}."</a></html>",1);
#-- for all models set internal temperature reading
if ($jhash->{'temperature'}) {
readingsBulkUpdateIfChanged($hash,"inttemp",$jhash->{'temperature'});
}
#############################################################################################################################
#-- 1st generation: we have a shelly1, shelly1pm, shellypro4, shelly2, shelly25, shellyplug or shellyem switch type device
if( ($model =~ /shelly1.*/) || ($model eq "shellyuni") || ($model eq "shellyplug") || ($model =~ /shelly(pro)?4/) || ($model =~ /shelly\d?em/) || (($model =~ /shelly2(\.5)?/) && ($mode eq "relay")) ){
for( my $i=0;$i<$channels;$i++){
$subs = (($channels == 1) ? "" : "_".$i);
$ison = $jhash->{'relays'}[$i]{'ison'};
$ison =~ s/0|(false)/off/;
$ison =~ s/1|(true)/on/;
$overpower = $jhash->{'relays'}[$i]{'overpower'};
readingsBulkUpdateIfChanged($hash,"relay".$subs,$ison);
readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower)
if(defined($overpower));
if($model =~ /shelly(1|(plug)).*/){
readingsBulkUpdateIfChanged($hash,"state",$ison)
}else{
readingsBulkUpdateIfChanged($hash,"state","OK");
}
}
if ($model eq "shellyuni") {
my $voltage = $jhash->{'adcs'}[0]{'voltage'};
readingsBulkUpdateIfChanged($hash,"voltage",$voltage);
}
my $metern = ($model =~ /shelly.?em/)?"emeters":"meters";
# 2 Zeilen Addon für 3EM Einzelparameter Gesamtleitung Summe der drei Phasen # Ralf
$total_power = $jhash->{'total_power'}; # Ralf
readingsBulkUpdateIfChanged($hash,"total_power",$total_power); # Ralf
for( my $i=0;$i<$meters;$i++){
$subs = ($meters == 1) ? "" : "_".$i;
$power = $jhash->{$metern}[$i]{'power'};
$energy = int($jhash->{$metern}[$i]{'total'}/6)/10;
# 1 Zeile Addon für 3EM 3 Werte Einspeiserichtung von L1,2,3 # Ralf
$energy_returned = int($jhash->{$metern}[$i]{'total_returned'}/6)/10; # Ralf
readingsBulkUpdateIfChanged($hash,"power".$subs,$power);
if ($model =~ /shelly.?em/) {
my $voltage = $jhash->{$metern}[$i]{'voltage'};
readingsBulkUpdateIfChanged($hash,'voltage'.$subs,$voltage);
# 2 Zeilen Addon für 3EM 3 Werte Strom L1,2,3 # Ralf
$current = $jhash->{$metern}[$i]{'current'}; # Ralf
readingsBulkUpdateIfChanged($hash,'current'.$subs,$current); # Ralf
# my $reactivePower = $jhash->{$metern}[$i]{'reactive'}; # Ralf auskommentiert, welcher Shelly hat reactve => kann ein Fehler sein
#my $apparentPower = sqrt( ($power * $power) + ($reactivePower * $reactivePower) );
#my $powerFactor = ($apparentPower != 0)?(int($power / $apparentPower * 100) / 100):"0";
#readingsBulkUpdateIfChanged($hash,'powerFactor'.$subs,$powerFactor);
$energy = $jhash->{$metern}[$i]{'total'};
# 1 Zeile Addon für 3EM 3 Werte Einspeiserichtung L1,2,3 # Ralf nochmal wie in Zeile 1153 u. 1154 -> ist hier nach dem if shelly.?em
$energy_returned = $jhash->{$metern}[$i]{'total_returned'}; # Ralf
}else{
$energy = int($jhash->{$metern}[$i]{'total'}/6)/10;
}
readingsBulkUpdateIfChanged($hash,"energy".$subs,$energy);
# 1 Zeile Addon für 3EM 3 Werte Einspeiserichtung L1,2,3 # Ralf nochmal wie in Zeile 1153 u. 1154 -> ist hier nach dem else
readingsBulkUpdateIfChanged($hash,"energy_returned".$subs,$energy_returned); # Ralf
}
Wer es brauchen kann...
Gruß Ralf
Edit wegen Variablen Namen, doppelte Readings
Damit die Ergänzung zum 36_ShellyMonitor passt muss die Variable mit "$energyReturned" bezeichnet werden (nicht $energy_returned).
Hmmmm...
So ganz nebenwirkungsfrei ist die Geschichte doch nicht.
Mein Shelly Plug-S erhält damit auch das Reading energyReturned. Den Wert (total-returned) stellt er natürlich in der Statusabfrage nicht zur Verfügung.
Zu einfach gedacht - aber für mich funktioniert es.
Wenn es mit dem Modul weitergehen sollte, wäre eine Ergänzung für den 3EM toll :)
Ich bekomme im Log laufend Perl Warnungen bei diesem Modul.
Zitat2023.01.08 11:37:44.040 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 5003.
2023.01.08 11:37:44.041 1: stacktrace:
2023.01.08 11:37:44.041 1: main::__ANON__ called by fhem.pl (5003)
2023.01.08 11:37:44.041 1: main::readingsBulkUpdateIfChanged called by ./FHEM/36_Shelly.pm (1314)
2023.01.08 11:37:44.041 1: main::Shelly_proc1G called by ./FHEM/36_Shelly.pm (1058)
2023.01.08 11:37:44.042 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (1045)
2023.01.08 11:37:44.042 1: main::__ANON__ called by FHEM/HttpUtils.pm (729)
2023.01.08 11:37:44.042 1: main::__ANON__ called by fhem.pl (779)
Kann ich das genauer nachsehen, welches Shelly Gerät dies verursacht?
Da ich ich ein paar definiert habe, ist es schwer.
Diese Meldung habe ich eigentlich per Zufall entdeckt, als ich stacktrace auf 1 gesetzt habe.
Ansonsten war im Log nur einmal einige Zeilen:
Zitat2023.01.07 17:00:00.006 1: PERL WARNING: Argument "???" isn't numeric in numeric le (<=) at (eval 45715863) line 1.
2023.01.07 17:05:00.004 1: PERL WARNING: Argument "???" isn't numeric in numeric le (<=) at (eval 45723768) line 1.
Vielleicht hilft bei der Analyse der Loglevel 4 oder 5 im Shelly Modul....
Gruß Ralf
Hallo,
ich habe ein paar Shelly Geräte im Einsatz, u.a. ShellyPlug, Shelly3em, Shelly2.5. Diese Shelly Geräte haben alle ein oder mehrere Reading "energy...". Dort wird der bisherige Verbrauch in Wh gespeichert.
Jetzt habe ich ein ShellyPlus1PM installiert, den Typ kann ich auch im ShellyModul auswählen, aber es gibt kein "energy" Reading. Stattdessen liefert der Adapter ein "Current" Reading, also die Stromstärke in Ampere.
Hier ein Listing vom ShellyPlus1PM:
Internals:
DEF 10.10.0.110
DURATION 0
FUUID 63b6fd76-f33f-2d4d-8ae5-b221b39e654f3a33
INTERVAL 60
NAME hk_Speicherladepumpe
NR 792
STATE on
TCPIP 10.10.0.110
TYPE Shelly
eventCount 25
READINGS:
2023-01-05 17:43:36 cloud disabled
2023-01-12 10:52:25 current 0.047
2023-01-11 11:56:27 firmware v1.12.2
2023-01-12 10:52:25 inttemp 58.8
2023-01-12 10:39:52 network <html>connected to <a href="http://10.10.0.110">10.10.0.110</a></html>
2023-01-12 10:51:22 overpower 0
2023-01-12 10:52:25 power 5.7
2023-01-12 10:51:22 relay on
2023-01-12 10:52:25 state OK
2023-01-12 10:52:25 voltage 232.4
Attributes:
devStateIcon on:sani_pump@red:off off:sani_pump@blue:on
group Pumpen
model shellyplus1pm
room Heizungskeller,Shelly
shellyuser admin
stateFormat relay
userReadings energyTotal:energy.* monotonic { ReadingsVal($name,"energy",0)/1000 }
Das userReading am Ende habe ich hinzugefügt. Ist bei mir als Standard für Shelly Energiewerte. FHEM update all und Restart wurde vorher durchgeführt, Stand heute.
Hat jemand eine Idee wie ich an den "energy" Wert komme, bzw. wie ich den Langzeitverbrauch aufzeichnen kann?
Grüße
Feller
Hallo
Der ShellyPlus1PM ist ja 2. Generation (hab ich nicht). Liefert der denn Energy überhaupt?
Kennst Du die http API. Da kann man mal über den Browser in die Daten gucken.
https://shelly-api-docs.shelly.cloud/gen2/ (https://shelly-api-docs.shelly.cloud/gen2/)
Z.B. mit http://<IP>/rpc/EM.GetStatus?id=0 kommt ein JSON zurück. Schau mal rein.
Gruß
Edit:
Hier ist der EM (EnergyMeter Teil)
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EM/ (https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EM/)
Scroll mal etwas nach unten zum Status. Mir scheint, dass da nur Strom, Spannung und Power zur Verfügung steht.
Ich habe nen 3EM. Der speichert auch Daten an die man per HTTP drankommt.
<IP>/emeter/<id>/em_data.csv id = 0 | 1 | 2 | 3
Lt. Beschreibung kann der PLus1PM: Strommessung mit Datenspeicherung
In der API-Beschreibung steht für EMData (https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EMData (https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EMData)) in der Mitte etwas davon wie man zumindest mal schauen kann ob es Daten gibt.
CSV file download
Alternatively to the RPC method GetData, the same data can be downloaded in CSV file by calling HTTP url:
http://<device ip>/emdata/<id>/data.csv
Hallo
Ich habe einen ShellyPlus1PM.
Soeben habe ich
Zitat von: RalfRog am 12 Januar 2023, 13:02:10
Z.B. mit http://<IP>/rpc/EM.GetStatus?id=0 kommt ein JSON zurück. Schau mal rein.
ausprobiert. Dabei erhalte ich folgenden Antwort:
code 404
message "No handler for EM.GetStatus"Gruss birdy
Tja... auf die Schnelle in der Gen2DeviceAPI bei Shelly gelesen.
War nur ne Idee, da man die Gen1 Geräte per HTTP-Abfrage relativ leicht darauf checken kann was sie so liefern und ob energy dabei ist.
Gruß Ralf
Ggemäss
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EM#methods (https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EM#methods)
solle http://192.168.33.1/rpc/EM.GetStatus?id=0 funktionieren.
Tut es aber nicht, zumindest nicht bei mir.
Aber http://<ip>/rpc/Shelly.GetStatus funktioneirt und liefert aengergy.total
ble {}
cloud
connected true
input:0
id 0
state false
mqtt
connected false
switch:0
id 0
source "loopback"
output true
apower 8.5
voltage 223.3
current 0.148
aenergy
total 12624.232
by_minute
0 40.969
1 138.33
2 143.149
minute_ts 1673784736
temperature
tC 43.9
tF 111
sys
mac "84CCA87733D0"
restart_required false
time "13:12"
unixtime 1673784738
uptime 3282502
ram_size 234484
ram_free 155620
fs_size 458752
fs_free 106496
cfg_rev 15
kvs_rev 0
schedule_rev 15
webhook_rev 0
available_updates
beta
version "0.13.0-beta1"
wifi
sta_ip "10.xx.xx.xx"
status "got ip"
ssid "xxxxxxxxxx"
rssi -69
ws
connected false
Als Idee...
Dann besteht für Feller ja die Möglichkeit - wenn das Modul die Daten nicht in ein Reading packt bzw. MQTT als Ausweg nicht in Frage kommt - z.B. über HTTPMOD den Wert auszulesen.
Für mich lese ich daraus, dass man sich bei Gen2 Geräten vorab intensiv damit beschäftigen sollte was und wie die Dinger Daten liefern.
Gruß Ralf
Inzwischen denke ich, dass ShellyPlus1PM eben nur ein PM und kein EM Device ist,
und die EM.xxx Befehle somit gar nicht zur Verfügung stehen.
Welche Methoden unterstützt werden sieht man hier.
http://<ip>/rpc/Shelly.ListMethods
Gruss birdy
Vermutlich hast du da völlig recht ;)
Wenn die Geräte die Energywerte aber intern ausrechnen und aufsummieren spricht ja nichts dagegen es im Modul auszulesen und zu verwenden.
Macht das Modul beim ShellyPlug ja auch (nutze ich für mein Balkonkraftwerk).
Beim 3EM hab ich mir z. B. die fehlenden Werte current und total_power reingepatcht.
Es ist halt schwer zu entwickeln wenn die Geräte nicht zur Verfügung stehen.
Zitat von: RalfRog am 15 Januar 2023, 18:02:51
Es ist halt schwer zu entwickeln wenn die Geräte nicht zur Verfügung stehen.
Klar doch, verstehe ich. Melde Dich falls ich Dich irgendwie unterstützen kann.
Ich verwende für mein Balkonkraftwerk einen ShellyPlus1PM, momentan noch. Und am Hauptanschluss ein 3EM. Leider kann der ShellyPlus1PM nicht zwischen Stromrichtung und der Wirk- / Scheinleistung unterscheiden. So ,,produziert" mein Balkonkraftwerk in der Nach durchgehen 3W :)
Darum werde ich den ShellyPlus1PM in Kürze durch ein Shelly EM ersetzen, der liegt schon bereit und wartet nur noch auf die Montage.
Gruss, birdy
Meine Anmerkung galt den Maintainern mit so einem Zoo zurecht zu kommenn ::)
Zur Zeit laufen der PlugS und der 3EM wie gewünscht (mit kleinem Eingriff ins Modul). Danke für das Angebot :)
Da hab ich mit meinem EVT300 (Glück?) nachts keine Probleme. Der PlugS zeigt Power 0. Es kommt schon mal morgens beim Start zu kleinen Spitzen....
Das wird jetzt aber wohl zu sehr OT.
Gruß Ralf
Hallo,
zunächst vielen Dank an @RalfRog und @birdy für die Infos. Ich habe heute den "http://<ip>/rpc/Shelly.GetStatus" mit meiner IP Adresse ausgeführt. Als Antwort kommt HTTP Error 401 - Die Website funktioniert nicht. Ich hatte noch Firmware 0.12.0 auf dem Shelly Plus1PM und habe dann die Firmware 0.13.0-beta1 installiert, da die auch im @birdy's Listing aufgeführt ist. Das Ergebnis ist aber das gleiche - HTTP Error 401.
Muss ich sonst noch etwas in der Konfiguration des Shelly einstellen, damit der GetStatus funktioniert?
Vielen Dank für eure Hilfe!
Feller
Habe leider keine Gen2.
Lt. https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Shelly#http-endpoint-shelly (https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Shelly#http-endpoint-shelly) müsste mit "http://<ip>/shelly" der Shelly Grundlegendes über sich verraten.
Zitat
HTTP Endpoint: /shelly
This resource is equivalent to invoking Shelly.GetDeviceInfo. The aim of this request is to identify a device. As the generation (gen) of the device determines the channels and methods/endpoints available, this information is useful for further integrations of Shelly devices in other systems.
Ist aber alles nur Theorie. Zumindest bei Birdy gibt der ShellyPlus1PM ja Antwort.
Geht denn das normale Webinterface "http://<ip>/" bei den Gen2 Geräten? Wäre zumindest meine Erwartung.
Edit 17:10 Uhr
Ist Error 401 nicht "401 Error Unauthorized Access"? Hast Du schon einen User/Passwort im Shelly für den Zugriff eingestellt. Dann nimm den doch mal raus.
ZitatMeine Anmerkung galt den Maintainern mit so einem Zoo zurecht zu kommen
Das genau war für mich der Grund, mich da etwas zurückzuziehen. Pack ich einfach zeitlich nicht - vielleicht wenn ich im Ruhestand bin??? Obwohl ich dann schon wieder tausend andere Ideen habe...
LG
pah
Zitat von: Prof. Dr. Peter Henning am 17 Januar 2023, 19:11:00
Pack ich einfach zeitlich nicht - vielleicht wenn ich im Ruhestand bin??? Obwohl ich dann schon wieder tausend andere Ideen habe...
... da bin ich mal froh, dass es nicht nur mir so geht ;) ;D
... keine 300 Tage mehr .... :P
LG
Papa Romeo
Hallo,
@RalfRog, HTTP Error 401 war der richtige Hinweis! Nachdem ich Benutzer/Kennwort rausgenommen habe, funktioniert auch http://<IP>/rpc/Shelly.GetStatus. Hier die komplette Ausgabe der Website:
{"ble":{},"cloud":{"connected":false},"input:0":{"id":0,"state":false},"mqtt":{"connected":false},"switch:0":{"id":0, "source":"timer", "output":false, "apower":0.0, "voltage":233.2, "current":0.000, "aenergy":{"total":9.634,"by_minute":[0.000,0.000,0.000],"minute_ts":1673980938},"temperature":{"tC":null, "tF":null}},"sys":{"mac":"A8032ABBA9B8","restart_required":false,"time":"19:42","unixtime":1673980940,"uptime":45948,"ram_size":249064,"ram_free":144892,"fs_size":458752,"fs_free":98304,"cfg_rev":10,"kvs_rev":0,"schedule_rev":0,"webhook_rev":0,"available_updates":{"stable":{"version":"0.12.0"}}},"wifi":{"sta_ip":"10.10.10.10","status":"got ip","ssid":"NASA","rssi":-47},"ws":{"connected":false}}
Vielleicht kann jemand den Wert des "aenergy:total" in das Modul 36_Shelly.pm integrieren? Ich kann es leider nicht. Zur Zeit möchte ich nicht auf User/Kennwort verzichten. Ich schaue mir mal die Möglichkeit mit HTTPMOD an.
Vielen Dank für die Hilfe.
Feller
Damit das nicht zu OT wird mach nen neuen Beitrag in
Edit: Sonstige Syteme
auf.
Kann da gern mein HTTMOD-Beispiel für die Abfrage meines PiHole reinhängen. Müsste hier bei dem JSON-String ähnlich einfach sein.
Danach erst wieder über User/Kennwort nachdenken.
Gruß Ralf
Edit:
JsonMod wäre vermutlich auch eine gute Anlaufstelle die Shelly's alternativ per HTTP abzufragen.
Müsste vermutlich im Modul so angesprochen werden.
Gen1 per <IP>/status
Gen2 per <IP>/rpc/Shelly.GetStatus (auch bei mehrkanaligen Geräten)
Zitat von: Starkstrombastler am 18 Dezember 2022, 09:55:31
Ich werde in den nächsten Tagen an dieser Stelle eine neue Version veröffentlichen, welche den Shelly Plus2PM weitergehend berücksichtigt.
Inzwischen sind ein paar Tage vergangen .... und mit viel, viel mehr Aufwand wie gedacht habe ich eine Version mit den erforderlichen Erweiterungen für die 2. Gen. Dabei werden auch die "Actions" genutzt, so dass der Shelly bei Eintreten eines Events (im Shelly) die Aktualisierung der Readings anstoßen kann.
Bevor ich das hier präsentiere stehen aber noch Tests mit meinem Produktivsystem an - bis dahin bitte noch etwas Geduld.
Tolle Sache! ;D
Hast Du dich ausschließlich auf Gen2 konzentriert?
Mir würde für den 3EM auch noch eine Ergänzung einfallen....
Gruß Ralf
Zitatviel, viel mehr Aufwand wie gedacht
Genau das war der Grund, warum ich es nicht mehr machen konnte. Danke für die hineingesteckte Arbeit, beim Testen helfe ich gerne wieder mit.
LG
pah
Zitat von: Starkstrombastler am 30 Januar 2023, 18:16:21
Bevor ich das hier präsentiere stehen aber noch Tests mit meinem Produktivsystem an - bis dahin bitte noch etwas Geduld.
Kann ich beim Testen helfen? Habe auch einen Plus 2 PM hier, für die Rollladen-/Fenstersteuerung.
Zitat von: RalfRog am 31 Januar 2023, 14:28:05
Tolle Sache! ;D
Hast Du dich ausschließlich auf Gen2 konzentriert?
Mir würde für den 3EM auch noch eine Ergänzung einfallen....
und ja, natürlich helfe ich beim Testen mit kleinem Gerätepark vor allem der 3EM (und PlugS sowie ggf. 1PM).
Ich habe einen fetten Shelly-Zoo (allerdings überwiegend Gen1) und helfe gerne ebenfalls mit.
@Lichti6: wie im Thread Titel zu lesen ist das hier der Support-Thread für das Shelly-Modul! Nicht für eine Anbindung per mqtt!
Das hier wäre evtl. ein passender Thread:
https://forum.fhem.de/index.php/topic,129394.msg1243506.html#msg1243506
Oder selber im Forum suchen...
Gruß, Joachim
Hallo,
das Interval vom shelly modul wird in Sekunden angegeben.
Wie verhält sich ein svg-Plot, wenn ich jetzt z. b. 30 Minuten als interval einstelle, und nach z. b. 15 Minuten für 5 Minuten eine größeren Stromverbraucher einschalte.
Wird mir dieser "Ausschlag" in der Grafik nicht angezeigt?
Vielen Dank
Viele Grüße
Ruggy
Na du erhältst alle 30 Minuten den zu diesem Zeitpunkt aktuellen Wert.
Fragst du Leistungswerte ab siehst du die Spitze nicht.
Hast Du Energiewerte werden die "aufaddiert". Also kommt nach 30 Minuten der Energieverbrauch von den 5 Minuten zum vorherigen Wert dazu.
So verhalten sich die Energiereadings vom PlugS, 3EM und 1PM.
Zitat von: Ruggy am 19 Februar 2023, 17:30:56
...
Wird mir dieser "Ausschlag" in der Grafik nicht angezeigt?
....
Also jein. Kommt drauf an was du plottest.
Deine Frage bezieht sich vermutlich auf Leistung - also nein.
Selbst wenn Du alle 2 Minuntej abfragst siehst du einen 30 Sekunden-Peak nicht. Da geht nur selber rechnen. Delta Energie geteilt durch Zeit = durchschnittliche Leistung, ist aber vermutlich auch nicht das was man will.
Gruß Ralf
Hallo an die Runde!
Ich habe seit gestern einen Shelly EM (nicht den 3EM) in FHEM eingebunden, aber ich bin etwas verwirrt wegen der Einheit von "total".
Beim Shelly Plug S musste man den Total Energy (Watt Minuten) Wert durch 60 und 1000 dividieren um auf kWh zu kommen.
Beim Shelly EM hatte ich laut Shelly App ca. 10,5kWh Verbrauch, erhalte aber den Wert 175 in FHEM.
Eigentlich könnte man die Werte 1:1 aus der Schnittstelle entnehmen, sie kommen bereits in Wh daher.
https://shelly-api-docs.shelly.cloud/gen1/#shelly-em-relay-0
Shelly EM: /emeter/{index}
total: Total consumed energy, Wh
Ich müsste den Wert mal 60 nehmen und dann durch 1000 dividieren? (175*60/1000=10,5kWh)
Ist das wirklich so gewollt? Welche Einheit soll energy_1 darstellen?
Würde das Reading Wminuten anzeigen, müsste ich doch 175/60/1000 machen.
Ich vermute das Shelly Modul macht intern immer die Divison durch 60 (wie bei den anderen Devices nötig), was beim Shelly EM aber nicht nötig ist. Und ich müsste sie dann mit mal 60 wieder retourrechnen...
Übrigens: Das Attribute model habe ich auf "shellyem" gesetzt, ansonsten nur die IP Adresse beim erstellen des Devices angeben.
Und das Modul habe ich soeben aktualisiert und FHEM neu gestartet. Problem bleibt bestehen.
Danke schon mal an alle!
Die Version im SVN ist älter (05.2022) => my $version = "4.01"
Es gibt eine my $version = "4.02f" im Beitrag #251 (09.2022) (4.02f https://forum.fhem.de/index.php/topic,118446.msg1233686.html#msg1233686 (https://forum.fhem.de/index.php/topic,118446.msg1233686.html#msg1233686))
Keine Ahnung ob das etwas ändert.
So ein Rechenfehler war auch im 36_ShellyMonitor.pm von gvzdus (https://forum.fhem.de/index.php/topic,118446.msg1255032.html#msg1255032 (https://forum.fhem.de/index.php/topic,118446.msg1255032.html#msg1255032))
=> Wenn der EM im Code wie ein 1PM oder so gehandhabt wird passiert das. Die Dinger haben ja Wattminuten. Ich glaube bis auf den 3EM werden die 1Gen gleich berechnet. Das ist dann für dem EM falsch.
So, es ist soweit. Anbei eine neue (Test-)Version des Shelly-Moduls, in der sich meine ersten Modul-Entwicklungs-Gehversuche auf Basis des von PAH entwickelten Moduls (v. 4.02f, 3.9.2022) etablieren.
Berücksichtigt ist insbesondere die 2. Gen. Es sollten alle Shellies mit Relais (plus1, plus2, pro1, pro2, ...) unterstützt werden.
Alle die gerne testen möchten sollten dies jetzt ausgiebig tun, da ich selbst auch nicht alle Geräte vor Ort habe.
Getested habe ich mit folgenden Shellies: shelly1, shelly1pm, shelly2 (roller), shelly4, shellydimmer, shellyrgbw (white + color), shellyi3, shellyplug, shellyplus2m (relay + roller).
Was gibt es sonst noch:
Für die Gen. 2 Geräte besteht ein Attribut "webhooks": Hier lässt sich ein FHEM-WEB device auswählen, auf welches Webhooks ausgerichtet werden. Die Webhooks werden von fhem aus im Shelly abgelegt und ermöglichen ein nahezu verzögerungsloses Nachführen der Readings für Eingänge und Ausgänge. Ist im FHEMWEB-device ein Token definiert, wird dies im Webhook mit aufgenommen und bei Bedarf (z.B. bei fhem-Neustart) im Shelly aktualisiert.
Mit dem Attribut "showunits" werden die Einheiten, insbesondere Energie und Leistung, in den Readings mit aufgenommen. Damit soll die bisweilen bestehende Verwirrung aufgehoben werden, weil die Shellies unterschiedliche Einheiten nutzen (Watt-Minuten, Watt-Stunden, etc.). Werden diese Readings in Notify o.ä. verwendet, sollte diese von ReadingsVal auf ReadingsNum umgestellt werden.
Mit dem Attribut "showinputs" werden Readings für die Konfiguration der Eingänge (button, switch, inverted, ...) und den Status der Eingänge (buttons) angezeigt. Das ist dann sinnvoll, wenn die Eingänge via Webhook vom Shelly getriggert werden.
Die bisherige Notwendigkeit, das Model direkt im Anschluss der Definition (define) als Attribut festzulegen, entfällt. Das Model wird vom Modul ermittelt und (aus Kompatibiltäsgründen) weiterhin als Attribut abgelegt. Ebenso wird bei "Multi-mode" Shellies (also Shelly(..)2.. u.a.) der Mode vom Shelly abgefragt und als Attribut abgelegt.
Die (englische) Online-Doku habe ich für das Testen umgehangen, so dass die Infos leichter zur Verfügung stehen.
Jetzt bin ich mal auf die Testergebnisse gespannt. Aber zunächst stehen die Feiertage an, danach geht es weiter.
Frohe Ostern
Bernhard
Ein Hinweis wäre eventuell noch hilfreich.
Damit der "ShellyMonitor" nicht in die Suppe spuckt sollte man ihn eventuell dekativieren, da er mit dem "alten" Modul zusammenarbeitet.
Erster Test definieren eines ShellyPlug-S(vorher alle Shellies aus der Testinstllation gelöscht)
==> define Shelly_Plug Shelly <IP>
- Attribut model wird nicht automatisch gesetzt
- Reading relay fehlt
- Reading power fehlt
- Reading energy fehlt
- ggfs. Reading overpower fehlt (gab es vorher)
Readings im ersten Schritt| cloud | disabled | 2023-04-11 23:03:14 |
| firmware | v1.10.1 | 2023-04-11 23:03:14 |
| inttemp | 23.77 | 2023-04-11 23:19:15 |
| network | connected to 11.12.13.14 | 2023-04-11 23:02:14 |
| state | OK | 2023-04-11 23:03:14 |
Nach setzen des Modells shellyplug kommen drei Readings dazu| energy | 39156.5 | 2023-04-11 23:28:16 |
| power | 0 | 2023-04-11 23:28:16 |
| relay | on | 2023-04-11 23:28:16 |
Dann läuft alle Minute2023.04.11 23:45:18.145 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:46:18.213 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:46:18.282 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:46:18.286 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggleMuss bei Gen1 nicht einfach einmal im Intervall der Status abgerufen werden? Was machen die SET's?
LogauszugIm Verlauf verbose 4 und dann noch 5 eingestellt, kurz nach setzen des Modells endet hier der Logauszug
einmalig taucht auf: 23:02:14.442 2: [Shelly_get_model] has invalid JSON data for device Shelly_Plug
2023.04.11 23:02:14.361 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:02:14.365 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:02:14.372 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:02:14.375 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:02:14.382 2: [Shelly_Get] Shelly_Plug: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.11 23:02:14.437 2: [Shelly_get_model] Shelly_Plug: received 1778 byte of data from device
>>> 2023.04.11 23:02:14.442 2: [Shelly_get_model] has invalid JSON data for device Shelly_Plug
2023.04.11 23:02:14.456 2: [Shelly_get_model] Shelly_Plug: received 9 byte of data from device
2023.04.11 23:02:14.459 2: [Shelly_get_model] no endpoint found for URL on device Shelly_Plug
2023.04.11 23:02:14.767 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:02:14.770 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:02:24.284 3: [Shelly_shelly] Shelly_Plug is a first Gen device
2023.04.11 23:02:24.287 1: [Shelly_shelly] aborting, Shelly_Plug is not 2nd Gen
2023.04.11 23:03:14.284 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:03:14.369 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:03:14.373 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
...
...
...
2023.04.11 23:08:14.731 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:08:14.798 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:08:14.801 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
>>> verbose 4
2023.04.11 23:08:52.353 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:08:52.356 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:08:52.437 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:08:52.440 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:08:52.447 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:08:52.450 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:08:52.455 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.04.11 23:08:52.459 2: [Shelly_Get] Shelly_Plug: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
...
...
...
2023.04.11 23:11:05.696 4: [Shelly_Get] receiving command get Shelly_Plug config
2023.04.11 23:11:05.700 2: [Shelly_configure] Shelly_Plug: received command=settings/relay/0?default_state
2023.04.11 23:11:05.704 3: [Shelly_configure] issue a non-blocking call to http://10.20.30.90/settings/relay/0?default_state
2023.04.11 23:11:05.738 2: [Shelly_configure] Shelly_Plug: received command=settings/relay/0?default_state
2023.04.11 23:11:05.742 2: [Shelly_configure] device Shelly_Plug has returned 175 bytes of data
2023.04.11 23:11:05.745 4: [Shelly_configure] device Shelly_Plug processing "settings/relay/0?default_state"
2023.04.11 23:11:05.748 4: [Shelly_configure] device Shelly_Plug result is reg: default_state chan [channel 0] value on
2023.04.11 23:11:05.761 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:11:05.764 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
...
...
...
2023.04.11 23:27:16.367 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:27:16.434 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:27:16.438 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:27:24.632 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:27:24.635 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:27:24.709 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:27:24.713 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:27:24.719 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:27:24.723 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.11 23:27:24.728 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.04.11 23:27:24.732 2: [Shelly_Get] Shelly_Plug: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.11 23:27:46.199 5: [Shelly_Attr] Shelly_Plug: called with command set for attribute model and value shellyplug
2023.04.11 23:27:46.220 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:27:46.224 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:27:46.306 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:27:46.309 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:27:46.318 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:27:46.321 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:27:46.328 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.04.11 23:27:46.331 2: [Shelly_Get] Shelly_Plug: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.11 23:28:05.478 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:28:05.481 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:28:05.490 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:28:05.493 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:28:05.499 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.04.11 23:28:05.502 2: [Shelly_Get] Shelly_Plug: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.11 23:28:16.452 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:28:16.533 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:28:16.536 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:29:16.564 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:29:16.646 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:29:16.650 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:29:41.868 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:29:41.871 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:29:41.889 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:29:41.892 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:29:41.898 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.04.11 23:29:41.901 2: [Shelly_Get] Shelly_Plug: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.11 23:30:16.678 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:30:16.754 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:30:16.757 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:31:16.784 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:31:16.851 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:31:16.854 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.11 23:32:16.881 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:33:16.948 3: [Shelly_status] issue a non-blocking call to http://10.20.30.90/status
2023.04.11 23:33:17.017 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.11 23:33:17.021 2: [Shelly_Set] Shelly_Plug model=shellyplug: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggleGruß Ralf
Der 3EM folgt
Zweiter Test definieren eines Shelly 3EM==> define Shelly_3EM Shelly <IP>
- Attribut model wird gesetzt
- vorherige Readings scheinen da zu sein
- einige interessante Reading fehlen
Readings| cloud | disabled | 2023-04-12 00:04:02 |
| energy_0 | 239407.7 | 2023-04-12 00:10:03 |
| energy_1 | 253059.9 | 2023-04-12 00:10:03 |
| energy_2 | 303575.8 | 2023-04-12 00:10:03 |
| firmware | v1.11.8(update needed to v1.12.1) | 2023-04-12 00:04:02 |
| network | connected to 11.12.13.14 | 2023-04-12 00:03:02 |
| power_0 | 208.74 | 2023-04-12 00:10:03 |
| power_1 | 26.26 | 2023-04-12 00:10:03 |
| power_2 | 3.43 | 2023-04-12 00:10:03 |
| relay | off | 2023-04-12 00:04:02 |
| state | OK | 2023-04-12 00:04:02 |
| voltage_0 | 228.33 | 2023-04-12 00:10:03 |
| voltage_1 | 228.94 | 2023-04-12 00:10:03 |
| voltage_2 | 228.91 | 2023-04-12 00:10:03 |
Der 3EM hat - analog zu voltage noch current
- analog zu energy noch energyReturned (wichtig und interessant mit Solargeschichten)
- und total_power
- sowie den PowerFactor
Als JSON Struktur
emeters
0
power 212.29
pf 0.8
current 1.16
voltage 228.25
is_valid true
total 239463.9
total_returned 18320.5
1
power 25.78
pf 0.36
current 0.31
voltage 228.8
is_valid true
total 253082.7
total_returned 0
2
power 3.63
pf 0.07
current 0.23
voltage 228.67
is_valid true
total 303595.7
total_returned 0
total_power 241.7 Log dazu (verbose3)2023.04.12 00:03:02.664 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:03:02.667 2: [Shelly_Set] Shelly_3EM model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.12 00:03:02.676 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:03:02.679 2: [Shelly_Set] Shelly_3EM model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.12 00:03:02.685 2: [Shelly_Get] Shelly_3EM: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.12 00:03:02.830 2: [Shelly_get_model] Shelly_3EM: received 2037 byte of data from device
2023.04.12 00:03:02.839 2: [Shelly_get_model] discovered model=shelly3em for device Shelly_3EM
>>>> 2023.04.12 00:03:02.844 1: PERL WARNING: Use of uninitialized value $mode in string eq at ./FHEM/36_Shelly.pm line 464.
2023.04.12 00:03:02.853 2: [Shelly_get_model] Shelly_3EM: received 9 byte of data from device
2023.04.12 00:03:02.856 2: [Shelly_get_model] no endpoint found for URL on device Shelly_3EM
2023.04.12 00:03:02.995 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:03:02.998 2: [Shelly_Set] Shelly_3EM model=shelly3em: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.12 00:03:12.589 3: [Shelly_shelly] Shelly_3EM is a first Gen device
2023.04.12 00:03:12.592 1: [Shelly_shelly] aborting, Shelly_3EM is not 2nd Gen
2023.04.12 00:04:02.589 3: [Shelly_status] issue a non-blocking call to http://10.20.30.92/status
2023.04.12 00:04:02.669 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:04:02.673 2: [Shelly_Set] Shelly_3EM model=shelly3em: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.12 00:04:22.712 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:04:22.715 2: [Shelly_Set] Shelly_3EM model=shelly3em: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.12 00:04:22.725 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:04:22.728 2: [Shelly_Set] Shelly_3EM model=shelly3em: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.12 00:04:22.734 2: [Shelly_Get] Shelly_3EM: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.12 00:05:02.698 3: [Shelly_status] issue a non-blocking call to http://10.20.30.92/status
2023.04.12 00:05:02.818 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:05:02.821 2: [Shelly_Set] Shelly_3EM model=shelly3em: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.12 00:05:26.850 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:05:26.853 2: [Shelly_Set] Shelly_3EM model=shelly3em: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.12 00:05:26.862 3: [Shelly_Set] calling for device Shelly_3EM with command ?, without value
2023.04.12 00:05:26.866 2: [Shelly_Set] Shelly_3EM model=shelly3em: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle
2023.04.12 00:05:26.872 2: [Shelly_Get] Shelly_3EM: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
Was machen die Set und Get?
Hallo Ralf Rog und all die anderen, die sich das bisher angeschaut haben.
Von den vielen Logeinträgen bitte nicht irritieren lassen, das kommt aus vielen zusätzlichen Log-Befehlen, damit ich die Funktionen besser verstehe. Das wird am Ende wieder aufgeräumt.
Einige Punkte konnte ich bereits bearbeiten, es kommt eine neue Version.
Bei dem Punkt
unknown argument ? choose one of config password reboot:noArg update:noArg .....bin ich total ratlos. Die set-Befehle werden wohl von FHEMWEB gesendet und dienen dem Aufbau der set-Menus, vgl. Development Module Intro (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Set). Aber in dieser Häufigkeit?
Nebenbei: Heute wurde mein ShellyPro3EM geliefert.....
Gruß
Bernhard
Die Häufigkeit entspricht dem Intervall.
Bzw. kommt auch wenn man oben den Namen anklickt.
Gruß Ralf
Hi @Starkstrombastler
=> Autoerkennung des ShellyPlugS hat nicht funktioniert. Habe mal versucht etwas präzisere Daten zu erhalten
=> Wenn du Folgendes zur Analyse brauchen kannst...
- global verbose 5, die paar Geräte die noch drin sind individuell auf verbose 0
- define Shelly_Plug Shelly 11.12.13.14
- bis zum ok im Status den Log mitgeschrieben
LOG2023.04.14 19:47:55.152 5: Cmd: >define Shelly_Plug Shelly 11.12.13.14<
2023.04.14 19:47:55.162 5: HttpUtils url=http://11.12.13.14/settings NonBlocking via http
2023.04.14 19:47:55.164 4: IP: 11.12.13.14 -> 11.12.13.14
2023.04.14 19:47:55.172 5: HttpUtils url=http://11.12.13.14/rpc/Shelly.GetDeviceInfo NonBlocking via http
2023.04.14 19:47:55.176 4: IP: 11.12.13.14 -> 11.12.13.14
2023.04.14 19:47:55.186 5: Starting notify loop for Shelly_Plug, 2 event(s), first is initialized
2023.04.14 19:47:55.195 5: End notify loop for Shelly_Plug
2023.04.14 19:47:55.200 5: Starting notify loop for global, 1 event(s), first is DEFINED Shelly_Plug
2023.04.14 19:47:55.202 5: createNotifyHash
2023.04.14 19:47:55.218 5: Installer (fhemInstaller) - Notify: $VAR1 = [
'DEFINED Shelly_Plug'
];
2023.04.14 19:47:55.227 5: End notify loop for global
2023.04.14 19:47:55.235 5: HttpUtils request header:
GET /settings HTTP/1.0
Host: 11.12.13.14
User-Agent: fhem
Accept-Encoding: gzip,deflate
2023.04.14 19:47:55.241 5: HttpUtils request header:
GET /rpc/Shelly.GetDeviceInfo HTTP/1.0
Host: 11.12.13.14
User-Agent: fhem
Accept-Encoding: gzip,deflate
2023.04.14 19:47:55.305 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:47:55.307 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:47:55.313 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:47:55.315 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:47:55.320 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.04.14 19:47:55.322 2: [Shelly_Get] Shelly_Plug: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.14 19:47:55.441 4: http://11.12.13.14/settings: HTTP response code 200
2023.04.14 19:47:55.443 5: HttpUtils http://11.12.13.14/settings: Got data, length: 1778
2023.04.14 19:47:55.445 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: Mongoose/6.18
Connection: close
Content-Type: application/json
Content-Length: 1778
2023.04.14 19:47:55.447 2: [Shelly_get_model] Shelly_Plug: received 1778 byte of data from device
2023.04.14 19:47:55.451 2: [Shelly_get_model] has invalid JSON data for device Shelly_Plug
2023.04.14 19:47:55.456 5: Starting notify loop for Shelly_Plug, 1 event(s), first is Error
2023.04.14 19:47:55.465 5: End notify loop for Shelly_Plug
2023.04.14 19:47:55.494 4: http://11.12.13.14/rpc/Shelly.GetDeviceInfo: HTTP response code 404
2023.04.14 19:47:55.497 5: HttpUtils http://11.12.13.14/rpc/Shelly.GetDeviceInfo: Got data, length: 9
2023.04.14 19:47:55.500 5: HttpUtils response header:
HTTP/1.1 404 Not Found
Server: Mongoose/6.18
Content-Type: text/plain
Connection: close
Content-Length: 9
2023.04.14 19:47:55.502 2: [Shelly_get_model] Shelly_Plug: received 9 byte of data from device
2023.04.14 19:47:55.504 2: [Shelly_get_model] no endpoint found for URL on device Shelly_Plug
2023.04.14 19:47:55.551 5: Cmd: >{ReadingsVal("Shelly_Plug","config","")}<
2023.04.14 19:47:55.567 5: Cmd: >{AttrVal("Shelly_Plug","room","")}<
2023.04.14 19:47:55.667 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:47:55.669 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:48:05.202 3: [Shelly_shelly] Shelly_Plug is a first Gen device
2023.04.14 19:48:05.204 1: [Shelly_shelly] aborting, Shelly_Plug is not 2nd Gen
2023.04.14 19:48:55.200 3: [Shelly_status] issue a non-blocking call to http://11.12.13.14/status
2023.04.14 19:48:55.203 5: HttpUtils url=http://11.12.13.14/status NonBlocking via http
2023.04.14 19:48:55.206 4: IP: 11.12.13.14 -> 11.12.13.14
2023.04.14 19:48:55.218 5: HttpUtils request header:
GET /status HTTP/1.0
Host: 11.12.13.14
User-Agent: fhem
Accept-Encoding: gzip,deflate
2023.04.14 19:48:55.248 4: http://11.12.13.14/status: HTTP response code 200
2023.04.14 19:48:55.250 5: HttpUtils http://11.12.13.14/status: Got data, length: 851
2023.04.14 19:48:55.252 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: Mongoose/6.18
Connection: close
Content-Type: application/json
Content-Length: 851
2023.04.14 19:48:55.258 5: [Shelly_proc1G] Model of device Shelly_Plug is generic and mode is . Updates every 60 seconds. Data is:
{"wifi_sta":{"connected":true,"ssid":"WLAN_SSID","ip":"11.12.13.14","rssi":-85},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"18:48","unixtime":1681494536,"serial":32648,"has_update":false,"mac":"3C6105DF2674","cfg_changed_cnt":1,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"input"}],"meters":[{"power":0.74,"overpower":0.00,"is_valid":true,"timestamp":1681498136,"counters":[0.816, 0.881, 1.048],"total":2509874}],"temperature":28.89,"overtemperature":false,"tmp":{"tC":28.89,"tF":84.00, "is_valid":true},"update":{"status":"unknown","has_update":false,"new_version":"","old_version":"20210323-105718/v1.10.1-gf276b51"},"ram_total":50632,"ram_free":39884,"fs_size":233681,"fs_free":166915,"uptime":9343300}
2023.04.14 19:48:55.264 5: Starting notify loop for Shelly_Plug, 4 event(s), first is inttemp: 28.89
2023.04.14 19:48:55.275 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:48:55.278 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:48:55.286 5: End notify loop for Shelly_Plug
2023.04.14 19:49:06.147 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:49:06.155 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:49:06.161 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:49:06.163 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:49:06.167 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.04.14 19:49:06.170 2: [Shelly_Get] Shelly_Plug: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
2023.04.14 19:49:06.366 5: Cmd: >{ReadingsVal("Shelly_Plug","config","")}<
2023.04.14 19:49:06.378 5: Cmd: >{AttrVal("Shelly_Plug","room","")}<dann Minütlich############# 1 #############
2023.04.14 19:49:55.292 3: [Shelly_status] issue a non-blocking call to http://11.12.13.14/status
2023.04.14 19:49:55.295 5: HttpUtils url=http://11.12.13.14/status NonBlocking via http
2023.04.14 19:49:55.298 4: IP: 11.12.13.14 -> 11.12.13.14
2023.04.14 19:49:55.310 5: HttpUtils request header:
GET /status HTTP/1.0
Host: 11.12.13.14
User-Agent: fhem
Accept-Encoding: gzip,deflate
2023.04.14 19:49:55.338 4: http://11.12.13.14/status: HTTP response code 200
2023.04.14 19:49:55.341 5: HttpUtils http://11.12.13.14/status: Got data, length: 851
2023.04.14 19:49:55.343 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: Mongoose/6.18
Connection: close
Content-Type: application/json
Content-Length: 851
2023.04.14 19:49:55.347 5: [Shelly_proc1G] Model of device Shelly_Plug is generic and mode is . Updates every 60 seconds. Data is:
{"wifi_sta":{"connected":true,"ssid":"WLAN_SSID","ip":"11.12.13.14","rssi":-86},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"18:49","unixtime":1681494596,"serial":32648,"has_update":false,"mac":"3C6105DF2674","cfg_changed_cnt":1,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"input"}],"meters":[{"power":0.68,"overpower":0.00,"is_valid":true,"timestamp":1681498196,"counters":[0.759, 0.816, 0.881],"total":2509875}],"temperature":28.83,"overtemperature":false,"tmp":{"tC":28.83,"tF":83.90, "is_valid":true},"update":{"status":"unknown","has_update":false,"new_version":"","old_version":"20210323-105718/v1.10.1-gf276b51"},"ram_total":50632,"ram_free":39884,"fs_size":233681,"fs_free":166915,"uptime":9343360}
2023.04.14 19:49:55.352 5: Starting notify loop for Shelly_Plug, 1 event(s), first is inttemp: 28.83
2023.04.14 19:49:55.354 5: createNotifyHash
2023.04.14 19:49:55.373 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:49:55.375 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:49:55.385 5: End notify loop for Shelly_Plug
############# 2 #############
2023.04.14 19:50:55.392 3: [Shelly_status] issue a non-blocking call to http://11.12.13.14/status
2023.04.14 19:50:55.396 5: HttpUtils url=http://11.12.13.14/status NonBlocking via http
2023.04.14 19:50:55.398 4: IP: 11.12.13.14 -> 11.12.13.14
2023.04.14 19:50:55.410 5: HttpUtils request header:
GET /status HTTP/1.0
Host: 11.12.13.14
User-Agent: fhem
Accept-Encoding: gzip,deflate
2023.04.14 19:50:55.439 4: http://11.12.13.14/status: HTTP response code 200
2023.04.14 19:50:55.441 5: HttpUtils http://11.12.13.14/status: Got data, length: 851
2023.04.14 19:50:55.444 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: Mongoose/6.18
Connection: close
Content-Type: application/json
Content-Length: 851
2023.04.14 19:50:55.449 5: [Shelly_proc1G] Model of device Shelly_Plug is generic and mode is . Updates every 60 seconds. Data is:
{"wifi_sta":{"connected":true,"ssid":"WLAN_SSID","ip":"11.12.13.14","rssi":-86},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"18:50","unixtime":1681494656,"serial":32648,"has_update":false,"mac":"3C6105DF2674","cfg_changed_cnt":1,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"input"}],"meters":[{"power":0.81,"overpower":0.00,"is_valid":true,"timestamp":1681498256,"counters":[0.722, 0.759, 0.816],"total":2509876}],"temperature":28.78,"overtemperature":false,"tmp":{"tC":28.78,"tF":83.80, "is_valid":true},"update":{"status":"unknown","has_update":false,"new_version":"","old_version":"20210323-105718/v1.10.1-gf276b51"},"ram_total":50632,"ram_free":39884,"fs_size":233681,"fs_free":166915,"uptime":9343420}
2023.04.14 19:50:55.454 5: Starting notify loop for Shelly_Plug, 1 event(s), first is inttemp: 28.78
2023.04.14 19:50:55.465 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:50:55.467 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:50:55.473 5: End notify loop for Shelly_Plug
############# 3 #############
2023.04.14 19:51:55.479 3: [Shelly_status] issue a non-blocking call to http://11.12.13.14/status
2023.04.14 19:51:55.482 5: HttpUtils url=http://11.12.13.14/status NonBlocking via http
2023.04.14 19:51:55.485 4: IP: 11.12.13.14 -> 11.12.13.14
2023.04.14 19:51:55.496 5: HttpUtils request header:
GET /status HTTP/1.0
Host: 11.12.13.14
User-Agent: fhem
Accept-Encoding: gzip,deflate
2023.04.14 19:51:55.525 4: http://11.12.13.14/status: HTTP response code 200
2023.04.14 19:51:55.528 5: HttpUtils http://11.12.13.14/status: Got data, length: 851
2023.04.14 19:51:55.530 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: Mongoose/6.18
Connection: close
Content-Type: application/json
Content-Length: 851
2023.04.14 19:51:55.535 5: [Shelly_proc1G] Model of device Shelly_Plug is generic and mode is . Updates every 60 seconds. Data is:
{"wifi_sta":{"connected":true,"ssid":"WLAN_SSID","ip":"11.12.13.14","rssi":-86},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"18:51","unixtime":1681494716,"serial":32648,"has_update":false,"mac":"3C6105DF2674","cfg_changed_cnt":1,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"input"}],"meters":[{"power":0.87,"overpower":0.00,"is_valid":true,"timestamp":1681498316,"counters":[0.736, 0.722, 0.759],"total":2509876}],"temperature":29.06,"overtemperature":false,"tmp":{"tC":29.06,"tF":84.31, "is_valid":true},"update":{"status":"unknown","has_update":false,"new_version":"","old_version":"20210323-105718/v1.10.1-gf276b51"},"ram_total":50632,"ram_free":39884,"fs_size":233681,"fs_free":166915,"uptime":9343480}
2023.04.14 19:51:55.540 5: Starting notify loop for Shelly_Plug, 1 event(s), first is inttemp: 29.06
2023.04.14 19:51:55.550 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:51:55.552 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:51:55.557 5: End notify loop for Shelly_Plug
############# 4 #############
2023.04.14 19:52:55.564 3: [Shelly_status] issue a non-blocking call to http://11.12.13.14/status
2023.04.14 19:52:55.568 5: HttpUtils url=http://11.12.13.14/status NonBlocking via http
2023.04.14 19:52:55.571 4: IP: 11.12.13.14 -> 11.12.13.14
2023.04.14 19:52:55.584 5: HttpUtils request header:
GET /status HTTP/1.0
Host: 11.12.13.14
User-Agent: fhem
Accept-Encoding: gzip,deflate
2023.04.14 19:52:55.611 4: http://11.12.13.14/status: HTTP response code 200
2023.04.14 19:52:55.613 5: HttpUtils http://11.12.13.14/status: Got data, length: 851
2023.04.14 19:52:55.616 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: Mongoose/6.18
Connection: close
Content-Type: application/json
Content-Length: 851
2023.04.14 19:52:55.621 5: [Shelly_proc1G] Model of device Shelly_Plug is generic and mode is . Updates every 60 seconds. Data is:
{"wifi_sta":{"connected":true,"ssid":"WLAN_SSID","ip":"11.12.13.14","rssi":-85},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"18:52","unixtime":1681494776,"serial":32648,"has_update":false,"mac":"3C6105DF2674","cfg_changed_cnt":1,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"input"}],"meters":[{"power":0.70,"overpower":0.00,"is_valid":true,"timestamp":1681498376,"counters":[0.757, 0.736, 0.722],"total":2509877}],"temperature":28.78,"overtemperature":false,"tmp":{"tC":28.78,"tF":83.80, "is_valid":true},"update":{"status":"unknown","has_update":false,"new_version":"","old_version":"20210323-105718/v1.10.1-gf276b51"},"ram_total":50632,"ram_free":39884,"fs_size":233681,"fs_free":166915,"uptime":9343540}
2023.04.14 19:52:55.626 5: Starting notify loop for Shelly_Plug, 1 event(s), first is inttemp: 28.78
2023.04.14 19:52:55.636 3: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.04.14 19:52:55.638 2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
2023.04.14 19:52:55.644 5: End notify loop for Shelly_Plug
Zunächst mal danke an Starkstrombastler für die Weiterentwicklung des Moduls.
Poste dann hier meinen Versuch mit einem Shelly Uni.
Der Shelly ist mit einem DHT22 zur Temperatur und Feuchtemessung verbunden.
List vom Device:
Internals:
DEF 192.168.1.30
FUUID xxxxxxxxxxxxx
INTERVAL 60
NAME myShelly
NR 637
SHELLY SHUNI-1
STATE OK
TCPIP 192.168.1.30
TYPE Shelly
eventCount 729
Helper:
DBLOG:
humidity_0:
logdb:
TIME 1681475544.53637
VALUE 32
temperature_0:
logdb:
TIME 1681475544.53637
VALUE 23
READINGS:
2023-04-14 14:18:16 cloud enabled(connected)
2023-04-12 20:22:32 energy 0 Wh
2023-04-14 14:18:16 firmware v1.13.0-rc1(update needed to v1.12.1)
2023-04-14 14:32:24 humidity_0 32
2023-04-14 14:31:46 network <html>connected to <a href="http://192.168.1.30">192.168.1.30</a></html>
2023-04-12 20:22:32 power W
2023-04-12 02:35:21 relay_0 off
2023-04-12 02:35:21 relay_1 off
2023-04-14 14:32:24 state OK
2023-04-14 14:32:24 temperature_0 23
2023-04-14 14:34:24 voltage 0.05 V
Attributes:
event-on-change-reading temperature_0,humidity_0
model shellyuni
room System
showinputs show
showunits normal
verbose 5
Auszug aus dem Log:
2023.04.14 14:33:13 3: [Shelly_Set] calling for device myShelly with command ?, without value
2023.04.14 14:33:13 2: [Shelly_Set] myShelly model=shellyuni: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle xtrachannels:noArg
2023.04.14 14:33:14 3: [Shelly_Set] calling for device myShelly with command ?, without value
2023.04.14 14:33:14 2: [Shelly_Set] myShelly model=shellyuni: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle xtrachannels:noArg
2023.04.14 14:33:14 3: [Shelly_Set] calling for device myShelly with command ?, without value
2023.04.14 14:33:14 2: [Shelly_Set] myShelly model=shellyuni: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle xtrachannels:noArg
2023.04.14 14:33:14 4: [Shelly_Get] receiving command get myShelly ?
2023.04.14 14:33:14 2: [Shelly_Get] myShelly: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
Es wiederholt sich minütlich:
2023.04.14 14:33:24 3: [Shelly_status] issue a non-blocking call to http://192.168.1.30/status
Diese 2 Warnungen erscheinen regelmäßig, wohl dann wenn sich ein Reading ändert:
2023.04.12 23:29:45 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_Shelly.pm line 1760, <GEN7428531> line 12082.
2023.04.12 23:29:45 1: PERL WARNING: Use of uninitialized value $energy in division (/) at ./FHEM/36_Shelly.pm line 2297, <GEN7428531> line 12082.
2023.04.13 00:14:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_Shelly.pm line 1760, <GEN7428511> line 1306181.
2023.04.13 00:14:47 1: PERL WARNING: Use of uninitialized value $energy in division (/) at ./FHEM/36_Shelly.pm line 2297, <GEN7428511> line 1306181.
2023.04.13 00:25:48 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_Shelly.pm line 1760, <GEN7428511> line 1339083.
2023.04.13 00:25:48 1: PERL WARNING: Use of uninitialized value $energy in division (/) at ./FHEM/36_Shelly.pm line 2297, <GEN7428511> line 1339083.
Ich vermute das es wegen den Readings energy und power ist, die in meinem Fall ja nicht benötigt werden. Ich kann die Readings löschen, sie erscheinen nach einiger Zeit jedoch von selber wieder.
Hoffe du kannst damit etwas anfangen und noch das ein oder andere ausmerzen. Die letzten Warnungen erscheinen trotz Verbose 0 im Log.
Gruß TK67
Zitat von: RalfRog am 14 April 2023, 20:08:342023.04.14 19:49:55.292 3: [Shelly_status] issue a non-blocking call to http://11.12.13.14/status
2023.04.14 19:49:55.295 5: HttpUtils url=http://11.12.13.14/status NonBlocking via http
2023.04.14 19:49:55.298 4: IP: 11.12.13.14 -> 11.12.13.14
....
Zitat von: TK67 am 14 April 2023, 21:00:01Es wiederholt sich minütlich:
2023.04.14 14:33:24 3: [Shelly_status] issue a non-blocking call to http://192.168.1.30/status...
Für Gen1 Geräte ist beim Default-Intervall von 60sec zumindest das Obige normal, da ja minütlich die (Mess)Werte aktualisiert werden und per ~/staus-Abfrage geholt werden.
Nur sind diese Meldungen auch erforderlich bzw. das Ausführen der Sub SET (oder GET) im Code? Im Grunde immer nachfolgend zur Statusabfrage.
Zitat von: RalfRog am 14 April 2023, 20:08:343: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2: [Shelly_Set] Shelly_Plug model=generic: unknown argument ? choose one of config password reboot:noArg update:noArg
Zitat von: TK67 am 14 April 2023, 21:00:013: [Shelly_Set] calling for device myShelly with command ?, without value
2: [Shelly_Set] myShelly model=shellyuni: unknown argument ? choose one of config password reboot:noArg update:noArg off off-for-timer on on-for-timer toggle xtrachannels:noArg
4: [Shelly_Get] receiving command get myShelly ?
2: [Shelly_Get] myShelly: unknown argument ?, choose one of config registers:noArg shelly_status:noArg status:noArg version:noArg
Gruß Ralf
Zitat von: TK67 am 14 April 2023, 21:00:01...Ich vermute das es wegen den Readings energy und power ist, die in meinem Fall ja nicht benötigt werden. Ich kann die Readings löschen, sie erscheinen nach einiger Zeit jedoch von selber wieder....
@Starkstrombastler
Wenn ich es in der API Beschreibung richtig sehe kennt der Shelly Uni keine energy und power.
Hallo,
auch von meiner Seite ein Dankeschön an Starkstrombastler für die Weiterentwicklung des Moduls.
'habe die neue (Test-)Version des Moduls mit meinem "shellyplus2pm" getestet, der seit ein paar Monaten wegen der fehlenden Unterstützung im Schrank lag.
Ich habe erst einmal keine schwerwiegenden Fehler/Probleme feststellen können.
Auch die anderen shelly-Komponenten, die ich schon in Betrieb hatte, zeigen keine Auffälligkeiten.
Auffallend ist hier (wie schon berichtet) die relativ große Gesprächigkeit in der FHEM-Log-Datei (auch unter Verbose 3 noch). Aber das ist ja nur zu Testzwecken.
Zuletzt habe ich dann testweise und aus reiner Neugier mal das Attribute ,,showunits" auf ,,original" gesetzt.
Hierbei zeigte sich, dass dann bei allen Shelly-Geräten die Einheiten angezeigt wurden (also nicht nur bei dem shellyplus2pm-Gerät).
Ist das so gewollt?
Denke es sollte so sein, dass es individuell bei jedem Gerät gesetzt werden kann bzw. wirken soll.
Oder?
Gruß
Xaneu
Hallo Xaneu,
danke fürs Testen.
Zitat von: Xaneu am 01 Mai 2023, 18:17:54Zuletzt habe ich dann testweise und aus reiner Neugier mal das Attribute ,,showunits" auf ,,original" gesetzt.
Hierbei zeigte sich, dass dann bei allen Shelly-Geräten die Einheiten angezeigt wurden (also nicht nur bei dem shellyplus2pm-Gerät).
Das Attribut showunits soll wie alle anderen Attribute immer nur für das jeweilige Device gelten.
Dies und die weiteren gemeldeten "Auffälligkeiten" in der Testversion sollen mit der nächsten Version beseitigt sein, diese folgt in Kürze.
Showunits ist aber derzeit noch inkompatibel zum Shelly-Monitor.
Für den ShellyPlus2PM können mit dem Attribut "webhook" automatisiert Actions im Shelly angelegt werden, die bei entsprechenden Statusänderungen unverzögert eine Meldung an Fhem senden. Das ist sinnvoll, wenn der Shelly z.B. mittels Taster oder App bedient wird. Hat das funktioniert?
Zitat von: Starkstrombastler am 02 Mai 2023, 18:09:16...
Showunits ist aber derzeit noch inkompatibel zum Shelly-Monitor.
...
Schön freue mich auf das Update.
Interessant auch, dass die Weiterentwicklung prinzipiell kompatibel zum Shelly-Monitor ist/bleibt :D
Gibt es dabei Einschränkungen? Modelle, Readings?
Gruß Ralf
Hallo Starkstrombastler,
Zitat von: Starkstrombastler am 02 Mai 2023, 18:09:16Für den ShellyPlus2PM können mit dem Attribut "webhook" automatisiert Actions im Shelly angelegt werden, die bei entsprechenden Statusänderungen unverzögert eine Meldung an Fhem senden. Das ist sinnvoll, wenn der Shelly z.B. mittels Taster oder App bedient wird. Hat das funktioniert?
'habe es gerade mit Setzen des Attributs "
attr Test_shelly webhook WEB" getestet.
Anschließend zeigt der Event-Monitor mit jedem Ereignis an den Eingängen Einträge der folgenden Art:
2023-05-02 18:54:56.231 Shelly Test_shelly relay_0: on
2023-05-02 18:54:57.379 Shelly Test_shelly voltage_1: 232.1 V
2023-05-02 18:54:57.379 Shelly Test_shelly inttemp: 45.8 °C
2023-05-02 18:54:57.396 Shelly Test_shelly voltage_0: 232.1 V
Es funktioniert also.
Mach es nicht Sinn diese Funktion (webhook-Richtung: shelly -> FHEM) standardmäßig zu aktivieren?
Jedenfalls hätte ich ein solches Verhalten erwartet bzw. ist ein solches Verhalten doch (immer) erwünscht.
Die andere Funktion (webhook-Richtung: FHEM -> shelly):
Zitat von: Starkstrombastler am 08 April 2023, 12:15:00Ist im FHEMWEB-device ein Token definiert, wird dies im Webhook mit aufgenommen und bei Bedarf (z.B. bei fhem-Neustart) im Shelly aktualisiert.
habe ich nicht ganz verstanden.
Gruß
Xaneu
Zitat von: RalfRog am 02 Mai 2023, 18:21:31Interessant auch, dass die Weiterentwicklung prinzipiell kompatibel zum Shelly-Monitor ist/bleibt
Das ist zumindest die Absicht.
Betroffen sind aber nur die kabelgebundenen Shellies der ersten Generation. Die Shellies der zweiten Generation unterstützen das von Shelly-Monitor genutzte Protokoll nicht.
Zitat von: Xaneu am 02 Mai 2023, 19:26:35Mach es nicht Sinn diese Funktion (webhook-Richtung: shelly -> FHEM) standardmäßig zu aktivieren?
Mit dem Attribut hat der Nutzer die Möglichkeit, die FHEMWEB-Instanz, an welche der Shelly sendet, auszuwählen.
Zitat von: Xaneu am 02 Mai 2023, 19:26:35Ist im FHEMWEB-device ein Token definiert, wird dies im Webhook mit aufgenommen und bei Bedarf (z.B. bei fhem-Neustart) im Shelly aktualisiert.
Das ist so realisiert, um unabhängig von weiteren Sicherheitseinstellungen zu sein. Wenn also im FHEMWEB-device das Attribut
csfrToken mit einem festen Wert oder random gesetzt ist, holt sich das Shelly-Modul den Token und baut ihn in der auf dem Shelly hinterlegten URL ein. Das sieht dann z.B. so aus (siehe in der Shelly-Webseite unter Settings - Actions):
http://192.168.178.100:8084/fhem?XHR=1&fwcsrf=csrf_445253534353513564&cmd=set%20ShellyTest%20out_on%200Dass auf dem Shelly URLs hinterlegt werden können ist nicht neu, das gibt es auch schon in der ersten Generation. Neu ist, dass die URLs vom Shelly-Modul automatisiert erstellt werden
können. Der Nutzer kann die URL aber auch ändern oder für andere Actions kopieren.
Mit obiger Beispiel-URL wird folgender Befehl an Fhem gesendet:
set ShellyTest out_on 0
Alles klar und danke für die umfangreiche Erklärung.
Gruß
Xaneu
Hier wie angekündigt eine aktuelle Test-Version des Moduls. Neben diversen Korrekturen wird auch der ShellyPro3EM unterstützt. Bitte die angebotenen Attribute durchprobieren!
Im ersten Step habe ich die Version auf mein Testsystem geladen und nach shutdown restart einen Shelly Plug S angelegt (Gen1)
=> Für den Plug funktioniert die Modellerkennung nicht.
=> Welche Bedeutung haben die unten aufgeführten Meldungen?
2023.05.05 13:38:37.510 5: [Shelly_Set] calling for device Plug with command ?, without value
2023.05.05 13:38:40.488 4: [Shelly_Get] receiving command get Plug ?
2023.05.05 13:38:54.744 5: [Shelly_Attr] Plug: called with command set for attribute verbose and value 4
=> dann Model gesetzt
2023.05.05 13:38:54.843 4: [Shelly_Get] receiving command get Plug ? Ablauf- Plug kommt sofort mit "state ok"
- legt die Readings an
2023-05-05 13:33:11 cloud disabled
2023-05-05 13:33:11 firmware v1.10.1
2023-05-05 13:34:11 inttemp 31.21
2023-05-05 13:33:11 network connected to 11.12.13.19
2023-05-05 13:33:11 state OK - nach verbose 5 sieht man im Log: "Model of device Plug is generic and mode is . Updates every 60 seconds"
- nach setzen des korrekten Model kommen die fehlenden Readings
2023-05-05 13:33:11 cloud disabled
2023-05-05 13:44:55 energy 60220
2023-05-05 13:33:11 firmware v1.10.1
2023-05-05 13:44:55 inttemp 30.6
2023-05-05 13:33:11 network connected to 11.12.13.19
2023-05-05 13:44:55 overpower 0
2023-05-05 13:44:55 power 3.32
2023-05-05 13:44:55 relay on
2023-05-05 13:44:55 state on - Statusabfrage für die Messwerte kommen korrekt im Intervall
Denke das sieht gut aus (abgesehen von der Autoerkennung). :)
spielen mit Attributen (viele gelten ja beim Plug nicht)
keine Auswirkung, egal welcher Attributwert gesetzt ist: "attr <name> showunits none|original|normal|normal2|ISO"
Insbesondere rechnet hier das Modul schon aus den Wattminuten des Devices Wattstunden aus. Original sieht man bisher nie. D.h. der Wert oben "energy 60220 " sieht im Device ja so aus "total":3613200"
Kommando zurück, ich hatte das Intervall auf 0 stehen. Funktioniert 8)
-> mehr bleibt beim Plug nicht ;)
Während der Attributtesterei gab es einmal: PERL WARNING: Use of uninitialized value $attrVal in string eq at ./FHEM/36_Shelly.pm line 826.
=> if( $attrVal eq "none" || $cmd eq "del" ){
Zitat von: RalfRog am 05 Mai 2023, 14:10:542023.05.05 13:38:37.510 5: [Shelly_Set] calling for device Plug with command ?, without value
2023.05.05 13:38:40.488 4: [Shelly_Get] receiving command get Plug ?
2023.05.05 13:38:54.744 5: [Shelly_Attr] Plug: called with command set for attribute verbose and value 4
=> dann Model gesetzt
2023.05.05 13:38:54.843 4: [Shelly_Get] receiving command get Plug ?
Meldungen zur Autoerkennung sehen wir da nicht, weil zum Zeitpunkt des Define der Level noch niedriger war. Die Befehle
set <device> ? bzw.
get <device> ? kommen wohl von FHEMWEB und dienen dem Aufbau der Dropdown-Menus. Das war wohl auch schon in der ursprünglichen Fassung so, nur mit dem Unterschied, dass diese dort nicht geloggt wurden.
Zitat von: RalfRog am 05 Mai 2023, 14:10:54Model of device Plug is generic
Als Attribut model wurde also zunächst generic angelegt, richtig? Das ist immer dann der Fall, wenn sich der Shelly mit einer ID "type" meldet, die hier im Modul nicht bekannt ist. Bitte hierzu folgende Anfrage an den Shelly Plug absetzen:
<ip-adresse>/settingsDie Antwort sollte in etwa so aussehen:
device:
type: "SHPLG-S"
..... ......
Zitat von: Starkstrombastler am 05 Mai 2023, 15:54:13Als Attribut model wurde also zunächst generic angelegt, richtig? Das ist immer dann der Fall, wenn sich der Shelly mit einer ID "type" meldet, die hier im Modul nicht bekannt ist. Bitte hierzu folgende Anfrage an den Shelly Plug absetzen: <ip-adresse>/settings
Die Antwort sollte in etwa so aussehen:
device:
type: "SHPLG-S"
..... ......
Ja genau generic wurde angelegt/angenommen (Das Attribut wird nicht angelegt/gesetzt. Auch nicht model = generic).
Ich habe es händisch gesetzt.
Klar das Model ist : SHPLG-S (Ausgabe settings -> {"device":{"type":"SHPLG-S",)
Als nächstes habe ich meinen Shelly 3EM eingebunden. Sieht auch prima aus.
Autoerkennung funktioniert und die Readings sind soweit gleich da.
Auch die in der alten Version fehlenden Reading wie current, energy_returned & pf .
Er kennt ja an sich auch noch die Gesamtleistung total_power.
"device":{"type":"SHEM-3"
"emeters":[
{"power":84.83,"pf":0.50,"current":0.74,"voltage":224.95,"is_valid":true,"total":282410.1,"total_returned":28608.0},
{"power":89.72,"pf":0.71,"current":0.56,"voltage":225.37,"is_valid":true,"total":308194.0,"total_returned":0.0},
{"power": 3.05,"pf":0.06,"current":0.23,"voltage":224.93,"is_valid":true,"total":365555.4,"total_returned":0.0}],
"total_power":177.6Das Modul scheint zusätzlich die Werte zu errechnen:
- apparentpower_x
- reactivepower_x
- energyTTL
- powerTTL
=> oder ist das der Originalwert total_power?
Die Rechenwerte finde ich an sich ok (man braucht manches Usereading nicht), da die ja teilweise in der 2GEN auch vorkommen.
Die Frage (insbesonde an die Mitleser) wäre, ob eine eindeutige Unterscheidung von Gerätewerten und Rechenwerten Sinn macht.
Mehr Geräte hab ich leider nicht.
Ach doch... hab noch nen 1PM in der Schublade.
Wenn noch mehr gute Rückmeldungen kommen kann ich nur sagen: Klasse gemacht ;D Toll! und danke für die Arbeit.
Zitat von: RalfRog am 05 Mai 2023, 16:14:05Ja genau generic wurde angelegt/angenommen (Das Attribut wird nicht angelegt/gesetzt. Auch nicht model = generic).
Ich habe es händisch gesetzt.
Klar das Model ist : SHPLG-S (Ausgabe settings -> {"device":{"type":"SHPLG-S",)
Da müssen wir mal schauen, was ander User berichten. Bei mir funktioniert die Autoerkennung des ShellyPlugS.
Zitat von: RalfRog am 05 Mai 2023, 16:30:23Das Modul scheint zusätzlich die Werte zu errechnen:
- apparentpower_x
- reactivepower_x
- energyTTL
- powerTTL
=> oder ist das der Originalwert total_power?
Ja das stimmt, Werte werden berechnet. Auch PowerTTL wird als Summe der Einzelwerte bestimmt und sollte damit um eine Kommastelle genauer sein.
returnedTTL fehlt noch, wird ergänzt.
Zitat von: Starkstrombastler am 05 Mai 2023, 17:18:05Da müssen wir mal schauen, was ander User berichten. Bei mir funktioniert die Autoerkennung des ShellyPlugS.
Seltsam...
Ich guck mal ob ich mit global verbose 5 beim define was sehen kann.
Hi
wenn du einen Tipp hast bau ich gern ne Zeile "Debug/Log" in den Code. Z.B. zur Ausgabe des rohen Rückgabewertes aus /settings
Ich glaube hier liegt das Problem:
2023.05.05 17:28:16.931 5: [Shelly_Set] calling for device Shelly_Plug with command ?, without value
2023.05.05 17:28:16.937 4: [Shelly_Get] receiving command get Shelly_Plug ?
2023.05.05 17:28:17.080 4: http://10.20.30.90/settings: HTTP response code 200
ok GEN1 ==>> 2023.05.05 17:28:17.084 5: HttpUtils http://11.12.13.19/settings: Got data, length: 1778
2023.05.05 17:28:17.087 5: HttpUtils response header:
HTTP/1.1 200 OK
Server: Mongoose/6.18
Connection: close
Content-Type: application/json
Content-Length: 1778
2023.05.05 17:28:17.091 5: [Shelly_get_model] Shelly_Plug: received 1778 byte of data from device
Nok Antwort ==>> 2023.05.05 17:28:17.098 5: [Shelly_get_model] has invalid JSON data for device Shelly_Plug
2023.05.05 17:28:17.105 5: Starting notify loop for Shelly_Plug, 1 event(s), first is Error
2023.05.05 17:28:17.113 5: End notify loop for Shelly_Plug
2023.05.05 17:28:17.120 4: http://10.20.30.90/rpc/Shelly.GetDeviceInfo: HTTP response code 404
2023.05.05 17:28:17.123 5: HttpUtils http://10.20.30.90/rpc/Shelly.GetDeviceInfo: Got data, length: 9
2023.05.05 17:28:17.127 5: HttpUtils response header:
HTTP/1.1 404 Not Found
Server: Mongoose/6.18
Content-Type: text/plain
Connection: close
Content-Length: 9
Hier die Daten mit dem Browser abgerufen, wird korrekt dargestellt:
{"device":{"type":"SHPLG-S","mac":"3C6105DF2674","hostname":"shellyplug-s-DF2674","num_outputs":1,"num_meters":1},"wifi_ap":{"enabled":false,"ssid":"shellyplug-s-DF2674","key":""},"wifi_sta":{"enabled":true,"ssid":"nochnWLAN","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"wifi_sta1":{"enabled":false,"ssid":null,"ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"ap_roaming":{"enabled":false,"threshold":-70},"mqtt": {"enable":false,"server":"10.20.30.41:1883","user":"","id":"shellyplug-s-DF2674","reconnect_timeout_max":60.000000,"reconnect_timeout_min":2.000000,"clean_session":false,"keep_alive":60,"max_qos":0,"retain":true,"update_period":30},"coiot": {"enabled":true,"update_period":300,"peer":""},"sntp":{"server":"10.20.30.1","enabled":true},"login":{"enabled":false,"unprotected":false,"username":"solar"},"pin_code":"","name":"Solar_Plug","fw":"20210323-105718/v1.10.1-gf276b51","discoverable":false,"build_info":{"build_id":"20210323-105718/v1.10.1-gf276b51","build_timestamp":"2021-03-23T10:57:18Z","build_version":"1.0"},"cloud":{"enabled":false,"connected":false},"timezone":"Europe/Berlin","lat":50.986938,"lng":6.890820,"tzautodetect":false,"tz_utc_offset":7200,"tz_dst":true,"tz_dst_auto":false,"time":"16:39","unixtime":1683301181,"led_status_disable":true,"debug_enable":false,"allow_cross_origin":false,"actions":{"active":false,"names":["btn_on_url","out_on_url","out_off_url"]},"hwinfo":{"hw_revision":"prod-190516","batch_id":1},"max_power":500,"led_status_disable":true,"led_power_disable":true,"relays":[{"name":null,"appliance_type":"General","ison":true,"has_timer":false,"default_state":"on","auto_on":0.00,"auto_off":0.00,"schedule":false,"schedule_rules":[],"max_power":500}],"wifirecovery_reboot_enabled":false}
Zitat von: RalfRog am 05 Mai 2023, 17:42:48..
wenn du einen Tipp hast bau ich gern ne Zeile "Debug/Log" in den Code. Z.B. zur Ausgabe des rohen Rückgabewertes aus /settings
Selbstversuch:
486 $json = JSON->new->utf8;
487 Debug $json;
488 Debug $data;
489 $jhash = eval{ $json->decode( $data ) };
490 Debug $jhash;
491 if( !$jhash ){Ergebnis:
2023.05.05 17:53:00.533 5: [Shelly_get_model] Shelly_Plug: received 1778 byte of data from device
2023.05.05 17:53:00.536 1: DEBUG>JSON=SCALAR(0x37fe2d0)
die Daten: 2023.05.05 17:53:00.540 1: DEBUG>{"device":{"type":"SHPLG-S","mac":"aabbcc112233","hostname":"shellyplug-s-DF2674","num_outputs":1,"num_meters":1},"wifi_ap":{"enabled":false,"ssid":"shellyplug-s-DF2674","key":""},"wifi_sta":{"enabled":true,"ssid":"WLAN","ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"wifi_sta1":{"enabled":false,"ssid":null,"ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"ap_roaming":{"enabled":false,"threshold":-70},"mqtt": {"enable":false,"server":"11.12.13.99:1883","user":"","id":"shellyplug-s-DF2674","reconnect_timeout_max":60.000000,"reconnect_timeout_min":2.000000,"clean_session":false,"keep_alive":60,"max_qos":0,"retain":true,"update_period":30},"coiot": {"enabled":true,"update_period":300,"peer":""},"sntp":{"server":"11.12.13.1","enabled":true},"login":{"enabled":false,"unprotected":false,"username":"user"},"pin_code":"","name":"Solar_Plug","fw":"20210323-105718/v1.10.1-gf276b51","discoverable":false,"build_info":{"build_id":"20210323-105718/v1.10.1-gf276b51","build_timestamp":"2021-03-23T10:57:18Z","build_version":"1.0"},"cloud":{"enabled":false,"connected":false},"timezone":"Europe/Berlin","lat":50.986938,"lng":6.890820,"tzautodetect":false,"tz_utc_offset":7200,"tz_dst":true,"tz_dst_auto":false,"time":"16:53","unixtime":1683301981,"led_status_disable":true,"debug_enable":false,"allow_cross_origin":false,"actions":{"active":false,"names":["btn_on_url","out_on_url","out_off_url"]},"hwinfo":{"hw_revision":"prod-190516","batch_id":1},"max_power":500,"led_status_disable":true,"led_power_disable":true,"relays":[{"name":null,"appliance_type":"General","ison":true,"has_timer":false,"default_state":"on","auto_on":0.00,"auto_off":0.00,"schedule":false,"schedule_rules":[],"max_power":500}],"wifirecovery_reboot_enabled":false}
2023.05.05 17:53:00.546 1: PERL WARNING: Use of uninitialized value $msg in concatenation (.) or string at fhem.pl line 5563.
2023.05.05 17:53:00.549 1: DEBUG>
2023.05.05 17:53:00.552 5: [Shelly_get_model] has invalid JSON data for device Shelly_PlugSieht der Rückgabewert anders aus als bei dir? Unerlaubte sonderzeichen?
Der Rückgabewert sieht doch unauffällig aus.
Wie reagiert eigentlich die offizielle Modul-Fassung?
Zitat von: RalfRog am 05 Mai 2023, 14:10:542023-05-05 13:33:11 firmware v1.10.1
Vielleicht hilft ein Firmware-Update, aktuelle Version für den ShellyPlug ist v1.13.0
Hallo
Habe auf dem Livesystem (da läuft 4.02f) mal nach dem letzten Restart gesucht und tatsächlich:
"Shelly_configure] invalid JSON data"
Das ist mir bisher nicht aufgefallen, da die Readings korrekt gesetzt werden und man da ja noch das Modell setzen musste.
2023.04.29 15:39:37.097 2: Defined real device shelly_3em_haus for 10.20.30.92 as model shelly3em
2023.04.29 15:39:37.102 1: Assigning device shelly_3em_haus SHELLYID 244CAB42CE6B
...
2023.04.29 15:39:38.911 1: [Shelly_configure] invalid JSON data for device shelly_plug_s_df2674
2023.04.29 15:39:39.062 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 5015.
...
2023.04.29 15:39:42.754 2: Defined real device shelly_plug_s_df2674 for 10.20.30.90 as model shellyplug
2023.04.29 15:39:42.756 1: Assigning device shelly_plug_s_df2674 SHELLYID DF2674
Zitat von: Starkstrombastler am 05 Mai 2023, 19:35:18Vielleicht hilft ein Firmware-Update, aktuelle Version für den ShellyPlug ist v1.13.0
Solange alles funktioniert, bin ich bei den Shelly's vorsichtig mit Updates. Im Shelly-Forum werden ja oft recht viele Probleme nach Updates beschrieben. Oder es fallen Funktionen weg/verändert wie beim 3EM von 1.11 nach 1.12 mit der internen Datenspeicherung der Energy.
Vielleicht hast Du eine Idee dem Problem auf die Spur zu kommen. Mein Perl ist da doch sehr rudimentär.
Es scheint sich ja in der Zeile "$jhash = eval{ $json->decode( $data ) };" zu äußern. Wenn es korrekt läuft kommt für $jhash eine Hash-Referenz zurück und im Fehlerfall ist es "Leer" oder "Null".
2023.05.05 17:53:00.536 1: DEBUG>JSON=SCALAR(0x37fe2d0)
2023.05.05 17:53:00.540 1: DEBUG>{"device":{"type":"SHPLG-S", ...
hier wird jetzt Zeile $jhash = eval{ $json->decode( $data ) }; ausgeführt
2023.05.05 17:53:00.546 1: PERL WARNING: Use of uninitialized value $msg in concatenation (.) or string at fhem.pl line 5563.
2023.05.05 17:53:00.549 1: DEBUG>Der 1PM funktioniert übrigens gut :D (
FW 1.10.1, vorhin mal defniert) und liefert:
2023.05.05 18:33:42.341 1: DEBUG>JSON=SCALAR(0x3b7fa90)
2023.05.05 18:33:42.345 1: DEBUG>{"device":{"type":"SHSW-PM","...
hier wird jetzt Zeile $jhash = eval{ $json->decode( $data ) }; ausgeführt
2023.05.05 18:33:42.351 1: DEBUG>HASH(0x3b9d190)
Nochmal meine Debugs im Code:
486 $json = JSON->new->utf8;
487 Debug $json;
488 Debug $data;
489 $jhash = eval{ $json->decode( $data ) };
490 Debug $jhash;
491 if( !$jhash ){
Hallo Starkstrombastler
Bin durch Extra-Debug und -Dumper Zeilen auf etwas gestoßen und habe in Code-Zeile #486 mal testhalber
"$json = JSON->new->utf8->relaxed;" gesetzt.
Damit wird mein Plug S erkannt.
Um das hier nicht zu unübersichtlich zu machen, werde ich einen neuen Beitrag aufmachen.
Stelle dort mal meine Erkenntnisse zusammen - die ich aber leider im Detail nicht richtig einordnen kann.
Gruß Ralf
Edit: "hier kommt der Link auf den neuen Beitrag hin" https://forum.fhem.de/index.php?msg=1274940
Die bisherigen Erkenntnisse aus den Tests von RalfRog sind in dieser neuen Fassung berücksichtigt:
Für die Problematik der Autoerkennung ist das Logging etwas ausführlicher, die Diskussion dazu aber bitte im separaten Thread (s.o.) führen.
Rückmeldungen wie immer gerne gesehen, da ich aber die nächsten Tage auf Reisen bin, muss ich entsprechend um etwas Geduld bitten.
Hallo habe die Version 4.04e installiert und meine drei Shelly's installiert
Plug S
1PM
3EM
Alles schick!
2023.05.06 18:27:02.097 1: [Shelly_get_model] standard decoding: has invalid JSON data for device Shelly_Plug
2023.05.06 18:27:02.102 1: [Shelly_get_model] decoded JSON with relaxed decoding for device Shelly_Plug
2023.05.06 18:27:02.105 1: [Shelly_get_model] discovered model=shellyplug for device Shelly_Plug
2023.05.06 18:28:07.062 1: [Shelly_get_model] discovered model=shelly1pm for device S1PM
2023.05.06 18:28:40.513 1: [Shelly_get_model] discovered model=shelly3em for device S3EM
Wunsch:
Rename von "returnedTTL" zu "energy_returnedTTL", dann steht es beisammen und ist leichter zu efassen.
Auch der Test vom Plug S & EM in Verbindung mit dem ShellyMonitor sieht gut aus.
Die Reading die dort hinterlegt sind (fest codiert) werden per CoIot aktualisiert.
Hallo Starkstrombastler,
'habe nun die letzte Testversion ,,4.04e" auf meinen kleinen Shelly-Mini-Zoo losgelassen:
Shelly Plus 1
Shelly 2.5
Shelly Plug S
Shelly Plus 2PM
(Shelly Plus i4)
Der Fehler, dass das beim Shelly Plus 2PM gesetzte Attribute ,,showunits original", direkt auf alle Shelly-Geräte wirkte, ist behoben.
Alle angeschlossenene Shelly-Geräte bis auf den Shelly Plus i4 laufen einwandfrei. Allerdings hatten meine Tests nicht den Tiefgang wie die von RalfRog.
Da es keine Auffälligkeiten gab, habe ich nun die Testversion ,,4.04e" direkt auf meinem System belassen.
Zum Shelly Plus i4:
Beim Stöbern im Quelltext hatte ich entdeckt, dass auch der Shelly Plus i4, den ich bisher über MQTT auslese, unterstützt wird.
Ich hätte das nun gerne getestet, mit dem Ziel dann alle Shelly-Geräte über das Modul "36_Shelly.pm" betreiben zu können.
Leider konnte ich, nach dem Deaktivieren des MQTT-Protokolls über die Shelly-Weboberfläche und anschließendem Reboot, auf den Shelly Plus i4 nicht mehr zugreifen.
Auch ließ sich das Geräte nicht mehr auf Werkseinstellung zurücksetzten (Shelly stromlos schalten und wieder einschalten und dann innerhlab einer Minute 5x einen Eingang betätigen).
Xaneu
Ich biete mich auch gerne zum Testen an. Habe mir folgendes geholt:
Shelly Plus 2PM (Doppelsteckdose)
Shelly Plus 1PM (Steckdose)
Shelly Plus Plug S (einzelne Geräte)
am Wochenende sollen noch folgen:
Shelly Plus 2PM (Doppellichtschalter)
Shelly Plus 1PM (Einzellichtschalter)
Shelly Plus i4 (Szenenauswahl)
Gruß .. Max
Hallo, bei mir wird nach einem Neustart jedes Shelly device als Model "Generic" erkannt.
Dies hat zur folge das es nicht immer richtig funktioniert (Shelly Bulp), gehen dann die Farben nicht usw.
Stelle ich das Modell dann manuell richtig ein, klappt alles. Nun werden die einstellungen nach einem Neustart wieder zurück auf "generic" gesetzt
ist da irgendwie ab zu schalten?
Zitat von: THZ_Haus am 12 Mai 2023, 22:21:03Stelle ich das Modell dann manuell richtig ein, klappt alles. Nun werden die einstellungen nach einem Neustart wieder zurück auf "generic" gesetzt
ist da irgendwie ab zu schalten?
Neustart des/der Shelly's oder FHEM?
Im Falle FHEM: hast du vielleicht vergessen "save config" zu machen?
Moin,
habe jetzt nochmal getestet, wenn ich von "generic" auf "shellybulb" umstelle, wird dies nicht gespeichert.
Die anderen Shellys sind okay!
MfG
Ich habe zwar keine ShellyBulb.
Aber umgekehrt habe ich einfach mal den ShellyPlugS auf "shellybulb" eingestellt die Config gespeichert und ein "shutdown restart" durchgeführt.
Das Attribut geht dann tatsächlich wieder auf "model=shellyplug". Vermutlich liegt das an der Art wie Starkstrombastler die Deviceerkennung umgesetzt hat und daher die nicht erkannte "shellybulb" wieder auf "generic" geht.
@Starkstrombastler:
Im log ist nach dem Restart und vorheriger Definition meines Plug als shellybulb:
2023.05.13 09:05:04.846 1: [Shelly_get_model] standard decoding: has invalid JSON data for device Shelly_Plug
2023.05.13 09:05:04.851 1: [Shelly_get_model] decoded JSON with relaxed decoding for device Shelly_Plug
2023.05.13 09:05:04.852 1: [Shelly_get_model] discovered model=shellyplug for device Shelly_Plug
2023.05.13 09:07:52.739 2: Defined real device Shelly_Plug for 11.12.13.19 as model shellyplug
2023.05.13 09:07:52.742 1: Assigning device Shelly_Plug SHELLYID DF2674
ich habe einen neuen Shelly Uni.
Die Temperatur wird in den Readings angezeigt.
Die gemessene Spannung vom ADC und der Status der Sensor-Eingänge fehlen aber.
Zitat von: THZ_Haus am 12 Mai 2023, 22:21:03Hallo, bei mir wird nach einem Neustart jedes Shelly device als Model "Generic" erkannt.
Als "generic" werden die Shellies angelegt, wenn sie
a) eine unbekannte Type sind
b) nicht vom Shelly-Modul unterstützt werden (z.B. Batterie-Geräte oder TRV)
c) die Kommunikation fehlerhaft ist (z.B. wg. alter Firmware).
zu a) wie lautet denn bei den auffälligen Shellies das Internal 'SHELLY' ? Falls das nicht vorhanden ist, bitte über den Browser folgende Anfrage absetzen: <ip-adresse_des_Shelly>/settings
Die Antwort des Shelly unter
device:type: hier posten (z.B.
"SHBLB-1").
Zitat von: Xaneu am 08 Mai 2023, 23:08:22Beim Stöbern im Quelltext hatte ich entdeckt, dass auch der Shelly Plus i4, den ich bisher über MQTT auslese, unterstützt wird.
Der Shelly i4 wird derzeit nicht wirklich unterstützt. Er wird als Model=generic angelegt, was aber bei den Geräten der 2. Generation nichts bringt, weil diese nicht vom Shelly-Monitor unterstützt werden. Die Unterstützung vom Shelly-Modul ist aber in Arbeit.
Ist die Kommunikation mit dem i4 inzwischen wieder hergestellt?
Zitat von: mkriegl am 11 Mai 2023, 17:10:01Shelly Plus 2PM (Doppelsteckdose)
Shelly Plus 1PM (Steckdose)
Shelly Plus Plug S (einzelne Geräte)
am Wochenende sollen noch folgen:
Shelly Plus 2PM (Doppellichtschalter)
Shelly Plus 1PM (Einzellichtschalter)
Shelly Plus i4 (Szenenauswahl)
Da die Shelly Plus 2PM in meiner Testumgebung vorhanden sind, sollten diese auf Anhieb funktionieren, auch mit automatisch angelegten Webhooks.
Shelly Plus 1PM auch, aber der ist bisher nicht getestet.
Zum i4 siehe Posting oben, Thema ist in Arbeit.
Zitat von: RalfRog am 06 Mai 2023, 18:43:14Rename von "returnedTTL" zu "energy_returnedTTL", dann steht es beisammen und ist leichter zu efassen.
--> nächste Modulversion.
Aber:
In der FHEM-Welt gibt es ja bereits diverse Zähler. Kennt jemand einen Ansatz für FHEM-einheitliche Leistungs- und Energie-Readings? Immerhin steht das EM in FHEM ja für Energie-Monitoring.
Auch der ShellyPro3EM wird vom Modul unterstützt. Hat das bereits jemand ausprobiert und die verschiedenen Attribute getestet?
Zitat von: Lichti am 13 Mai 2023, 10:40:47ich habe einen neuen Shelly Uni.
Die Temperatur wird in den Readings angezeigt.
Die gemessene Spannung vom ADC und der Status der Sensor-Eingänge fehlen aber.
Die Spannung sollte mit der letzten Modulfassung vom 6. Mai ausgewertet werden. Welche Readings fehlen denn genau? Bitte das Ergebnis von
<ip-adresse_des_Shelly>/status hier posten.
Zitat von: RalfRog am 13 Mai 2023, 09:35:48@Starkstrombastler:
Im log ist nach dem Restart und vorheriger Definition meines Plug als shellybulb:
2023.05.13 09:05:04.846 1: [Shelly_get_model] standard decoding: has invalid JSON data for device Shelly_Plug
2023.05.13 09:05:04.851 1: [Shelly_get_model] decoded JSON with relaxed decoding for device Shelly_Plug
2023.05.13 09:05:04.852 1: [Shelly_get_model] discovered model=shellyplug for device Shelly_Plug
2023.05.13 09:07:52.739 2: Defined real device Shelly_Plug for 11.12.13.19 as model shellyplug
2023.05.13 09:07:52.742 1: Assigning device Shelly_Plug SHELLYID DF2674
Ist das Verhalten des Moduls ein falsch gesetztes Model auch nachträglich zu korrigieren korrekt?
Beim Uni fehlen (Version vom 6.Mai):
Spannung vom ADC
Status vom Input 1
Status vom Input 2
Hier der Status vom Uni:
wifi_sta
connected true
ssid "FDW30"
ip "192.168.178.60"
rssi -52
cloud
enabled true
connected true
mqtt
connected false
time "18:01"
unixtime 1683993665
serial 167
has_update false
mac "C45BBE6C639D"
cfg_changed_cnt 0
actions_stats
skipped 0
relays
0
ison false
has_timer false
timer_started 0
timer_duration 0
timer_remaining 0
source "http"
1
ison false
has_timer false
timer_started 0
timer_duration 0
timer_remaining 0
source "http"
inputs
0
input 0
event ""
event_cnt 1
1
input 0
event ""
event_cnt 1
adcs
0
voltage 0
ext_sensors
temperature_unit "C"
ext_temperature
0
hwID "28146495f0ff3ce6"
tC 23.88
tF 74.97
ext_humidity {}
update
status "idle"
has_update false
new_version "20230503-102354/v1.13.0-g9aed950"
old_version "20230503-102354/v1.13.0-g9aed950"
ram_total 50776
ram_free 36832
fs_size 233681
fs_free 141815
uptime 26229
Zitat von: Starkstrombastler am 13 Mai 2023, 16:10:13Zitat von: RalfRog am 06 Mai 2023, 18:43:14Rename von "returnedTTL" zu "energy_returnedTTL", dann steht es beisammen und ist leichter zu efassen.
--> nächste Modulversion.
Aber:
In der FHEM-Welt gibt es ja bereits diverse Zähler. Kennt jemand einen Ansatz für FHEM-einheitliche Leistungs- und Energie-Readings? Immerhin steht das EM in FHEM ja für Energie-Monitoring.
Auch der ShellyPro3EM wird vom Modul unterstützt. Hat das bereits jemand ausprobiert und die verschiedenen Attribute getestet?
Hallo Starkstrombastler
Im Zusammenhang mit dem Shelly_Monitor (von gvzdus) gibt es auch noch eine Unsauberkeit, deren Verursacher vermutlich ich bin.
Zum Jahreswechsel hatte ich gvzdus kontaktiert (https://forum.fhem.de/index.php?msg=1253662) und er hat den Shelly 3EM ergänzt und die Maßeinheit Wh/Wm für Energie korrigiert.
Auf meinen Vorschlag hin hat er noch das Readings ""energyReturned" nachgepflegt. Aus jetziger Sicht ist die Namensgebung sicher unglücklich (ich hatte mir damals keine tieferen Gedanken gemacht).
Besteht die Möglichkeit einer Abstimmung um das praktikabel (auch im Hinblick auf Gen2 Namensgebung) hinzubekommen?
Gruß Ralf
Zitatzu a) wie lautet denn bei den auffälligen Shellies das Internal 'SHELLY' ? Falls das nicht vorhanden ist, bitte über den Browser folgende Anfrage absetzen: <ip-adresse_des_Shelly>/settings
Die Antwort des Shelly unter device:type: hier posten (z.B. "SHBLB-1").
Habs gerade geprüft, Auszug:
device
type "SHBDUO-1"
Dann ist das Umstellen auf "shellybulp" auch falsch, und der Typ SHBDUO-1 wird noch nicht unterstützt?
Zitat von: RalfRog am 13 Mai 2023, 16:33:32Ist das Verhalten des Moduls ein falsch gesetztes Model auch nachträglich zu korrigieren korrekt?
An sich schon, weil es für jede Shelly-Hardware eben nur ein Model gibt, was diese Hardware abbildet. Mit Einführung der Autoerkennung wäre es vielleicht am besten, ganz auf das Attribut 'model' zu verzichten. Außer man möchte, dass ein Gerät als 'generic' dargestellt wird. Ein weiterer Grund für das Attribut wäre eine nicht erfolgreiche Autoerkennung.
Und so ist die Autoerkennung auch umgesetzt: bei erfolgreicher Autoerkennung wird eben nur das erkannte model und 'generic' als Auswahl für das Attribut 'model' zugelassen. Außerdem werden alle (na ja: die meisten) nicht relevanten Attribute herausgenommen. Bei nicht erfolgreicher Autoerkennung werden alle model und 'generic' angeboten.
Allerdings besteht derzeit noch ein Problem, dass sich die Autoerkennung bei Neustart nicht genau so wie gerade beschrieben verhält.
Bei mir ist das aktuell kein Problem, da das Modul ja meine bescheidenen drei kennt.
Ich denke mal laut.
Wenn das Modul einen (neuen) Typ nicht kennt ist das Modell generic zwar ok aber vielleicht passt ein anderes Modell besser, dass manuell gesetzt wird.
Wie wäre die Vorgehensweise
- kein Modell gesetzt -> Autoerkennung, ggfs. generic
- generic gesetzt -> Autoerkennung weil möglicherweise Verbesserungen
- spezifisches Modell gesetzt, per Autoerkennung nicht mehr überschreiben
Eine interessante Option wäre den Input als Reading darzustellen (SW Eingang gibts ja an vielen Shelly's).
Man kann den SW vom Relay "detach'en" und damit als Sensor (z.B. auf/zu) nutzen.
(Ich versuche das gerade mit dem Shelly1 am Garagentor umzusetzen und greife erstmal auf JSONMOD zurück)
Edit:
Hat sich wohl erledigt.
Auch bei Gen1 (zumindest am Shelly1) kann das Attribut "showinputs" auf "show" gesetzt werden und dann erscheint das Reading "button".
Die Funktion ist also schon da ;)
Gruß Ralf
Zitat von: Starkstrombastler am 13 Mai 2023, 15:58:02Da die Shelly Plus 2PM in meiner Testumgebung vorhanden sind, sollten diese auf Anhieb funktionieren, auch mit automatisch angelegten Webhooks.
Shelly Plus 1PM auch, aber der ist bisher nicht getestet.
Zum i4 siehe Posting oben, Thema ist in Arbeit.
Hätte ich weiter oben gelesen, dann hätte ich auch die aktuelle Version gesehen ;D .. danke schon mal dafür. Was mir aufgefallen ist:
- bei Statistics wandert "state" mit in Statistiken ein. Macht aber eher keinen Sinn
- meine Shelly Plus Plug S werden erkannt, werfen dann aber meist "Error" oder "Model shellypluspug identified" aus. Daten werden nicht aktualisiert - nur vielleicht mal bei einem Neustart von fhem - attr wurde aber beim definieren korrekt erkannt
Wenn ich für den PlusPlugS Daten liefern soll, kann ich das gerne machen. Danke schon mal für die Arbeit am Modul
Gruß .. Max
Hallo Testergemeinde,
es stehen ja noch einige Rückmeldungen zum i4, Uni, Duo-Bulb und PlusPlugS aus. Ich habe mir jetzt diese Shellies bestellt, denn rein theoretisch ist es schwer bis unmöglich die Shellies korrekt abzubilden (zumindest für mich). Mit einer echten Testumgebung mit Schaltern und Lasten sieht das ganz anders aus. Und für irgendetwas werden die Teile dann auch gut sein.
Also wenn die Teile nächste Woche ankommen werde ich mich erstmal darum kümmern.
Wir können dann auch die Diskussion zur Gestaltung der Readings bei den diversen EnergyMetern führen, aber in den nächsten Tagen stehen erstmal andere Dinge an. Vielleicht findet ja jemand bis dahin eine brauchbare Grundlage bei anderen Modulen zu EnergyMetern.
Gruß
Bernhard
Hallo.
@Starkstrombastler Ich freue mich auch sehr darüber das Du Dir die Arbeit machst und das Modul von PAH weiterentwickelst und pflegst. Danke!
Momentan nutze ich noch die offizielle Version 4.01 des Moduls.
Da ich bisher nur gen1 Shellys habe sollten die auch mit Deiner Weiterentwicklung soweit ich gelesen habe problemlos laufen.
Es liegen aber schon einige Zeit zwei Shelly Plus 1PM bei mir rum die ich gerne einsetzen würde.
Wie sollte ich eine Migration durchführen? Einfach das Modul ersetzten und ein restart von Fhem?
Oder müssen /sollten die bereits definierten Geräte neu angelegt werden?
Wichtig ist natürlich auch, wie kann ich im Bedarfsfall zurückgehen?
Gruß
Daniel
Zitat von: Starkstrombastler am 17 Mai 2023, 23:29:13...
Wir können dann auch die Diskussion zur Gestaltung der Readings bei den diversen EnergyMetern führen, aber in den nächsten Tagen stehen erstmal andere Dinge an. Vielleicht findet ja jemand bis dahin eine brauchbare Grundlage bei anderen Modulen zu EnergyMetern.
...
Bestimmt sinnvoll. Hoffe es können viele zum Stand der diversen EnergyMeter beitragen. Ich hab nur die Shellies und eine HM-Steckdose.
Ich fasse nach meinem Urlaub mal meinen Ist-Stand zusammen.
Gruß Ralf
Zitat von: WhyTea am 19 Mai 2023, 09:32:14Wie sollte ich eine Migration durchführen? Einfach das Modul ersetzten und ein restart von Fhem?
Oder müssen /sollten die bereits definierten Geräte neu angelegt werden?
Wichtig ist natürlich auch, wie kann ich im Bedarfsfall zurückgehen?
Sofern man über eine eigene Testumgebung verfügt, sollte man "in Entwicklung befindliche Module" ersteinmal dort ausprobieren. Ansonsten ist grundsätzlich eine vorherige Sicherung/Backup sinnvoll.
Es reicht, das Modul im Moduleordner abzulegen und einen Restart von Fhem durchzuführen. Damit die Testversion bei einem Update nicht von der offiziellen Version überschrieben wird, muss das Attribut
attr global exclude_from_update 36_Shelly.pm gesetzt bzw. erweitert werden.
Für das Zurückgehen muss die Testversion wieder durch die letzte offizielle Version ersetzt werden (z.B. mittel "update") und Fhem neu gestartet werden. Eventuell von der Testversion neu angelegte Readings (und ggf. in den Shellies abgelegte Actions) müssen manuell entfernt werden.
Bei der Einbindung von Testversionen in eine vorhandene Fhem-Umgebung bitte immer beachten, dass sich Readings, Attribute oder auch die grundsätzliche Funktionalität ändern können!
Vielen Danke für die ausführliche Antwort!
So wie ich das sehe ist dies hier die aktuelle Version, richtig?
Zitat von: Starkstrombastler am 06 Mai 2023, 12:11:42Die bisherigen Erkenntnisse aus den Tests von RalfRog sind in dieser neuen Fassung berücksichtigt: [url="https://forum.fhem.de/index.php?action=dlattach;attach=171122;type=preview;file"]36_Shelly.pm[/url]
Für die Problematik der Autoerkennung ist das Logging etwas ausführlicher, die Diskussion dazu aber bitte im separaten Thread (s.o.) führen.
Rückmeldungen wie immer gerne gesehen, da ich aber die nächsten Tage auf Reisen bin, muss ich entsprechend um etwas Geduld bitten.
Kann ich die nur hier im Forum laden oder liegt die auch irgendwo in einem Git oder ähnlichen, sodass ich sie direkt laden könnte?
Gruß
Daniel
Zitat von: WhyTea am 22 Mai 2023, 12:35:42So wie ich das sehe ist dies hier die aktuelle Version, richtig?
Richtig, letzte Version ist vom 6. Mai. Und die gibt es auch nur hier im Forum.
Moin
Ich habe jetzt auf die Version vom 6.Mai umgestellt und einen Restart durchgeführt.
Verändert hat sich soweit nichts. Meine Shellys (1PM und Plugs) sind erreichbar und regieren.
Die Geräteerkennung hat scheinbar nicht funktioniert. :-/
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device EG_WZ_Terrassenlicht
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device EG_WZ_Terrassenlicht
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device KG_BZ_Waschmaschine
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device KG_BZ_Waschmaschine
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device KG_BZ_Trockner
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device KG_BZ_Trockner
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device KG_BZ_Trockner
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device KG_BZ_Trockner
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device EG_WZ_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device EG_WZ_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device KG_GZ_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device KG_GZ_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device OG1_SZ_Steckdose
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device OG1_SZ_Steckdose
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device OG2_KZ_Klima_shelly1pm
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device OG2_KZ_Klima_shelly1pm
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device EG_WZ_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device EG_WZ_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device KG_GZ_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device KG_GZ_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device KG_TK_Serverschrank
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device KG_TK_Serverschrank
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device KG_TK_Serverschrank
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device KG_TK_Serverschrank
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device KG_BZ_Waschmaschine
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device KG_BZ_Waschmaschine
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device EG_WZ_Terrassenlicht
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device EG_WZ_Terrassenlicht
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device EG_Eingang_Steckdose
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device EG_Eingang_Steckdose
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device GA_Huette_shelly1pm
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device GA_Huette_shelly1pm
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device GA_Huette_shelly1pm
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device GA_Huette_shelly1pm
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device EG_Eingang_Steckdose
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device EG_Eingang_Steckdose
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device OG1_SZ_Klima_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device OG1_SZ_Klima_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device OG1_SZ_Klima_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device OG1_SZ_Klima_shellyplugs
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device OG1_SZ_Steckdose
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device OG1_SZ_Steckdose
2023.05.25 08:42:30 1: [Shelly_get_model] standard decoding: has invalid JSON data for device OG2_KZ_Klima_shelly1pm
2023.05.25 08:42:30 1: [Shelly_get_model] relaxed decoding: has invalid JSON data for device OG2_KZ_Klima_shelly1pm
Woran könnte das liegen?
Gruß
Daniel
Zitat von: WhyTea am 25 Mai 2023, 09:24:40Die Geräteerkennung hat scheinbar nicht funktioniert.
Hallo WhyTea,
die Autoerkennug probiert den Shelly sowohl als Gen1 als auch als Gen2 anzusprechen. Damit wird also auch mindestens eine negative Antwort vom Shelly zurückgegeben.
Wie lautet die Antwort des Shelly auf folgende Anfrage (im Browser):
http://ip-des-Shelly/infoAußerdem bitte noch prüfen:
Wenn die Autoerkennung funktioniert wird eine Zeile der Art
[Shelly_get_model] discovered model=shelly1pm for device ....in das Logfile geschrieben und es wird ein Internal "SHELLY" angelegt, ist dies vorhanden?
Zitat von: Starkstrombastler am 25 Mai 2023, 14:23:20Hallo WhyTea,
die Autoerkennug probiert den Shelly sowohl als Gen1 als auch als Gen2 anzusprechen. Damit wird also auch mindestens eine negative Antwort vom Shelly zurückgegeben.
Das ist soweit nachvollziehbar aber ich habe hier halt immer zwei nagative wie du siehst.
Zitat von: Starkstrombastler am 25 Mai 2023, 14:23:20Wie lautet die Antwort des Shelly auf folgende Anfrage (im Browser):
http://ip-des-Shelly/info
Antwort ist eine weisse Webseite auf der nur "Not Found" steht.
Meinst Du vielleicht http://ip-des-Shelly/status oder http://ip-des-Shelly/shelly?
Da bekomme ich Antworten.
Zitat von: Starkstrombastler am 25 Mai 2023, 14:23:20Außerdem bitte noch prüfen:
Wenn die Autoerkennung funktioniert wird eine Zeile der Art
[Shelly_get_model] discovered model=shelly1pm for device ....in das Logfile geschrieben und es wird ein Internal "SHELLY" angelegt, ist dies vorhanden?
Solche Zeilen wurden nicht geloggt.
Ein Internal Shelly wurde ebenfalls nicht angelegt.
Gruß
Daniel
Hallo Starkstrombastler
Meinst du eventuell den Endpoint IP/shelly, den es bei Gen1 und Gen2 gibt und ebenfalls Auskunft über das Modell?
Gruß Ralf
Es gibt ja auch die Möglichkeit die Shellys per MQTT abzufragen und zu steuern.
Kann mir jemand sagen wo die Vor- bzw. Nachteile der beiden Systeme sind?
Das Shelly Modul ist von der Anwendung her einfacher als MQTT (https://wiki.fhem.de/wiki/MQTT) und eignet sich daher insbesondere für FHEM-Einsteiger. Die Anbindung via MQTT ist von Vorteil, wenn Aktualität der Statusmeldungen wichtig ist, da bei dem Shelly-Modul mit kurzen Polling-Intervallen die Systemlast steigt. Letzteres ist insbesonders bei sehr großen Installationen (mehrere Hundert Devices) von Bedeutung.
Bei Shellies der ersten Generation wird auch durch die Verwendung des Shelly-Monitors (siehe Commandref) eine hohe Aktualität erreicht. Allerdings ist die aktuell hier diskutierte Testversion des Shelly-Moduls noch nicht vollständig kompatibel zum Shelly-Monitor.
Zitat von: mkriegl am 11 Mai 2023, 17:10:01Ich biete mich auch gerne zum Testen an. Habe mir folgendes geholt:
Shelly Plus 2PM (Doppelsteckdose)
Shelly Plus 1PM (Steckdose)
Shelly Plus Plug S (einzelne Geräte)
am Wochenende sollen noch folgen:
Shelly Plus 2PM (Doppellichtschalter)
Shelly Plus 1PM (Einzellichtschalter)
Shelly Plus i4 (Szenenauswahl)
Gruß .. Max
Hey Max,
hast Du Deine SHELLY
PLUS PLUG S schon eingebunden ??
Das hab ich leider nicht hingekriegt.
Der SHELLY PLUG S ist kein Problem: funzt supi. Aber für den SHELLY
PLUS PLUG S gabs irgendwie nix.
Wenn ja, kannst Du mir ein Schritt für Schritt - Setup schicken ? Bin leider Laie und brauche es daher bissi ausführlicher ;D
LG
Christian
Zitat von: SmartHomeHeni am 02 Juni 2023, 09:44:01...
hast Du Deine SHELLY PLUS PLUG S schon eingebunden ??
Das hab ich leider nicht hingekriegt.
Der SHELLY PLUG S ist kein Problem: funzt supi. Aber für den SHELLY PLUS PLUG S gabs irgendwie nix.
...
Welche Modulversion verwendest du denn? Die "offizielle" die es per Update gibt (von letztem Jahr? version = "4.01")
Versuch doch einfach mal hier die Testversion der "Entwicklung" (https://forum.fhem.de/index.php?msg=1274963).
Zitat von: Starkstrombastler am 22 Mai 2023, 17:51:36Zitat von: WhyTea am 22 Mai 2023, 12:35:42So wie ich das sehe ist dies hier die aktuelle Version, richtig?
Richtig, letzte Version ist vom 6. Mai. Und die gibt es auch nur hier im Forum.
Zitat von: WhyTea am 25 Mai 2023, 15:41:07Meinst Du vielleicht http://ip-des-Shelly/status oder http://ip-des-Shelly/shelly?
Da bekomme ich Antworten.
Nur als Info, weiß nicht ob das hier schon irgendwo steht:
Ein Shelly 1pm plus wird so abgefragt
http://<IP>/rpc/Shelly.GetStatusAktuell habe ich kein reading "energy" im Shelly 1pm plus.
Da wurde wohl die Schreibweise intern verändert.
Hallo Loctite,
Zitat von: Loctite am 02 Juni 2023, 18:27:20Aktuell habe ich kein reading "energy" im Shelly 1pm plus.
Da wurde wohl die Schreibweise intern verändert.
bezieht sich diese Angabe auf
a) die Ausgabe des Shelly oder
b) auf das Shelly-Modul?
zu a) die Angabe findet sich hier unter "aenergy", wobei das "a" für "active" steht. Damit ist Active-Energy, also Wirkenergie, gemeint.
zu b) im Shelly-Modul lautet das reading unverändert "energy".
Welche Modulversion?
Wie lautet das Internal "SHELLY"?
Wie lautet das Anttribut "model"?
Zitat von: Starkstrombastler am 03 Juni 2023, 11:36:30Hallo Loctite,
Welche Modulversion?
Wie lautet das Internal "SHELLY"?
Wie lautet das Anttribut "model"?
Version ist die letzte die über das FHEM Update verfügbar ist 4.01
Ich habe einen Beitrag gefunden der besagt, das man in der 36_Shelly.pm aus dem "energy" ein "aenergy" machen soll, dann würde es gehen (Zeile 14xx) muss ich nachschauen.
Das habe ich gemacht und hatte danach direkt das reading energy.
Modell wurde "shellyplus1pm" angegeben.
Was mit Internal "SHELLY" gemeint ist weiß ich nicht.
Zitat von: Loctite am 03 Juni 2023, 22:50:59Version ist die letzte die über das FHEM Update verfügbar ist 4.01
Shellies der zweiten Generation (Plus- und Pro-Varianten) werden vom Modul im FHEM-Update (V. 4.01) nur rudimentär unterstützt. Abhilfe schafft die Weiterentwicklung des Moduls, welche sich derzeit noch im Teststadium befindet.
Die derzeit letzte Testversion kann hier (https://forum.fhem.de/index.php?action=dlattach;attach=171122) heruntergeladen werden.
Der ShellyPlus1PM sollte unterstützt werden, allerdings liegen dazu noch keine Testergebnisse vor. Ich möchte dazu einladen dies zu testen. Allerdings, wie bei allen Entwicklungen, mit entsprechender Vorsicht (am besten auf einem Testsystem).
Zitat von: Loctite am 03 Juni 2023, 22:50:59Was mit Internal "SHELLY" gemeint ist weiß ich nicht.
Das Internal "SHELLY" gibt es in der Modulversion 4.01 noch nicht.
Hallo Starkstrombastler
Eine interesannte Ergänzung für die Shellies mit Relay wäre die Auswertung des SW-Eingangs.
Der "Button Type" kann mit "detach" zur unabhägigen Auswertung konfiguriert werden (0= offen, 1= geschlossen auf L(-) oder N(+)).
Als Beispiel in einem Shelly1 (1PM) -Gen1- kommt die Info im Status als Inputs mit
"wifi_sta":{"connected":true,"ssid":"WLAN","ip":"11.12.13.19","rssi":-78},
"cloud":{"enabled":false,"connected":false},
"mqtt":{"connected":false},
"time":"14:39",
"unixtime":1685968799,
"serial":14,
"has_update":false,
"mac":"1234567890AB",
"cfg_changed_cnt":0,
"actions_stats":{"skipped":0},
"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"source":"http"}],
"meters":[{"power":0.00,"is_valid":true}],
"inputs":[{"input":1,"event":"","event_cnt":2}],
"ext_sensors":{},
"ext_temperature":{},
"ext_humidity":{},
"update":{"status":"unknown","has_update":false,"new_version":"","old_version":"20230503-095514/v1.13.0-g9aed950"},
"ram_total":51688,
"ram_free":39860,
"fs_size":233681,
"fs_free":150851,
"uptime":11983
Habe mir mal testhalber und recht unorthodox (mein Perl ist auch eher schlecht...) das Reading mit einer Zeile 1908 in den Code für das BulkUpdate gequetscht:
1896 #############################################################################################################################
1897 #-- 1st generation: we have a switch type device and 'relay'-mode, e.g. shelly1, shelly1pm, shelly4, shelly2, shelly2.5, shellyplug or shellyem
1898 if( $shelly_models{$model}[0]>0 && $mode ne "roller" ){
1899
1900 my $metern = ($model =~ /shelly.?em/)?"emeters":"meters";
1901
1902 for( my $i=0;$i<$channels;$i++){
1903 $subs = ($channels == 1) ? "" : "_".$i;
1904 $ison = $jhash->{'relays'}[$i]{'ison'};
1905 $ison =~ s/0|(false)/off/;
1906 $ison =~ s/1|(true)/on/;
1907 readingsBulkUpdateIfChanged($hash,"relay".$subs,$ison);
1908 readingsBulkUpdateIfChanged($hash,"input".$subs,$jhash->{'inputs'}[$i]{'input'}); #Ralf fuer Input
Ergebnis für Shelly1
input 1 2023-06-05 15:41:48
network connected to 11.12.13.19 2023-06-06 14:20:22
power 0 2023-06-05 15:38:08
relay off 2023-06-05 15:40:47
state off 2023-06-06 14:20:22
Gruß Ralf
P.S. Habe gvzdus mal wegen der Möglichkeiten im Monitor angetriggert.
Hallo RalfRog
Zitat von: RalfRog am 06 Juni 2023, 14:29:54Eine interesannte Ergänzung für die Shellies mit Relay wäre die Auswertung des SW-Eingangs.
da bin ich auch schon drauf gekommen und habe das etwas versteckt eingebaut:
attr <dev> showinputs showDas Einlesen auf diese Weise macht nur dann Sinn, wenn die Signale lange genug am Eingang anstehen. Kurzzeitige Signale wird man kaum beim Polling erwischen. Um also Fehlinterpretationen zu vermeiden, habe ich hier die Möglichkeit zum Verbergen vorgesehen.
Anders sieht es aus, wenn der Shelly bei einem Eingangssignal mittels Aktion/Webhook eine Nachricht an Fhem sendet und dies vom Shelly-Modul ausgewertet wird. Das ist dann fast Echtzeit.
In der letzten Testversion sollte dies zumindest in Grundzügen vorhanden sein. Mit der nächsten Testversion dann auf jeden Fall verbessert.
Ah super schau ich mir an ;D
Bei mir ist es ein Reedkontakt am Garagentor - daher keine kurzen Pulse.
Das Echtzeitproblem bei Gen1 könnte der Shelly-Monitor auffangen. Ist natürlich keine "langfristige" Lösung. Gen2 ist die Zukunft.
Die Actions muss ich mir anschauen. Ich glaube da war dann noch das Thema der CSRF-token.
Sieht ja ganz gut aus (Gen1: Shelly1 & Shelly1PM) :D
button on 2023-06-07 08:51:22
event_cnt 1 2023-06-07 08:51:22
overpower - 2023-06-07 08:50:41
power 0 2023-06-07 08:50:41
relay on 2023-06-07 08:55:16
state off 2023-06-07 08:50:41
cloud disabled 2023-06-07 08:50:41
firmware v1.13.0 2023-06-07 08:50:41
network connected to 10.20.30.93 2023-06-07 08:50:41
Je nach dem auf was reagiert werden soll ist der "event_cnt" auch sinnvoll.
Der ShellyMonitor kann die beiden Readings leider nicht aktualisieren. Ob an der Namensgebung liegt?
Mir fehlt da etwas der Durchblick wie das Zusammenspiel der beiden Module genau aussieht.
Jetzt muss ich mir mal anschauen wie das mit den Actions/Webhooks Richtung FHEM funktioniert ???
Gruß Ralf
Zitat von: RalfRog am 07 Juni 2023, 09:58:21Je nach dem auf was reagiert werden soll ist der "event_cnt" auch sinnvoll.
Soweit wie ich das bis jetzt überblicke, zählt der Shelly nur, wenn der Eingang auf Taster gestellt ist (Momentary, auch Detached).
Zitat von: RalfRog am 07 Juni 2023, 09:58:21Der ShellyMonitor kann die beiden Readings leider nicht aktualisieren. Ob an der Namensgebung liegt?
Mir fehlt da etwas der Durchblick wie das Zusammenspiel der beiden Module genau aussieht.
Mit dem Shelly-Monitor habe ich mich bisher noch nicht ausführlich beschäftigt, da die zu Grunde liegende Funktion bei den Shellies Gen2 nicht mehr verfügbar ist.
Wenn jetzt mal ein paar Tage Regen kommen, kann ich endlich ein vernünftiges Update der Testversion bereitstellen. ;D Mal sehen...
Zitat von: Starkstrombastler am 07 Juni 2023, 12:41:57....
Soweit wie ich das bis jetzt überblicke, zählt der Shelly nur, wenn der Eingang auf Taster gestellt ist (Momentary, auch Detached)
...
Ja das kann gut sein. Habe tatsächlich bisher nur den "detach"-Mode probiert, da es mein Anwendungsfall ist.
Vermutlich auch der Interessanteste - unabhängiger Sensor.
Bei Betrieb mit Netzspannung ist allerdings der Sicherheitsaspekt unbedingt zu berücksichtigen!!!
Habe die Actions mal probiert - daher noch ein paar Anmerkungen zu der Auswertung SW / Input.
- Prima, dass dass Modul den Input (als Reading button) darstellt. Wenn es mit CoIot (Monitor) geht wäre es toll - da zeitnahes und regelmäßiges Update ohne Pollen (-> auch anderer Werte wie Power etc.).
Ja ist mit Blick auf Gen2 ein auslaufendes Modell.
- Zeitnahe Aktualisierung mittels Aktion/Webhook geht auch, kommt aber nur einmal. Aktualisierung dann erst beim nächtsten Pollen.
CoIot bleibt aktiv und läuft für die "normalen" Readings Power/Energy weiter.
Macht aber aus vielfach beschrieben Gründen der Sicherheit eine separate eingeschränkte Web-Instanz mit festem CSRF-Token nötig.
- Bei separater Web-Instanz wird sicher angeführt den Shelly doch gleich per MQTT einzubinden. Updates werden zyklisch gesendet (Shelly1 30 sec).
Nicht jedem sympatisch da per Modul meist einfacher zu handeln und mit MQTT wiederum wäre CoIot verloren - für Gen2 aber irrelevat.
Gruß Ralf
P.S.
Bleibe für meine paar Gen1-Geräte CoIot und Monitor Fan
Zitat von: RalfRog am 10 Juni 2023, 17:02:39Habe die Actions mal probiert
Die Actions in Shelly Gen1 und mehr noch in Gen2 sind ein wenig beachtetes aber mächtiges Instrument, um von den Shellies Daten nahezu in
Echtzeit zu bekommen. Die Einbindung in FHEM besteht aus zwei Teilen:
1. Die Definition der Action auf dem Shelly: Für ein bestimmtes auslösendes Event (z.B. ein Signal an einem Eingang) muss eine URL auf dem Shelly abgespeichert werden.
2. Die vom Shelly kommende Nachricht muss vom Shelly-Modul ausgewertet werden.
Für diese Kommunikation bieten sich wiederum zwei Möglichkeiten an:
a) Der Shelly teilt FHEM mit, dass sich etwas geändert hat und fordert FHEM auf, neue Daten abzuholen;
b) Der Shelly teilt FHEM mit, dass ein bestimmtes Ereignis eingetreten ist.
Für den Fall a) muss die URL also sinngemäß folgendes enthalten:
http;//ip-adresse:port/fhem/....get <device> statusDas ist relativ universell und kann gleichermaßen für alle gewünschten Actions eingetragen werden.
Für den Fall b) muss die URL auf das Ereignis abgestimmt sein, z.B.:
http;//ip-adresse:port/fhem/....set <device> input_on 0In diesem Beispiel teilt der Shelly mit, dass am Eingang 0 ein Signal anliegt. FHEM wertet dieses sofort aus und aktualisiert das Reading input_0.
Desweiteren wird das Shelly-Modul das Polling-Intervall abbrechen und sofort eine neue Anfrage an den Shelly senden (pollen). Damit werden dann weitere Readings, z.B. Power, aktualisert. Im Ergebnis liegen also aktuelle Werte des Shelly nahezu in Echtzeit in FHEM vor.
Bisherige Umsetzung im Shelly-Modul:
Die oben unter 2. genannte Auswertung ist der derzeiten Testversion bereits berücksichtigt und wird mit dem nächsten Update weiter verbessert.
Die erforderliche Definiton der Action (Punkt 1.) kann vom Shelly-Modul übernommen werden. Dies ist derzeit für Gen2-Geräte in der Testversion für eine Kommunikation gem. a) bereits enthalten und erfolgt mittels des Attributes
webhook.
Dabei wird abhängig vom gewählten FHEMWEB-Device auch ein CSFR-Token in die URL mit eingebaut, regelmäßig geprüft und bei Änderung auf dem Shelly angepasst.
Bei den Gen1-Geräten muss die Action vom Nutzer selbst eingetragen werden. Denkbar ist, dass vom Shelly-Modul eine Kopiervorlage angeboten wird oder das Einfügen mittels eines Set-Befehles erfolgt.
Diese Berücksichtigung der Shelly-Actions in FHEM erlaubt weiterhin die sogenannte Direct-Device-to-Device Kommunikation (DDD), d.h. Shellies kommunizieren untereinander oder mit anderen Geräte ohne einen Umweg über FHEM, was auf Grund der höheren Ausfallsicherheit immer eine gute Wahl ist.
Bisher hat sich aber hier im Forum noch kein Gen2-Nutzer gemeldet, der dieses Feature ausprobiert hat. Feedback dazu ist aber für die weitere Entwicklung gerne gesehen.
Hi
Danke für die vertiefenden Erklärungen.
Ich hatte nur b) probiert.
a) ist auch ne gute Idee.
Die Unterbrechung des Poll-Intervalls muss ich mal checken - habe es nicht wahrgenommen.
Muss deinen Beitrag noch ein zweites Mal in Ruhe lesen für vertiefendes Verständnis.
Bekomme demnächst nen neuen PlugS. Da kann ich mir das Attribut Webhook anschauen.
Gruß Ralf
Modulversion: my $version = "4.04e"
Hi
Wollte mich mal an die Webhooks drangeben und habe daher meine beiden "Plug's" eingesteckt ein PlugS und ein PlusPlugS.
Aufgrund der Tatsache, dass beim PlugS als Modell shellybulb stand habe ich erstmal den ShellyMonitor und alles Shelly-Devices gelöscht und dann die beiden Plug's neu angelegt.
- Der PlugS sieht gut aus. Die erwarteten Readings sind da.
WÄRE eine Unterscheidung Plug <-> Plugs nötig? Es gibt ja keine 2 Modelle zur Auswahl - nur "shellyplug". Kleine Unterschiede sind ja vorhanden z.B. temperature.
- Der PlugS sieht erstmal NICHT gut aus. Er meldet state = Error, model = shellyplusplug.
Im EventMonitor mit Log (Verbose 0/4) steht:
2023-06-16 17:41:54.877 Shelly PlugPlus initialized
2023-06-16 17:41:54.892 Global global DEFINED PlugPlus
2023.06.16 17:41:55.063 1: [Shelly_get_model] discovered model=shellyplusplug for device PlugPlus
2023-06-16 17:41:55.072 Shelly PlugPlus Model "shellyplusplug" identified
2023.06.16 17:41:56.414 1: [Shelly_proc1G] has invalid JSON data for device PlugPlus
2023-06-16 17:41:56.430 Shelly PlugPlus Error
Setze verbose 4
2023-06-16 17:50:54.648 Global global ATTR PlugPlus verbose 4
2023.06.16 17:50:54.741 4: [Shelly_Get] receiving command get PlugPlus ?
2023.06.16 17:51:05.697 4: [Shelly_Get] receiving command get PlugPlus status
2023.06.16 17:51:05.699 4: [Shelly_status] issue a non-blocking call to http://10.20.30.94/status
2023.06.16 17:51:05.759 1: [Shelly_proc1G] has invalid JSON data for device PlugPlus
2023-06-16 17:51:05.776 Shelly PlugPlus Error
Offensichtlich fragt das Modul den PlusPlugS trotz textlich korrektem Modell wie einen Gen1 ab - und es bleibt dabei.
Erst nach Wechsel zu "generic" und zurück zu "shellyplusplug" macht das Modul eine Abfrage Gen1 und dann Gen2 und zeigt die readings.
Hier der dazu nur das Log:
2023.06.16 17:41:55.063 1: [Shelly_get_model] discovered model=shellyplusplug for device PlugPlus
2023.06.16 17:41:56.414 1: [Shelly_proc1G] has invalid JSON data for device PlugPlus
*** Verbose 4
2023.06.16 17:50:54.741 4: [Shelly_Get] receiving command get PlugPlus ?
2023.06.16 17:51:05.697 4: [Shelly_Get] receiving command get PlugPlus status
2023.06.16 17:51:05.699 4: [Shelly_status] issue a non-blocking call to http://10.20.30.94/status
2023.06.16 17:51:05.759 1: [Shelly_proc1G] has invalid JSON data for device PlugPlus
2023.06.16 17:54:29.938 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 684.
2023.06.16 17:54:29.941 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 689.
2023.06.16 17:54:29.947 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 700.
2023.06.16 17:54:29.950 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 708.
2023.06.16 17:54:29.958 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 717.
2023.06.16 17:54:29.969 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 750.
*** setze Modell generic
2023.06.16 17:54:30.065 4: [Shelly_Get] receiving command get PlugPlus ?
2023.06.16 17:54:52.181 4: [Shelly_Get] receiving command get PlugPlus status
2023.06.16 17:54:52.184 4: [Shelly_status] issue a non-blocking call to http://10.20.30.94/status
2023.06.16 17:54:52.226 1: [Shelly_proc1G] has invalid JSON data for device PlugPlus
*** setze Modell shellyplusplug
2023.06.16 17:55:12.658 4: [Shelly_Get] receiving command get PlugPlus ?
2023.06.16 17:55:20.137 4: [Shelly_Get] receiving command get PlugPlus ?
2023.06.16 17:55:31.222 4: [Shelly_Get] receiving command get PlugPlus status
2023.06.16 17:55:31.225 4: [Shelly_status] Mode: relay
2023.06.16 17:55:31.227 4: [Shelly_status] issue a non-blocking call to http://10.20.30.94/rpc/Switch.GetStatus?id=0
2023.06.16 17:55:31.274 4: [Shelly_proc2G] device PlugPlus processing component relay
2023.06.16 17:55:31.277 4: [Shelly_proc2G:relay] getting relay state for device PlugPlus channel/id 0
2023.06.16 17:55:31.281 4: [Shelly_proc2G] PlugPlus: Processing metering channel
2023.06.16 17:55:31.285 1: PERL WARNING: Use of uninitialized value $pfactor in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2660.
2023.06.16 17:55:31.287 4: [Shelly_proc2G] PlugPlus relay voltage=0.3, current=0, power=0 powerfactor=
2023.06.16 17:55:31.322 4: [Shelly_proc2G] PlugPlus: short update in 60 seconds
2023.06.16 17:55:49.569 4: [Shelly_Get] receiving command get PlugPlus ?
2023.06.16 17:56:31.008 4: [Shelly_status] Mode: relay
2023.06.16 17:56:31.010 4: [Shelly_status] issue a non-blocking call to http://10.20.30.94/rpc/Switch.GetStatus?id=0
2023.06.16 17:56:31.245 4: [Shelly_proc2G] device PlugPlus processing component relay
2023.06.16 17:56:31.248 4: [Shelly_proc2G:relay] getting relay state for device PlugPlus channel/id 0
2023.06.16 17:56:31.251 4: [Shelly_proc2G] PlugPlus: Processing metering channel
2023.06.16 17:56:31.253 4: [Shelly_proc2G] PlugPlus relay voltage=0.2, current=0, power=0 powerfactor=
2023.06.16 17:56:31.279 4: [Shelly_proc2G] PlugPlus: short update in 60 secondsWas jetzt noch fehlt ist der Test ob nach einem Restart der PlusPlugS klemmt oder läuft und die Webhooks.
Edit: Ich füge den Test in der nächsten Antwort ein. Dann bleibt dieser Beitrag übersichtlicher.
Lasse die Webhook erstmal sein. So ganz sauber kommt der PlusPlugS nach FHEM-Restart nicht hoch.
Es gibt einige Perl Warnings und das Modul meint am Ende der PlusPlugS sei Gen1 ::)
Für den PlugS gibts nur einen Log-Eintrag. Habe aber auch vergessen dort verbose 4 zu setzen. Sieht aber gut aus.
Hier der Log vom Restart, der für mich nicht ganz sauber aussieht, am PlusPlugS verändert sich nix mehr, bleibt auf state = Error.
2023.06.16 18:18:04.465 0: Server shutdown
...
2023.06.16 18:20:14.261 0: Featurelevel: 6.2
...
2023.06.16 18:20:14.436 4: [Shelly_status] Mode: relay
2023.06.16 18:20:14.438 4: [Shelly_status] issue a non-blocking call to http://10.20.30.94/rpc/Switch.GetStatus?id=0
2023.06.16 18:20:14.457 4: [Shelly_shelly] PlugPlus is a second Gen device
2023.06.16 18:20:14.459 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetStatus
2023.06.16 18:20:14.477 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetConfig
2023.06.16 18:20:14.495 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetDeviceInfo
2023.06.16 18:20:14.514 1: PERL WARNING: Use of uninitialized value $net in pattern match (m//) at ./FHEM/36_Shelly.pm line 3029.
2023.06.16 18:20:14.517 1: [Shelly_webhook] Error PlugPlus: network status is not connected
2023.06.16 18:20:14.519 4: [Shelly_shelly] PlugPlus: long update in 60 seconds
2023.06.16 18:20:14.842 1: [Shelly_get_model] discovered model=shellyplusplug for device PlugPlus
2023.06.16 18:20:14.845 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 552.
2023.06.16 18:20:14.847 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 565.
2023.06.16 18:20:14.849 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 570.
2023.06.16 18:20:14.862 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 587.
2023.06.16 18:20:14.882 4: [Shelly_proc2G] device PlugPlus processing component info
2023.06.16 18:20:14.886 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 2274.
2023.06.16 18:20:14.908 4: [Shelly_proc2G] device PlugPlus processing component relay
2023.06.16 18:20:14.923 4: [Shelly_proc2G] PlugPlus: short update in 60 seconds
2023.06.16 18:20:14.941 4: [Shelly_proc2G] device PlugPlus processing component status
2023.06.16 18:20:14.949 4: [Shelly_proc2G] device PlugPlus processing component config
2023.06.16 18:20:14.969 1: [Shelly_get_model] discovered model=shellyplug for device Plug
2023.06.16 18:20:15.028 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/36_Shelly.pm line 1166.
2023.06.16 18:20:15.041 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 1171.
2023.06.16 18:20:15.045 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/36_Shelly.pm line 1171.
2023.06.16 18:21:14.012 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 1712.
2023.06.16 18:21:14.014 4: [Shelly_status] issue a non-blocking call to http://10.20.30.94/status
2023.06.16 18:21:14.044 1: [Shelly_proc1G] has invalid JSON data for device PlugPlus
2023.06.16 18:21:14.534 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/36_Shelly.pm line 1792.
2023.06.16 18:21:14.536 4: [Shelly_shelly] PlugPlus is a first Gen device
2023.06.16 18:21:14.538 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/36_Shelly.pm line 1794.
2023.06.16 18:21:14.540 4: [Shelly_shelly] intentionally aborting, PlugPlus is not 2nd Gen
Manuell get shelly-status:
2023.06.16 18:41:07.345 4: [Shelly_Get] receiving command get PlugPlus shelly_status
2023.06.16 18:41:07.347 4: [Shelly_shelly] PlugPlus is a first Gen device
2023.06.16 18:41:07.350 4: [Shelly_shelly] intentionally aborting, PlugPlus is not 2nd Gen
Manuell get status:
2023.06.16 18:41:40.419 4: [Shelly_Get] receiving command get PlugPlus status
2023.06.16 18:41:40.432 4: [Shelly_status] issue a non-blocking call to http://10.20.30.94/status
2023.06.16 18:41:40.482 1: [Shelly_proc1G] has invalid JSON data for device PlugPlus
Gruß Ralf
Edit:
Habe eine Weile gewartet ohne dass eine Änderung eintrat.
Nach ca. 15 Minuten habe ich generic/shellyplusplugS gesetzt (aber 2 mal musste ich es machen). Dann habe ich im Log/Eventmon (verbose 5) gesehen, dass die Daten korrekt als Gen2 abgerufen wurden.
Es hat "zwei?" Anläufe gebraucht bis die Readings alle da waren. 2 Mal bei On/Off schalten - beide Male einige Readings mehr.
Die Statusanzeige ist ein OK (statt Icon) und toggelt nur auf On. Ein zweites mal wieder auf Off toggeln geht nicht -> set toggle identisch
Habe dann doch noch das Attribut Webhook gesetzt. Das hat aber zu keinem Eintrag im PlusPlugS geführt und sieht im Log so aus:
2023.06.16 19:14:41.036 5: [Shelly_Attr] PlugPlus: called with command set for attribute webhook and value WEB
2023.06.16 19:14:41.038 3: [Shelly_Attr:webhook] Attribut webhook old: none new: WEB
2023.06.16 19:14:41.041 3: [Shelly_Attr:webhook] the webhook attribute is now WEB, create webhooks
2023.06.16 19:14:41.042 3: [Shelly_Attr:webhook] we will call Shelly_webhook for device PlugPlus, command is set to Create
2023.06.16 19:14:41.053 5: [Shelly_Set] calling for device PlugPlus with command ?, without value
2023.06.16 19:14:41.062 5: [Shelly_Set] calling for device PlugPlus with command ?, without value
2023.06.16 19:14:41.161 5: [Shelly_Set] calling for device PlugPlus with command ?, without value
2023.06.16 19:14:41.169 5: [Shelly_Set] calling for device PlugPlus with command ?, without value
2023.06.16 19:14:41.174 4: [Shelly_Get] receiving command get PlugPlus ?
2023.06.16 19:14:44.047 3: [Shelly_webhook] was called for device PlugPlus, but without command (Create..., Update, Delete, List)
2023.06.16 19:14:44.049 3: [Shelly_webhook] proceeding with command Create2023.06.16 19:14:44.052 4: [Shelly_webhook] device PlugPlus was called with command=Create
2023.06.16 19:14:44.053 4: [Shelly_webhook] device PlugPlus will be called by Webhook.
Hallo Ralf,
danke für das umfangreiche Testen. Da ich selbst keinen ShellyPlusPlugS in meinem Zoo habe, hat sich ein kleiner Fehler eingeschlichen und deswegen:
Zitat von: RalfRog am 16 Juni 2023, 18:45:39das Modul meint am Ende der PlusPlugS sei Gen1
Das Modul fragt erst in Gen1-Nomenklatur und dann in Gen2-Nomenklatur nach dem Typ des Shelly, bekommt dann vmtl. "SNPL-00112EU" als Antwort (vgl. Internal SHELLY) und ordnet das model "shellyplusplug" richtig zu. In der Tabelle "%shelly_models" gibt es aber nur "shellyplusplug
S". Das kann also nicht gehen.
Für einen schnellen Test bitte im Quellcode Zeile 257 das "S" entfernen.
"shellyplusplug"=>[1,0,0, 1,1,0],Ich muss mir das Modul an der Stelle nochmal anschauen, ein Logeintrag für diesen Fehlerfall wäre schon angebracht.
Das Modul arbeit derzeit mit zwei Polling-Intervallen: Der Status wird gem. Attribut "interval" gepollt, die Settings aber, um die Systemlast etwas zu reduzieren, mit einem Vielfachen davon. Daher kommen einige Readings erst nach etlichen Minuten.
Zitat von: RalfRog am 16 Juni 2023, 18:16:18WÄRE eine Unterscheidung Plug <-> Plugs nötig?
Ja, aber es sind
a) Gen1: ShellyPlug, ShellyPlugS
b) Gen2: ShellyPlusPlugS, auch in anderen Landesausführungen
Gruß
Bernhard
Also zunächst mal:
Zitat von: Starkstrombastler am 16 Juni 2023, 21:05:40...bekommt dann vmtl. "SNPL-00112EU" als Antwort
Ja exakt!
Zitat von: Starkstrombastler am 16 Juni 2023, 21:05:40Für einen schnellen Test bitte im Quellcode Zeile 257 das "S" entfernen.
Jo löst das Problem.
Zitat von: Starkstrombastler am 16 Juni 2023, 21:05:40Ja, aber es sind
a) Gen1: ShellyPlug, ShellyPlugS
War mir nur aufgefallen. Ist im Modul ja bisher auch so und es kann mit den kleinen Unterschieden ja offensichtlich umgehen.
Gruß Ralf
Habe am PlusPlugS auch mal das Kommando "get register" und "get config" geprüft
Scheint nicht für Gen2 zu funktionieren/ausgelegt zu sein.
- get PlugPlus config default_state
-> dürfte Aufruf für Gen1 sein 4: [Shelly_configure] issue a non-blocking call to http://10.20.30.94/settings/relay/0?default_state
-> im Log unter anderem 5: [Shelly_configure] device PlugPlus has returned data: "Not Found" - Nach Codeänderung: beim Webhook keine Änderung, es wird nichts eingetragen (für PlusPlugS).
- Nach Codeänderung: ebenfalls keine Änderung beim State-ICON und dem set toggle (für PlusPlugS)
Zitat von: RalfRog am 18 Juni 2023, 11:54:39Habe am PlusPlugS auch mal das Kommando "get register" und "get config" geprüft
Scheint nicht für Gen2 zu funktionieren/ausgelegt zu sein.
Ja, das stimmt, für die Gen2 sind diese Befehle noch nicht erweitert. Ich habe mich sowieso immer gefragt, ob das jemand überhaupt nutzt. Die Einrichtung eines Shelly ist m.M.n. über die Shelly-App oder seine Weboberfläche deutlich komfortabler.
Allerdings müssten dann diese Befehle im Modul für Gen2 ausgeblendet werden, das wäre noch zu tun.
Zitat von: RalfRog am 18 Juni 2023, 11:54:39beim Webhook keine Änderung, es wird nichts eingetragen (für PlusPlugS)
Da ich keinen ShellyPlusPlugS habe: Wie lautet denn die Ausgabe von
http://<ip_des_Shelly>/rpc/webhook.ListSupported Zitat von: RalfRog am 18 Juni 2023, 11:54:39keine Änderung beim State-ICON und dem set toggle (für PlusPlugS)
Das muss ich mir anschauen. Wie lautet denn die Ausgabe von
http://<ip_des_Shelly>/rpc/shelly.ListMethods
Hallo der Reihe nach ;) Wichtig zuerst.
Wenn Du was Bestimmtes brauchst sag Bescheid (habe PlugS,
PlusPlugS, Schelly1, Shelly1PM sowie Shelly3EM)
Zitat von: Starkstrombastler am 18 Juni 2023, 18:01:53Zitat von: RalfRog am 18 Juni 2023, 11:54:39beim Webhook keine Änderung, es wird nichts eingetragen (für PlusPlugS)
Da ich keinen ShellyPlusPlugS habe: Wie lautet denn die Ausgabe von http://<ip_des_Shelly>/rpc/webhook.ListSupported
{"hook_types":["switch.off","switch.on"],"types":{"switch.off":{},"switch.on":{}}}Zitat von: Starkstrombastler am 18 Juni 2023, 18:01:53Zitat von: RalfRog am 18 Juni 2023, 11:54:39keine Änderung beim State-ICON und dem set toggle (für PlusPlugS)
Das muss ich mir anschauen. Wie lautet denn die Ausgabe von http://<ip_des_Shelly>/rpc/shelly.ListMethods
uiiii - ist ja (nicht unerwartet) deutlich kompexer als Gen1
{
"methods": [
"PLUGS_UI.SetConfig",
"PLUGS_UI.GetConfig",
"PLUGS_UI.GetStatus",
"Switch.SetConfig",
"Switch.GetConfig",
"Switch.GetStatus",
"Switch.Toggle",
"Switch.Set",
"Schedule.List",
"Schedule.DeleteAll",
"Schedule.Delete",
"Schedule.Update",
"Schedule.Create",
"Input.SetConfig",
"Input.GetConfig",
"Input.GetStatus",
"Webhook.ListSupported",
"Webhook.List",
"Webhook.DeleteAll",
"Webhook.Delete",
"Webhook.Update",
"Webhook.Create",
"Script.Stop",
"Script.Start",
"Script.Eval",
"Script.GetCode",
"Script.PutCode",
"Script.SetConfig",
"Script.GetConfig",
"Script.GetStatus",
"Script.List",
"Script.Delete",
"Script.Create",
"WS.SetConfig",
"WS.GetConfig",
"WS.GetStatus",
"Mqtt.SetConfig",
"Mqtt.GetConfig",
"Mqtt.GetStatus",
"Cloud.SetConfig",
"Cloud.GetConfig",
"Cloud.GetStatus",
"BLE.SetConfig",
"BLE.GetConfig",
"BLE.GetStatus",
"Wifi.Scan",
"Wifi.ListAPClients",
"Wifi.SetConfig",
"Wifi.GetConfig",
"Wifi.GetStatus",
"Sys.SetConfig",
"Sys.GetConfig",
"Sys.GetStatus",
"KVS.Delete",
"KVS.Set",
"KVS.GetMany",
"KVS.Get",
"KVS.List",
"HTTP.Request",
"HTTP.POST",
"HTTP.GET",
"Shelly.ListMethods",
"Shelly.PutTLSClientKey",
"Shelly.PutTLSClientCert",
"Shelly.PutUserCA",
"Shelly.Reboot",
"Shelly.SetAuth",
"Shelly.Update",
"Shelly.CheckForUpdate",
"Shelly.DetectLocation",
"Shelly.ListTimezones",
"Shelly.GetStatus",
"Shelly.FactoryReset",
"Shelly.ResetWiFiConfig",
"Shelly.GetConfig",
"Shelly.GetDeviceInfo"
]
}
Zitat von: Starkstrombastler am 18 Juni 2023, 18:01:53Zitat von: RalfRog am 18 Juni 2023, 11:54:39Habe am PlusPlugS auch mal das Kommando "get register" und "get config" geprüft
Scheint nicht für Gen2 zu funktionieren/ausgelegt zu sein.
Ja, das stimmt, für die Gen2 sind diese Befehle noch nicht erweitert. Ich habe mich sowieso immer gefragt, ob das jemand überhaupt nutzt. Die Einrichtung eines Shelly ist m.M.n. über die Shelly-App oder seine Weboberfläche deutlich komfortabler.
Allerdings müssten dann diese Befehle im Modul für Gen2 ausgeblendet werden, das wäre noch zu tun.
Puh... so wirklich genutzt habe ich es nicht. Allenfalls schnell den "default_state" nachgeschaut.
Ob jemand mit Abfrage-Ergebnissen wie "default_state" oder "btn_type" etwas automatisiert - keine Ahnung.
Ich würde es vermutlich nicht vermissen.
Letztlich immer auch eine Frage wie aufwendig/komplex das nachher im Code ist.
Hallo zusammen,
ich habe mir für meine Balkonsolar einen Shelly plus 1PM und einen Shelly Pro 3EM geholt. Beides verbaut und sie funktionieren. Den 1PM habe ich problemlos über dieses Modul an Fhem angebunden... Daten ab in die DBlog, Grafana Graphen gebaut. Top, Wunderbar.
Der Shelly pro 3EM wird scheinbar noch nicht unterstütz. Man kann nur den shelly3em auswählen und damit kommt nur "error".
Auch auf die Gefahr hin, das die Frage hier schon mal gestellt wurde.. Wird es eine Unterstützung des Moduls auch für den Shelly pro 3EM geben? Im Augenblick hole ich mir die Werte über MQTT, das geht zwar, ist aber viel Bastelarbeit bis man eine einfache kwh Zählung hat.
Bei der Frage nach dem Support für den Pro 3EM schließe ich mich an...Wenn ich testen soll o.ä. bin ich dabei.
Viele Grüße
Christian
Klar, testen würde ich auch.
Hallo, mein Shellyuni zeigt in den Readings keine Spannung an.
Bei Verbose 5 werden im log JSON data angezeigt.
2023.06.23 14:09:52.790 5: [Shelly_proc1G] Spannungsmesser_Solarbatterie has JSON data: {"wifi_sta":{"connected":true,"ssid":"Castle_24GHz","ip":"192.168.178.122","rssi":-82},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"14:09","unixtime":1687522193,"serial":19337,"has_update":false,"mac":"E868E7F46F8C","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"source":"http"},{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"source":"input"}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"adcs":[{"voltage":13.14}],"ext_sensors":{},"ext_temperature":{},"ext_humidity":{},"update":{"status":"idle","has_update":false,"new_version":"20230503-102354/v1.13.0-g9aed950","old_version":"20230503-102354/v1.13.0-g9aed950"},"ram_total":50776,"ram_free":38736,"fs_size":233681,"fs_free":147337,"uptime":56254}
Was müsste ich machen, damit ich die adcs Werte in den Readings bekomme.
Bis jetzt hatte ich mit json noch nichts zu tun. Über jede Hilfe würde ich mich freuen.
List vom Device:
Internals:
.AttrList model:generic,shellyuni interval timeout shellyuser verbose:0,1,2,3,4,5 defchannel showinputs:show,hide event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading
CFGFN
DEF 192.168.178.122
FUUID 6494ae29-f33f-3b5c-f9d3-c32a4f9a81e85d40
INTERVAL 60
NAME Spannungsmesser_Solarbatterie
NR 3145
SHELLY SHUNI-1
SHELLYID shellyuni-E868E7F46F8C
STATE OK
TCPIP 192.168.178.122
TYPE Shelly
eventCount 34
units 0
.attraggr:
.attrminint:
OLDREADINGS:
READINGS:
2023-06-22 22:38:14 cloud disabled
2023-06-22 22:38:14 firmware v1.13.0
2023-06-23 02:24:24 network <html>connected to <a href="http://192.168.178.122">192.168.178.122</a></html>
2023-06-23 08:37:44 relay_0 off
2023-06-22 22:38:14 relay_1 off
2023-06-23 13:49:49 state OK
helper:
bm:
Shelly_Attr:
cnt 16
dmx -1000
dtot 0
dtotcnt 0
mTS 22.06. 23:13:27
max 0.00207304954528809
tot 0.00666689872741699
mAr:
set
Spannungsmesser_Solarbatterie
model
generic
Shelly_Define:
cnt 5
dmx -1000
dtot 0
dtotcnt 0
mTS 23.06. 13:42:20
max 0.0384259223937988
tot 0.104012727737427
mAr:
HASH(0x5563a8daa3f0)
Spannungsmesser_Solarbatterie Shelly 192.168.178.122
Shelly_Get:
cnt 65
dmx -1000
dtot 0
dtotcnt 0
mTS 22.06. 22:39:17
max 0.00552105903625488
tot 0.0190765857696533
mAr:
HASH(0x5563a8daa3f0)
Spannungsmesser_Solarbatterie
shelly_status
Shelly_Set:
cnt 324
dmx -1000
dtot 0
dtotcnt 0
mTS 22.06. 22:31:54
max 1.95329594612122
tot 2.02142333984375
mAr:
HASH(0x5563a8daa3f0)
Spannungsmesser_Solarbatterie
xtrachannels
hmccu:
Attributes:
comment https://forum.fhem.de/index.php?topic=124326.msg1188837#msg1188837
https://forum.fhem.de/index.php?topic=118446.15
defchannel 0
group Solaranlage_Gartenhaus
icon batterie@red
model shellyuni
room 00_4_Gartenhaus
verbose 5
Hast du die letzte Testversion (Beitrag #364, 6. Mai)
https://forum.fhem.de/index.php?action=profile;u=3884
Ich weiss allerdings nicht, ob Starkstrombastler an der Stelle das Ursprungsmodul ergänzt hat.
Hallo Ralf,
ja, die Version vom 06.05. habe ich installiert
Dann ist es vermutlich (noch) nicht eingebaut/ergänzt.
etwas OT wenn du den Wert dringend brauchst:
define Spannung_Solar JsonMod http://192.168.178.122/status/
darin dann Attribut
readingList complete();
interval */5 * * * * => alle 5 Minuten den Wert holen
Das "complete();" spuckt auf die Schnelle alle Werte des Uni aus.
Mit single kann man den Output einschränken. Muss aber etwas Gehirnschmalz rein.
Edit:
oder MQTT
Hallo Ralf,
du bist mein Held. Hat alles auf Anhieb geklappt
und bringt mich weiter, vielen vielen Dank.
Viele Grüße
Armin
Hallo Testergemeinde,
in den nächsten Tagen folgt eine neue Testversion, welche die bisher gemeldeten Probleme behebt. Darin enthalten ist auch der ShellyPro3EM Leistungsmesser und Energiezähler.
LG
Bernhard
Hallo Shelly-Fans,
hier ist das versprochene Update:
Neben diversen Fehlerkorrekturen werden bei allen Shellies die On-Off-Funktionalität mit den Befehlen set toggle, on-for-timer und off-for-timer überarbeitet. Die Timer, auch Shelly interne, werden ausgewertet und die Devices werden zeitnah nach deren Ablauf aktualisiert.
Für den ShellyPro3EM können automatisiert Webhooks/Actions angelegt werden. Diese werden vom Shelly bei einer gewissen Änderung ausgelöst. Sind im Stromnetz getaktete Verbraucher (z.B. Induktionskochfeld) vorhanden, kann es passieren, dass die Power-Readings mehrmals pro Sekunde aktualisiert werden. Ansonsten gibt es ein Attribut EMchannels, mit welchem die Namen der Power- und Energy-Readings, und damit auch deren Reihenfolge, angepasst werden. Das ist m.W.n. die einzige Methode, die Reihenfolge der Readings in Fhem im Sinne einer besseren Übersichtlichkeit zu beeinflussen. Mich würde interessieren, ob es eine favorisierte Konfiguration gibt. Dann könnte das im Code fixiert werden und erspart eine Menge Nebeneffekte, sollte man das Attribut im Produktivsystem ändern.
Außderm gibt es drei Attribute Energymeter_x, mit denen der aktuelle Zählerstand des bzw. der Zähler des Energieversorgers im Modul hinterlegt werden kann. Die Eingabe erfolgt in Wattstunden Wh, hinterlegt wird dann aber die Differenz zum jeweiligen Zählerstand des Shelly. Nach einer gewissen Laufzeit sollte dann die Genauigkeit des Shelly-Zählers erkennbar sein.
Für das Testen schlage ich vor, zunächst vorhandene Shelly-Devices zu löschen und dann neu anzulegen. Shutdown Restart ist erforderlich um Änderungen bei den Attributen zu berücksichtigen.
Freue mich über Rückmeldungen.
Gruß
Bernhard
Hallo Bernhard
ZitatFür das Testen schlage ich vor, zunächst vorhandene Shelly-Devices zu löschen und dann neu anzulegen. Shutdown Restart ist erforderlich um Änderungen bei den Attributen zu berücksichtigen.
Ich hab dein Modul runtergeladen und nach ./FHEM verschoben und neu geladen. Aus einem anderen Grund hab ich den Server neu gestartet. Ich möchte ungern mein einziges Shelly-Device Shelly 3EM löschen und neu anlegen. In dieser Konstellation sehe ich keine offenkundigen Fehler.
Ich hab das Modul vom Update ausgeschlossen. Ist geplant es in das SVN einzustellen? Dann müsste ich den Ausschluss rückgängig machen.
Viele Grüße Gisbert
Hallo zusammen,
habe seit letzter Woche das neue Modul im Einsatz. Ich verwende 2.5er shellys zum Steuern meiner Rolläden.
Die Geräte wurden mir in fhem immer mit verschiedenen icons für open:closed:half:stop und pct als Slider angezeigt. Der Slider ist jetzt leider verschwunden und es steht nur mehr pct dort.
Bin leider kompletter Anfänger und weiß nicht recht wo ich zu suchen anfangen soll.
Wer mir bitte jemand weiter helfen?
das attribut webCmd schaut so aus
webCmd open:closed:half:stop:pct
Vielen Dank
Liebe Grüße Bernhard
Hallo Bernhard,
sehr cool. Besten Dank.
Modul kopiert, 3EM gelöscht und neu gestartet. 3EM neu angelegt.
2023.07.03 16:19:04 1: [Shelly_proc1G] device Stromverbrauchsmesser has error "invalid JSON data"
2023.07.03 16:19:05 2: [Shelly_get_model] device Stromverbrauchsmesser is of type SPEM-003CEBEU
2023.07.03 16:19:05 2: [Shelly_get_model] discovered model=shellypro3em for device Stromverbrauchsmesser
2023.07.03 16:19:05 1: [Shelly_get_model] the attribute 'model' of device Stromverbrauchsmesser is set to 'shellypro3em'
Klappt soweit, als Darstellung werde ich wohl "_ABC" nutzen.
Viele Grüße
Christian
Hallo Gisbert,
das Update sollte für den Shelly3EM ist in Bezug auf verwaiste Attribute und Readings unkritisch sein. Es scheint ja auch gut zu funktionieren.
Zitat von: Gisbert am 03 Juli 2023, 11:07:03Ist geplant es in das SVN einzustellen?
Wenn die Community, und auch der ursprüngliche Modulentwickler (PAH, ich nehme an, dass er hier gelegentlich mitliest) mit meiner Arbeit zufrieden sind (und ich selbst auch), dann muss ich nur noch herausbekommen, wie man ein Modul ins SVN einstellt.
VG Bernhard
Hallo Bernhard,
mit dem Update von gestern hat sich für den Shelly2.5/Rollo nichts wesentliches geändert.
Zitat von: bene80 am 03 Juli 2023, 14:48:08Der Slider ist jetzt leider verschwunden und es steht nur mehr pct dort.
Aber die Rollosteuerung funktioniert schon noch und statt den Slider zu schieben kann man über die Kommandozeile einen Prozentwert eingeben z.B.
set <Rollo-Device> pct 55 Das Thema ist hier mal diskutiert worden und der Slider wurde aus dem Modul herausgenommen, um inkrementelle Befehle zu ermöglichen.
Mit dem nächsten Update wird es den Slider wieder geben und inkrementelle Befehle erfolgen z.B. mit
set <Rollo-Device> delta +20 oder
set <Rollo-Device> delta -25VG Bernhard
Hallo Bernhard,
mein letztes Update ist schon ewig her, darum hab ich nicht mitbekommen dass sich das geändert hat.
Ja sonst funktioniert alles wunderbar. Ok wenn der Slider aus dem Modul genommen wurde erklärt es
das warum jetzt nur mehr pct dort steht. Wenn der wieder rein kommt wäre das natürlich super, dann brauch ich vorerst nicts ändern.
Vielen Dank für deine Antwort
Schöne Grüße
Bernhard
Hallo Bernhard,
mit dem Shelly uni läuft alles Bestens
und die Spannung wird jetzt auch angezeigt.
Vielen Dank für deine Arbeit.
Viele Grüße Armin
War auf dem Testsystem mit einem SpielVersuch beschäftigt ein laufendes Buster auf Bullseye upzugraden... der Kernel bleibt bei 5.10.103 wie buster :(
So hab die alte SD wieder drin und nun zunächst einen Plug, PlusPlug, 1, 1PM und 3EM neu eingebunden. Sieht soweit gut aus ;D
- Der Shelly1 ist nicht ganz sauber. Modell wird nicht gesetzt und daher ist er nicht komplett (Relay etc.)
-> Nachdem es manuell gesetzt wurde kommt das Reading relay.
-> On/Off klappt und ICON wird angezeigt
-> Es werden zu viele Attribute angezeigt (metertype, webhook etc.).
-> Attribut showinputs fehlt, Rednigs kommen auch nicht nach Betätigung des Inputs (SW)
==> Zweiter Versuch den 1er einzubinden lief korrekt ab und er sah gut aus inkl. "showinputs" :)
- :) "showinputs" ist am 1PM da und nichts Auffälliges
- :) die Readings am 3EM sehen fast vollständig aus
-> Ist powerTTL gerechnet oder der Wert aus "total_power" vom Shelly selber?
-> energy_returned_0 und returnedTTL passen namentlich nicht ganz zusammen.
-> Anzahl der Nachkommstellen bei den gerechneten reactivepower & apparentpower könnte weniger sein
(Ich glaube es gibt 2Gen-Devices die liefern apparentpower. Da wäre die Frage nach Erkennbarkeit gerechneter zu ausgelesenen Werten)
- :) Plug: nichts Auffälliges
- PlusPlug: Webhooks noch nicht probiert, Anzeige im Webinterface noch "OK" statt "Lampen"-ICON
Habe blöderweise nicht mehr so ganz im Kopf wie das alles im Vorgänger aussah ::)
Gruß Ralf
Hallo Ralf,
bei mir laufen mehrere Shelly1 ohne Probleme mit der Testversion. Ich schlage daher vor, das Verhalten weiter zu beobachten.
Zum Shelly3EM:
Zitat von: RalfRog am 05 Juli 2023, 00:57:07Ist powerTTL gerechnet oder der Wert aus "total_power" vom Shelly selber?
Im Moment ist powerTTL die Addition der Einzelleistungen.
In der nächsten Version wird total_power vom Shelly gelesen und im Reading powerTTL abgelegt. Der aus den Einzelwerten berechnete Wert wird dann in powerTTLc abgelegt. Wenn beide Werte immer übereinstimmen, kann in einer späteren Version auf die Berechnung verzichtet werden.
Zitat von: RalfRog am 05 Juli 2023, 00:57:07energy_returned_0 und returnedTTL passen namentlich nicht ganz zusammen.
Damit das passt, wird das Reading auf energy_returned_TTL geändert.
Zitat von: RalfRog am 05 Juli 2023, 00:57:07Anzahl der Nachkommstellen bei den gerechneten reactivepower & apparentpower könnte weniger sein
So ist das, wenn man das Device nicht in der Testumgebung zur Verfügung hat... Werte werden auf eine Kommastelle gerundet.
Wenn die Berechung stimmt, muss man das eigentlich nicht separat ausweisen. Das gilt natürlich auch für die Ausgangswerte. Mich machen bspw. die Leistungsfaktoren PF bei meinem ShellyPro3EM stutzig. Die liegen oft zwischen 0.6 und 0.7. Wenn das nicht valide ist, taugt eine darauf aufbauende Rechnung natürlich auch nichts.
Zitat von: RalfRog am 05 Juli 2023, 00:57:07PlusPlug: Webhooks noch nicht probiert, Anzeige im Webinterface noch "OK" statt "Lampen"-ICON
Für einkanalige Devices PlusPlug, Plus1 und Pro1 wird der 'state' im Modul entsprechend geändert.
Gruß
Bernhard
Zitat von: Starkstrombastler am 05 Juli 2023, 22:12:26Wenn beide Werte immer übereinstimmen, kann in einer späteren Version auf die Berechnung verzichtet werden.
Wenn ich "händisch" schon mal die Summe kontrolliert habe, hat es bisher gepasst.
Zitat von: Starkstrombastler am 05 Juli 2023, 22:12:26Wenn die Berechung stimmt, muss man das eigentlich nicht separat ausweisen. Das gilt natürlich auch für die Ausgangswerte. Mich machen bspw. die Leistungsfaktoren PF bei meinem ShellyPro3EM stutzig. Die liegen oft zwischen 0.6 und 0.7. Wenn das nicht valide ist, taugt eine darauf aufbauende Rechnung natürlich auch nichts.
Wenn ich "starke" ohmsche Lasten auf einer Phase hatte war ich immer nahe bei 1.
Mir fehlt allerdings Erfahrung wo man mit den modernen haushaltsüblichen Verbrauchern so landet (LED-Licht, Schaltnetzteile, Induktionsherd etc.) und wie zuverlässig die verbauten Mess-IC den PF erfasssen können.
Gruß Ralf
Zitat von: Starkstrombastler am 26 Mai 2023, 16:03:08Das Shelly Modul ist von der Anwendung her einfacher als MQTT (https://wiki.fhem.de/wiki/MQTT) und eignet sich daher insbesondere für FHEM-Einsteiger.
Ist ja cool, da denkt einer mal an mich... O:-) und ein fröhliches Hallo allerseits!
Ich erzähle und frage einfach mal, ja?
Es geht um meine Rolläden. Die sollen hoch und runter und Status wäre nett. Hier lagen ein 2.5 und ein 2PM für Test rum, es fehlte das Entscheidende: Einer, der das einbaut.
type "SHSW-25"
fw "20191217-074901/1047-long-id-for-shelly-devices@ab2bdce7"
----
id "shellyplus2pm-b8d61a85ff88"
model "SNSW-102P16EU"
gen 2
fw_id "20220527-091739/0.10.2-beta4-gecc3a61"
ver "0.10.2-beta4"
app "Plus2PM"
Nun habe ich endlich einen Elektromeister gefunden, der das mehr oder minder freiwillig will und zudem auch schon allgemein Erfahrungen mit Shelly hat - der hat heute beide eingebaut. Ja, inzwischen habe ich verstanden, dass ich den 2.5 als veraltet wegtun werde: Alle Rolläden werden künftig Plus2PM erhalten, das ist klar.
Die Integration war etwas hakelig, ich musste euch ja erst finden. Nun habe ich die 36_Shelly aus dem Beitrag #429 und beide Shelly sind integriert und ich kann beide Rolläden schon mal hoch und runterfahren - mehr brauche ich eigentlich nicht.
Frage: Ist eine Temperatur von um die 70°C eigentlich normal oder tendiere ich dazu, die Hütte abzubrennen?
Frage/Bitte bzgl. Plus2PM gen2: Könnt ihr mir bitte freundlicherweise zeigen, wie ihr das in FHEM integiert habt? Also mit devState-Icon und Knöpfen und event-on-* und was man da so macht. Also das wäre sehr schön, sehr hilfreich.
Darf ich bitte noch um Ratschläge zu weiteren künftigen Shelly bitten? Ich mach einfach mal, ja?
Lichtschalter, bisher Kippschalter (LED, Nullleiter wohl vorhanden): Welchen Shelly nehmen?
Lichtschalter, bisher Relais (LED, Nullleiter wohl vorhanden): Welchen Shelly nehmen?
Steckdosen, mit Messung: Welchen Shelly nehmen?
Ganz wichtig: Ich danke euch für eure tolle Arbeit!
Hallo Curt,
willkommen in dieser Runde.
Zitat von: curt am 06 Juli 2023, 00:26:34Ist eine Temperatur von um die 70°C eigentlich normal
Das ist die Prozessortemperatur. Die Gehäuse-Aussentemperatur ist (hoffentlich) niedriger. Ein ShellyPlus2PM, der bei mir auf dem Schreibtisch liegt hat eine interne Temperatur von 50°C.
Zitat von: curt am 06 Juli 2023, 00:26:34Plus2PM gen2: Könnt ihr mir bitte freundlicherweise zeigen, wie ihr das in FHEM integiert habt?
Warte noch ein paar Tage, dann kommt ein Update der Testversion. Diese enthält für den Roller-Mode des ShellyPlus2PM vordefinierte Werte für die Attribute devStateIcon und cmdIcon.
Und vielleicht hat der eine oder andere noch spannende Code-Snippets, die er hier gerne verlinken kann.
Zitat von: curt am 06 Juli 2023, 00:26:34Darf ich bitte noch um Ratschläge zu weiteren künftigen Shelly bitten?
Von einem Shelly-Verkäufer würden hier jetzt bestimmt ganz viele Vorschläge kommen. Ich schlage aber vor, zunächst einmal die grundsätzliche Frage zu durchleuchten: Wie ist die Ausgangslage und was soll erreicht werden?
Und weil wir hier hauptsächlich über die Integration der Shellies in Fhem mit dem Shelly-Modul sprechen, gibt es im Shelly Support Forum (https://www.shelly-support.eu/forum/) sicherlich auch viele Anregungen.
Gruß
Bernhard
Zitat von: Starkstrombastler am 07 Juli 2023, 10:30:19willkommen in dieser Runde.
Hallo Bernhard, danke für die Aufnahme und freundliche Antwort.
Zitat von: Starkstrombastler am 07 Juli 2023, 10:30:19Zitat von: curt am 06 Juli 2023, 00:26:34Ist eine Temperatur von um die 70°C eigentlich normal
Das ist die Prozessortemperatur. Die Gehäuse-Aussentemperatur ist (hoffentlich) niedriger. Ein ShellyPlus2PM, der bei mir auf dem Schreibtisch liegt hat eine interne Temperatur von 50°C.
Die jetzt bei mir verbauten zwei ShellyPlus2PM sind hintereinander (!) in Rigips + starke Isolierung eines Fertigteils-Niedrigenergiehauses der ersten Generation verbaut. Dort pendelt sich die interne Temperatur nun bei ca. 67°C ein.
Zitat von: Starkstrombastler am 07 Juli 2023, 10:30:19Zitat von: curt am 06 Juli 2023, 00:26:34Plus2PM gen2: Könnt ihr mir bitte freundlicherweise zeigen, wie ihr das in FHEM integiert habt?
Warte noch ein paar Tage, dann kommt ein Update der Testversion. Diese enthält für den Roller-Mode des ShellyPlus2PM vordefinierte Werte für die Attribute devStateIcon und cmdIcon.
Oh, das klingt ja wie Weihnachten, ich freue mich.
Zitat von: Starkstrombastler am 07 Juli 2023, 10:30:19Und vielleicht hat der eine oder andere noch spannende Code-Snippets, die er hier gerne verlinken kann.
Ich habe vier Velux-Schrägdachfenster mit Rolläden (sowie Öffnung). Woher die dortigen Werte kommen (Modul oder von mir aus dem Forum abgeschrieben) kann ich nicht mehr sagen. Aber ich kann sie Dir gern zeigen. Da das andere vermutlich nicht so brennend interessiert, würde ich das alles in Anlagen packen, vmtl. sogar
nachträglich in diesem Beitrag. (Erledigt)
Ganz unabhängig davon interessiert mich die Einbindung ShellyPlus2PM/Roller in die Nutzeroberfläche FTUI3, also falls das jemand hat. (Slider ist für mich gar nicht mal zwingend; on/off und Status wäre es.)
Danke zudem für den netten offtopic-Zaunpfahl, das wusste ich nicht. Ich werde dort nachfragen.
P.S:
Möglicherweise ist gleiche Firmware sinnvoll (oder umgekehrt wird von Firmwareupdates abgeraten). Bei mir steht jedenfalls derzeit im Reading "firmware"
v0.10.2-beta4(update possible to latest stable v0.14.1)PP.S:
Etwas schwer zu erkennen, es sind zwei Anhänge, der eigentlich ggf. interessante ist die Textdatei.
2023-07-07_Velux.png
2023-07-07_Velux.txt
Hallo Curt,
mit Firmwareupdates der Shellies habe ich bisher keine schlechten Erfahrungen gemacht. Ich habe nur von einem Fall gehört, wo sich ein Nutzer über verkürzte Speicherzeiten von Zählerdaten (Shelly3EM) in der Cloud beschwert. Für FHEM-Nutzer sollte dies aber gar kein Thema sein, da wir mit FHEM unsere eigenen Daten loggen und speichern.
Es ist vielmehr so, dass das FHEM-Modul auf der aktuellen Firmware aufsetzt. Es gibt kein Versionsmanagement, welches sicherstellt, dass das Modul mit älteren Firmwareständen zuverlässig funktioniert.
Wenn du, warum auch immer, ein Update rückgängig machen willst, bietet das Shelly-Support-Forum alle Firmwareversionen zum Download an.
Die von dir vorgestellten Device-Definitionen zeigen, dass du eine funktionierende Lösung für deine Rollos hast. Glückwunsch!
Ich dachte aber eher an Code-Snippets bzgl. einer weitergehenden Integration von Shelly-Devices.
Und noch ein Hinweis: für die Einbindung von Code hier im Forum bitte den Code-Tag der Symbolleiste nutzen.
Gruß
Bernhard
Zitat von: Starkstrombastler am 08 Juli 2023, 13:15:54Die von dir vorgestellten Device-Definitionen zeigen, dass du eine funktionierende Lösung für deine Rollos hast. Glückwunsch!
Leider bin ich nicht in der Lage, das auf Plus2PM anzuwenden, da ist mein Problem.
Shelly-Update verstanden und umgesetzt.
Hallo Shelly-User,
hier ist wieder ein Update:
Mit diesem Update werden die hier zuletzt diskutierten Punkte berücksichtigt.
Neu: für die Roller-Devices (Shelly2/2.5/Plus2/Pro2) wurde ein Befehl eingebaut, der vordefinierte Standardattribute für die Rollosteuerung setzt:
get <name> predefAttrDamit werden die Attribute devStateIcon, cmdIcon, webCmd and eventMap gesetzt, sofern diese noch nicht definiert sind. Der User kann diese Attribute wie sonst üblich ändern oder auch löschen. Es gibt auch den Slider wieder.
Das Device sieht dann z.B. so aus:
rollo-device-overview.JPG
Inkrementelle Befehle erfolgen z.B. mit
set <Rollo-Device> delta +20 oder
set <Rollo-Device> delta -25
Nicht neu, aber vielleicht nicht allen bekannt ist die Möglichkeit, an den Rollo direkt Fahrzeiten (in Sekunden) zu übergeben:
set <Rollo-Device> open <int> oder
set <Rollo-Device> closed <int>
Nochmal erwähnen möchte ich die Möglichkeit, mit dem Attribut 'webhook' die Actions auf dem Shelly automatisiert zu definieren:
attr <name> webhook <FHEMWeb>Die verfügbaren FHEMWeb-Devices werden per Dropdown-List angeboten. Es muss eine nicht passwortgeschütze Instanz ausgewählt werden.
Damit können Ereignisse am Shelly (z.B. Tasterdruck) ohne Zeitverzögerung an Fhem übertragen werden.
Das Attribut steht zur Zeit nur für Gen2-Devices zur Verfügung. Die Befehle (URLs) können aber als Kopiervorlage für Gen1-Devices genutzt werden.
Die URL auf einem ShellyPro3EM sieht dann beispielsweise so aus:
http://192.168.178.99:8083/fhem?XHR=1&cmd=set%20Shelly_Y173%20Active_Power_$phase%20$active_poweroder einem ShellyPlusi4:
http://192.168.178.99:8083/fhem?XHR=1&cmd=set%20Shelly_Y176%20button_on%200
Viel Erfolg beim Ausprobieren
Gruß
Bernhard
defmod Heizungsschalter Shelly 192.168.178.92
attr Heizungsschalter devStateIcon 1.on:fts_door_open@green:off 1.off:fts_door@red:on 2.OK:10px-kreis-gruen@green 2.NOTOK:10px-kreis-rot@red
attr Heizungsschalter interval 60
attr Heizungsschalter model shellyplus1pm
attr Heizungsschalter room Shelly
attr Heizungsschalter stateFormat 2:state\
<a href="http://IPAddress" target="_blank">Hostname</a> \
1:relay\
<br>\
<b>Firmware:</b>\
firmware\
<br>\
<b>Wifi AP:</b>\
network_ssid
attr Heizungsschalter userReadings IPAddress {InternalVal($NAME,"DEF","0.0.0.0")}, \
Hostname {InternalVal($NAME,"NAME","0.0")}
setstate Heizungsschalter 2:Error: JSON\
<a href="http://192.168.178.92" target="_blank">Heizungsschalter</a> \
1:relay\
<br>\
<b>Firmware:</b>\
v0.14.1(update possible to v1.0.0-beta5)\
<br>\
<b>Wifi AP:</b>\
FB7590
setstate Heizungsschalter 2023-07-13 12:17:14 Hostname Heizungsschalter
setstate Heizungsschalter 2023-07-13 12:17:14 IPAddress 192.168.178.92
setstate Heizungsschalter 2023-07-13 12:12:39 cloud enabled(connected)
setstate Heizungsschalter 2023-07-13 12:12:39 firmware v0.14.1(update possible to v1.0.0-beta5)
setstate Heizungsschalter 2023-07-13 12:12:39 input off
setstate Heizungsschalter 2023-07-13 12:12:39 input_mode switch straight follow
setstate Heizungsschalter 2023-07-13 12:17:14 network invalid JSON data
setstate Heizungsschalter 2023-07-13 12:16:39 network_rssi -54
setstate Heizungsschalter 2023-07-13 12:12:39 network_ssid FB7590
setstate Heizungsschalter 2023-07-13 12:12:36 state Error: JSON
setstate Heizungsschalter 2023-07-13 12:12:39 webhook_cnt 0
setstate Heizungsschalter 2023-07-13 12:12:39 webhook_ver 0
Ich bekomme leider bei network und state JSON Fehler.
War auch in der letzten Version schon so.
An was kann das liegen?
Gruß
Hubert
Zitat von: carlos am 13 Juli 2023, 12:22:50Ich bekomme leider bei network und state JSON Fehler.
Da ich selbst keine ShellyPlus1PM im Einsatz habe: Frage an die Runde: gibt es ähnliche Probleme mit ShellyPlus1PM?
Vielleicht lässt sich mit verbose 5 das JSON-Ergebnis mal händisch analysieren.
Bei mir war ja auch mal so was komisches, was sich mit "$json = JSON->new->utf8->relaxed;" lösen ließ. Es war nichts offensichtlich falsch am Ergebnis.
(siehe im Mai https://forum.fhem.de/index.php?msg=1274939)
Gruß Ralf
Zitat von: Starkstrombastler am 13 Juli 2023, 11:45:02Neu: für die Roller-Devices (Shelly2/2.5/Plus2/Pro2) wurde ein Befehl eingebaut, der vordefinierte Standardattribute für die Rollosteuerung setzt:
get <name> predefAttrDamit werden die Attribute devStateIcon, cmdIcon, webCmd and eventMap gesetzt, sofern diese noch nicht definiert sind.
Also für mich ist das ganz toll, herzlichen Dank!
Das (bis auf die Schrittschaltung) muss ich nun noch in FTUI3 umsetzen; Du nutzt nicht zufällig die Nutzeroberfläche FTUI3?
Zitat von: curt am 14 Juli 2023, 00:08:28Das (bis auf die Schrittschaltung) muss ich nun noch in FTUI3 umsetzen; Du nutzt nicht zufällig die Nutzeroberfläche FTUI3?
Neu ist eigentlich nur die inkrementelle Ansteuerung mit 'delta' bzw. 'up' und 'down'. Das war früher schon mit 'pct +/- value' gelöst, aber da ging der Slider nicht mehr. Was bedeutet das denn für FTUI, ich habe das nicht im Einsatz?
Zitat von: Starkstrombastler am 13 Juli 2023, 23:32:45Zitat von: carlos am 13 Juli 2023, 12:22:50Ich bekomme leider bei network und state JSON Fehler.
Da ich selbst keine ShellyPlus1PM im Einsatz habe: Frage an die Runde: gibt es ähnliche Probleme mit ShellyPlus1PM?
Bernhard erstmal Danke für deine Weiterentwicklung.
Bei mir selber Fehler.
mit der $Id: 36_Shelly.pm 2023-05-04 bfranke $ Version läuft es wieder.
Was soll ich testen/auslesen?
Gruss Benny
Gleicher Fehler sowohl beim shellyplus1 als auch beim shellyplus1pm.
Folgendes steht im log.
2023.07.14 17:41:47 4: [Shelly_status] issue a non-blocking call to http://192.168.178.92/rpc/?id=0
2023.07.14 17:41:47 5: [Shelly_proc2G] =============> Status 2G Heizungsschalter model shellyplus1pm component err data Invalid request
2023.07.14 17:41:47 4: [Shelly_proc2G] device Heizungsschalter processing component
2023.07.14 17:41:47 5: [Shelly_proc2G] device Heizungsschalter has returned data Invalid request
2023.07.14 17:41:47 1: [Shelly_proc2G] device Heizungsschalter has error "invalid JSON data"
von Hand http://192.168.178.92/rpc/?id=0 ergibt auch: Invalid request
Zitat von: carlos am 14 Juli 2023, 17:41:052023.07.14 17:41:47 4: [Shelly_status] issue a non-blocking call to http://192.168.178.92/rpc/?id=0 (http://192.168.178.92/rpc/?id=0)
Diese Logzeile ist hilfreich und führt zur Zeile 2128 in 36_Shelly.pm. Die Zeile muss wie folgt lauten:
my $comp = AttrVal($name,"mode","relay");Damit lautet die Anfrage an den Shelly:
http://<ip-addr>/rpc/Switch.GetStatus?id=0Zitat von: benz_freak am 14 Juli 2023, 16:23:29mit der $Id: 36_Shelly.pm 2023-05-04 bfranke $ Version läuft es wieder.
In der Version vom 4.5. ist die besagte Zeile noch mit "relay" enthalten.
Die ShellyPlusPlug müssten übrigens das gleiche Fehlerbild aufweisen. Kann das jemand bestätigen?
Ja, mein PlusPlug meldet auch: "state Error: JSON 2023-07-14 23:55:00"
Das list:
Internals:
CFGFN
DEF 11.12.13.14
FUUID 64b1c426-f33f-84d4-7b0b-0dd12c43ce7502f1
INTERVAL 60
NAME PPlug
NR 74
SHELLY SNPL-00112EU
SHELLYID shellyplusplugs-80646fd00624
STATE Error: JSON
TCPIP 10.20.30.94
TYPE Shelly
eventCount 6
units 0
READINGS:
2023-07-14 23:55:02 cloud disabled
2023-07-14 23:55:02 firmware v0.12.99-plugsprod1
2023-07-14 23:55:02 network <html>connected to <a href="http://11.12.13.14">11.12.13.14</a> (Wifi)</html>
2023-07-14 23:55:02 network_rssi -76
2023-07-14 23:55:02 network_ssid nochnWLAN
2023-07-14 23:55:00 state Error: JSON
2023-07-14 23:55:02 webhook_cnt 0
2023-07-14 23:55:02 webhook_ver 0
helper:
a_Active_Power 0
b_Active_Power 0
c_Active_Power 0
power 0
powerCnt 1
Attributes:
model shellyplusplug
Gruß Ralf
Edit:
nach einem get <name> model hat der state auf "initialized" gewechselt.
Log:
2023.07.14 23:54:51.428 2: [Shelly_get_model] device PPlug is of type SNPL-00112EU
2023.07.14 23:54:51.432 2: [Shelly_get_model] discovered model=shellyplusplug for device PPlug
2023.07.14 23:54:51.435 1: [Shelly_get_model] the attribute 'model' of device PPlug is set to 'shellyplusplug'
2023.07.14 23:55:00.390 1: [Shelly_proc2G] device PPlug has error "invalid JSON data"
2023.07.14 23:55:02.620 3: [Shelly_proc2G:info] PPlug: firmware updated from 1 to v0.12.99-plugsprod1
==> verbose 4
==> get model
2023.07.15 00:01:02.585 4: [Shelly_shelly] PPlug is a second Gen device
2023.07.15 00:01:02.589 4: [Shelly_shelly] issue a non-blocking call to http://11.12.13.14/rpc/Shelly.GetStatus
2023.07.15 00:01:02.598 4: [Shelly_shelly] issue a non-blocking call to http://11.12.13.14/rpc/Shelly.GetConfig
2023.07.15 00:01:02.607 4: [Shelly_shelly] issue a non-blocking call to http://11.12.13.14/rpc/Shelly.GetDeviceInfo
2023.07.15 00:01:02.618 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 00:01:02.621 4: [Shelly_webhook] device PPlug will be called by Webhook.
2023.07.15 00:01:02.625 4: [Shelly_webhook] issue a non-blocking call to http://11.12.13.14/rpc/Webhook.List
2023.07.15 00:01:02.634 4: [Shelly_shelly] PPlug: long update in 60 seconds
2023.07.15 00:01:02.734 4: [Shelly_proc2G] device PPlug processing component status
2023.07.15 00:01:02.739 4: [Shelly_proc2G:status] PPlug: processing the answer rpc/Shelly.GetStatus from Shelly_shelly()
2023.07.15 00:01:02.748 4: [Shelly_proc2G] device PPlug processing component info
2023.07.15 00:01:02.752 4: [Shelly_proc2G:info] PPlug: processing the answer rpc/Shelly.GetDeviceInfo from Shelly_shelly()
2023.07.15 00:01:02.760 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 00:01:02.764 4: [Shelly_webhook] processing the webhook data for command=Check
2023.07.15 00:01:02.768 4: [Shelly_webhook] our counter says 0 webhooks on shelly
2023.07.15 00:01:02.771 4: [Shelly_webhook_url] calling url-builder with args: PPlug 0 ch:0 noe:0
2023.07.15 00:01:02.834 4: [Shelly_webhook_url] the host-ip of PPlug is: 11.12.13.40
2023.07.15 00:01:02.838 4: [Shelly_webhook_url] FHEMweb-device for PPlug is none (none or undefined)
2023.07.15 00:01:02.908 4: [Shelly_proc2G] device PPlug processing component config
2023.07.15 00:01:02.915 4: [Shelly_proc2G:config] PPlug: processing the answer rpc/Shelly.GetConfig from Shelly_shelly()
2023.07.15 00:01:21.789 2: [Shelly_get_model] device PPlug is of type SNPL-00112EU
2023.07.15 00:01:21.792 2: [Shelly_get_model] discovered model=shellyplusplug for device PPlug
Edit2
nach absetzen von "on" aus der FHEMoberfläche:
state Error: JSON
network invalid JSON data (wechselt aber nach 60 sek. auf connected)
Der Grund ist vermutlich im Log ersichtlich (GetStatus-Methode nach rpc/ fehlt, oder?):
2023.07.15 00:14:07.589 4: [Shelly_Set] switching channel 0 for device PPlug with command ?turn=off, FF=0
2023.07.15 00:14:07.593 4: [Shelly_onoff] issue a non-blocking call to http://11.12.13.14/relay/0?turn=off
2023.07.15 00:14:08.153 4: [Shelly_status] issue a non-blocking call to http://11.12.13.14/rpc/?id=0
2023.07.15 00:14:08.187 4: [Shelly_proc2G] device PPlug processing component
2023.07.15 00:14:08.192 1: [Shelly_proc2G] device PPlug has error "invalid JSON data"
http://11.12.13.14/relay/0?turn=off funktioniert aber http://11.12.13.14/rpc/?id=0 nicht (= Invalid request).
Zitat von: Starkstrombastler am 14 Juli 2023, 10:50:06Zitat von: curt am 14 Juli 2023, 00:08:28Das (bis auf die Schrittschaltung) muss ich nun noch in FTUI3 umsetzen; Du nutzt nicht zufällig die Nutzeroberfläche FTUI3?
Neu ist eigentlich nur die inkrementelle Ansteuerung mit 'delta' bzw. 'up' und 'down'. Das war früher schon [...]
Eigentlich geht es um Nutzerergonomie, bezogen auf die Oberfläche FTUI3. Da ist immer schlau wenn man mal sehen kann, wie es andere umsetzen. im Idealfall spart es Arbeit, klar.
Ich bin da nun in den Anfängen, da fällt mir was auf: Die Änderung des state kommt zu langsam nach FTU3, da wird mappen nicht funktionieren. Aber das scheint mir sowieso (für meinen Fall) eher sinnfrei, ich steuere ja nicht Apollo-11.
Real fehlt (mir) ein reading, welches die Zustände "fährt hoch", "fährt runter", "nix passiert" haben kann. Falls es das schon gibt habe ich es übersehen.
Wäre es denn bitte möglich, gelegentlich noch so ein Reading (natürlich mit sinnvoller bezeichneten Werten) einzubauen?
Hallo Ralf,
danke für Nachstellen:
Zitat von: RalfRog am 14 Juli 2023, 23:56:49Ja, mein PlusPlug meldet auch: "state Error: JSON 2023-07-14 23:55:00"
Damit wird das Fehlerbild bestätigt. Mit einer unvollständigen Anfrage kann der Shelly eben nichts anfangen.
Und weil das System den Fehler abfängt, 'berappelt' es sich auch und korrekte Anfragen liefern wieder vernünftige Ergebnisse (bis zur nächsten fehlerhaften Anfrage).
Und wie sieht es nach dem oben beschriebene Edit in Zeile 2128 der 36_Shelly.pm aus? Ich hoffe, da ist kein weiterer Fehler hineingeraten.
Hallo curt,
Zitat von: curt am 15 Juli 2023, 01:34:54Real fehlt (mir) ein reading, welches die Zustände "fährt hoch", "fährt runter", "nix passiert" haben kann. Falls es das schon gibt habe ich es übersehen.
schau dir mal das Reading 'state' an: es nimmt beim Fahren die Werte 'drive-up' bzw. 'drive-down' an. Und im Stillstand zeigt es die ungefähre Position in der Form 'pct-ii'.
Zitat von: Starkstrombastler am 15 Juli 2023, 10:19:15Hallo Ralf,
danke für Nachstellen:
Zitat von: RalfRog am 14 Juli 2023, 23:56:49Ja, mein PlusPlug meldet auch: "state Error: JSON 2023-07-14 23:55:00"
Damit wird das Fehlerbild bestätigt. Mit einer unvollständigen Anfrage kann der Shelly eben nichts anfangen.
Und weil das System den Fehler abfängt, 'berappelt' es sich auch und korrekte Anfragen liefern wieder vernünftige Ergebnisse (bis zur nächsten fehlerhaften Anfrage).
Und wie sieht es nach dem oben beschriebene Edit in Zeile 2128 der 36_Shelly.pm aus? Ich hoffe, da ist kein weiterer Fehler hineingeraten.
Damit funktionieren mein shellyplus1 und shellyplus1pm.
Danke dafür.
Yep PlusPlug ist damit (Edit in Zeile 2128) ebenfalls ok :D
Gruß Ralf
P.S.
Ich hatte gestern versucht das Problem in der API-Beschreibung nachzulesen.
Daher nur als Frage am Rande:
Müsste nicht konsequenterweise um in der Nomenklatur der Gen2 zu bleiben das Relay per "http://<IP>/rpc/Switch.Set?id=0&on=true|false" geschaltet werden?
Soweit ich das in der Beschreibung sehen konnte haben ja nur die "Components" Switch,Cover & Light je einen HTTP-Endpoint zum Schalten/Fahren
Andererseits bleibts mit http://<IP>/relay/0?turn=on|off für Gen1 und Gen2 gleich.
Webhook Gen2?
Müsste am PlusPlug schon etwas gehen?
Zumindest das "attribut webhook" kann ich auf die aktuelle FHEM-Web-Instanz setzen. Aber dann...??
Zitat von: RalfRog am 15 Juli 2023, 19:06:20Aber dann...??
...dann werden auf dem Shelly einige Webhooks angelegt (auf der Shelly Oberfläche unter Actions zu sehen), das Reading webhook_cnt zeigt die Anzahl der Webhooks und webhooks_ver den Versionszähler des Shelly - aber nur wenn im Modul alles passt.
Die Webhooks kannst du auch mit
<ip-des-Shelly>/rpc/Webhook.List anschauen.
Zum Testen das Intervall auf einen großen Wert stellen (damit das zyklische Update nicht dazwischen funkt) und den Shelly z.b. über App bedienen. Im Modul sollte die Änderung fast ohne Verzögerung sichtbar sein.
Jetzt bin ich mal gespannt...(leider klappt nur ganz selten so etwas auf Anhieb)
Re Nomenklatur:
Zitat von: RalfRog am 15 Juli 2023, 18:39:56Andererseits bleibts mit http://<ip>/relay/0?turn=on|off für Gen1 und Gen2 gleich.
Wenngleich nicht dokumentiert ist das so. Und solange das nicht abgeschafft wird, ist es für das Modul einfacher, hier keinen Unterschied zu machen.
Zitat von: Starkstrombastler am 15 Juli 2023, 19:28:15Wenngleich nicht dokumentiert ist das so. Und solange das nicht abgeschafft wird, ist es für das Modul einfacher, hier keinen Unterschied zu machen.
Doch ist drin, deswegen bin ich drüber gestolpert. Finde auch, solange es funktioniert und es einfacher ist...
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Switch#http-endpoint-relayid
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Cover#http-endpoint-rollerid
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Light#http-endpoint-lightid
Aber das Wichtige-> Webhooks: ich konnte nicht erkennen (Shelly Oberfläche), dass etwas angelegt wurde.
=> Ich spiele noch mal.
was sagen denn die Readings? und das Logging?
Beim ShellyPlus2PM im Roller-Modus sieht das in der Shelly-Oberfläche beispielsweise so aus:
Plus2PMActions.JPG
Wenn das automatische Anlegen (noch) nicht funktioniert, kann man den Webhook natürlich auch manuell anlegen, indem z.B. für "Switch Toggled on" folgendes in das Feld für die URL geschrieben wird:
http://192.168.178.99:8083/fhem?XHR=1&cmd=set%20Y175%20out_on%200Die IP ist auf die IP des FHEM-Host zu ändern. Die %20 stehen für Leerzeichen. Der Befehl lautet also besser lesbar: set Y175 out_on 0
Die weiteren Events, die das Shelly-Modul verarbeitet, sind u.a.: out_off, button_on, button_off
Es kann natürlich schon sein, dass beim PlusPlug irgendetwas noch nicht passt, ich habe hier bei mir keinen zum Testen.
ShellyPlusPlug
1) Das Löschen des Attributs Webhooks hat die händisch anglegten Actions (Name mit _ ) gelöscht (im Log erkennbar).
=> [Shelly_Attr:webhook] PPlug: delete all hooks forwarding to this host and name starts with _ usw.
2) Neuanalge des Attributs Webhooks. Actions werden nicht angelegt (Kontrolle Shelly Oberfläche).
/rpc/Webhook.List = > {"hooks":[], "rev":28} (durch eigene Spielereinen ist rev vermutlich auf 28)
Log:
2023.07.15 19:51:19.716 3: [Shelly_Attr:webhook] PPlug command is set, attribute webhook old: NoVal new: WEB
2023.07.15 19:51:19.719 3: [Shelly_Attr:webhook] the webhook attribute is now WEB, create webhooks
2023.07.15 19:51:19.722 3: [Shelly_Attr:webhook] we will call Shelly_webhook for device PPlug, command is Create
2023.07.15 19:51:22.730 4: [Shelly_webhook] proceeding with command 'Create' for device PPlug
2023.07.15 19:51:22.734 4: [Shelly_webhook] device PPlug was called with command=Create
2023.07.15 19:51:22.737 4: [Shelly_webhook] device PPlug will be called by Webhook.
Log zyklisches Update
2023.07.15 20:00:15.300 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 20:00:15.303 4: [Shelly_webhook] device PPlug will be called by Webhook.
2023.07.15 20:00:15.307 4: [Shelly_webhook] issue a non-blocking call to http://11.12.13.14/rpc/Webhook.List
2023.07.15 20:00:15.316 4: [Shelly_shelly] PPlug: long update in 300 seconds
2023.07.15 20:00:15.424 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 20:00:15.429 4: [Shelly_webhook] processing the webhook data for command=Check
2023.07.15 20:00:15.432 4: [Shelly_webhook] our counter says 0 webhooks on shelly
2023.07.15 20:00:15.436 4: [Shelly_webhook_url] calling url-builder with args: PPlug 0 ch:0 noe:0
2023.07.15 20:00:15.500 4: [Shelly_webhook_url] the host-ip of PPlug is: 11.12.13.24
2023.07.15 20:00:15.504 4: [Shelly_webhook_url] FHEMweb-device is: WEB
2023.07.15 20:00:15.507 4: [Shelly_webhook_url] FHEMweb port is: 8083
2023.07.15 20:00:15.511 4: [Shelly_webhook_url] FHEMweb-device "WEB" has port "8083" and webname "fhem"
2023.07.15 20:00:15.514 4: [Shelly_webhook_url] the token-string is:
2023.07.15 20:00:15.518 4: [Shelly_webhook_url] PPlug: the fhem command is: "get PPlug status"
2023.07.15 20:00:15.521 4: [Shelly_webhookurl] PPlug: &urls=[%22%26cmd=get%2520PPlug%2520status%22]
Edit
Im ersten Durchgang hatte ich händisch etwas angelegt. Den hat er nach get status kaputt geschrieben.
Austausch: http://11.12.13.24:8083/fhem?cmd=set%2520Plug%2520on gegen http://11.12.13.24:8083/fhem?XHR=1
Hier der Log:
2023.07.15 19:23:14.007 4: [Shelly_proc2G] device PPlug processing component status
2023.07.15 19:23:14.012 4: [Shelly_proc2G:status] PPlug: processing the answer rpc/Shelly.GetStatus from Shelly_shelly()
2023.07.15 19:23:14.050 4: [Shelly_proc2G] device PPlug processing component info
2023.07.15 19:23:14.055 4: [Shelly_proc2G:info] PPlug: processing the answer rpc/Shelly.GetDeviceInfo from Shelly_shelly()
2023.07.15 19:23:14.064 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 19:23:14.068 4: [Shelly_webhook] processing the webhook data for command=Check
2023.07.15 19:23:14.072 4: [Shelly_webhook] our counter says 1 webhooks on shelly
2023.07.15 19:23:14.075 4: [Shelly_webhook_url] calling url-builder with args: PPlug 0 ch:0 noe:0
2023.07.15 19:23:14.137 4: [Shelly_webhook_url] the host-ip of PPlug is: 11.12.13.24
2023.07.15 19:23:14.141 4: [Shelly_webhook_url] FHEMweb-device is: WEB
2023.07.15 19:23:14.145 4: [Shelly_webhook_url] FHEMweb port is: 8083
2023.07.15 19:23:14.148 4: [Shelly_webhook_url] FHEMweb-device "WEB" has port "8083" and webname "fhem"
2023.07.15 19:23:14.151 4: [Shelly_webhook_url] the token-string is:
2023.07.15 19:23:14.155 4: [Shelly_webhook_url] PPlug: the fhem command is: "get PPlug status"
2023.07.15 19:23:14.159 4: [Shelly_webhookurl] PPlug: &urls=[%22%26cmd=get%2520PPlug%2520status%22]
2023.07.15 19:23:14.222 4: [Shelly_webhook] shellies PPlug webhook 0 is http://11.12.13.24:8083/fhem?cmd=set%2520Plug%2520on
2023.07.15 19:23:14.227 1: PERL WARNING: Use of uninitialized value $1 in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3747.
2023.07.15 19:23:14.230 1: PERL WARNING: Use of uninitialized value $2 in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3747.
2023.07.15 19:23:14.234 1: PERL WARNING: Use of uninitialized value $3 in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3747.
2023.07.15 19:23:14.238 1: PERL WARNING: Use of uninitialized value $4 in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3747.
2023.07.15 19:23:14.242 1: PERL WARNING: Use of uninitialized value $current_url_command in substitution (s///) at ./FHEM/36_Shelly.pm line 3750.
2023.07.15 19:23:14.246 1: PERL WARNING: Use of uninitialized value $current_url_command in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3752.
2023.07.15 19:23:14.249 4: [Shelly_webhook] 0 checking part1 of url:
http://:/?XHR=1 against
http://11.12.13.24:8083/fhem?XHR=1
command is: ""
2023.07.15 19:23:14.252 4: [Shelly_webhook] 0 we have to update http://:/?XHR=1 to http://11.12.13.24:8083/fhem?XHR=1
2023.07.15 19:23:14.256 1: PERL WARNING: Use of uninitialized value $current_url_command in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3756.
2023.07.15 19:23:14.260 4: [Shelly_webhook] PPlug: 0 issue a non-blocking call with callback-command "Updated":
http://11.12.13.14/rpc/Webhook.Update?urls=[%22http://11.12.13.24:8083/fhem?XHR=1%22]&id=1
2023.07.15 19:23:14.302 4: [Shelly_proc2G] device PPlug processing component config
2023.07.15 19:23:14.309 4: [Shelly_proc2G:config] PPlug: processing the answer rpc/Shelly.GetConfig from Shelly_shelly()
2023.07.15 19:23:14.755 4: [Shelly_webhook] device PPlug was called with command=Updated
2023.07.15 19:23:14.759 4: [Shelly_webhook] processing the webhook data for command=Updated
Ich fange nochmal an und verwende diese Schreibweise.
=> http://192.168.178.99:8083/fhem?XHR=1&cmd=set%20Y175%20out_on%200
CSRF-Token hatte ich zu Test deaktiviert.
Zumindest, dass initial nichts angelegt wird ist klar ;)
So Fazit zum PlusPlug
Statt vorher http://11.12.13.24:8083/fhem?cmd=set%20Plug%20on habe ich deinem Beitrag #463 folgend
neu die Schreibweise http://11.12.13.24:8083/fhem?XHR=1&cmd=set%20Plug%20on verwendet.
- beim definieren des Attributs webhooks werden kein keine Actions automatisch angelegt
- Actions ohne _ im Namen bleiben in Ordnung, egal wie geschrieben
- die Schreibweise der URL in den Actions mit "/fhem?XHR=1&cmd=set" wird nicht "kaputt" geschrieben (Ursache vermutlich der Token Mechanismus)
- bei aktivem CSRF-Token findet eine Aktualisierung der Actions mit dem Token statt
Die vorab angelegte Action wurde beim Anlegen des Attributs nicht verändert (der Namenskonvention folgend _Name_).
2023.07.15 20:25:15.558 4: [Shelly_shelly] PPlug is a second Gen device
2023.07.15 20:25:15.561 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetStatus
2023.07.15 20:25:15.569 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetConfig
2023.07.15 20:25:15.580 4: [Shelly_shelly] issue a non-blocking call to http://10.20.30.94/rpc/Shelly.GetDeviceInfo
2023.07.15 20:25:15.590 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 20:25:15.593 4: [Shelly_webhook] device PPlug will be called by Webhook.
2023.07.15 20:25:15.598 4: [Shelly_webhook] issue a non-blocking call to http://10.20.30.94/rpc/Webhook.List
2023.07.15 20:25:15.607 4: [Shelly_shelly] PPlug: long update in 300 seconds
2023.07.15 20:25:15.769 4: [Shelly_proc2G] device PPlug processing component info
2023.07.15 20:25:15.773 4: [Shelly_proc2G:info] PPlug: processing the answer rpc/Shelly.GetDeviceInfo from Shelly_shelly()
2023.07.15 20:25:15.782 4: [Shelly_proc2G] device PPlug processing component config
2023.07.15 20:25:15.787 4: [Shelly_proc2G:config] PPlug: processing the answer rpc/Shelly.GetConfig from Shelly_shelly()
2023.07.15 20:25:15.797 4: [Shelly_proc2G] device PPlug processing component status
2023.07.15 20:25:15.801 4: [Shelly_proc2G:status] PPlug: processing the answer rpc/Shelly.GetStatus from Shelly_shelly()
2023.07.15 20:25:15.832 4: [Shelly_webhook] device PPlug was called with command=Check
2023.07.15 20:25:15.836 4: [Shelly_webhook] processing the webhook data for command=Check
2023.07.15 20:25:15.839 4: [Shelly_webhook] our counter says 1 webhooks on shelly
2023.07.15 20:25:15.843 4: [Shelly_webhook_url] calling url-builder with args: PPlug 0 ch:0 noe:0
2023.07.15 20:25:15.905 4: [Shelly_webhook_url] the host-ip of PPlug is: 10.20.30.40
2023.07.15 20:25:15.909 4: [Shelly_webhook_url] FHEMweb-device is: WEB
2023.07.15 20:25:15.912 4: [Shelly_webhook_url] FHEMweb port is: 8083
2023.07.15 20:25:15.916 4: [Shelly_webhook_url] FHEMweb-device "WEB" has port "8083" and webname "fhem"
2023.07.15 20:25:15.919 4: [Shelly_webhook_url] the token-string is:
2023.07.15 20:25:15.923 4: [Shelly_webhook_url] PPlug: the fhem command is: "get PPlug status"
2023.07.15 20:25:15.926 4: [Shelly_webhookurl] PPlug: &urls=[%22%26cmd=get%2520PPlug%2520status%22]
2023.07.15 20:25:15.988 4: [Shelly_webhook] shellies PPlug webhook 0 is http://10.20.30.40:8083/fhem?XHR=1&cmd=set%2520Plug%2520on
2023.07.15 20:25:15.993 4: [Shelly_webhook] 0 checking part1 of url:
http://10.20.30.40:8083/fhem?XHR=1 against
http://10.20.30.40:8083/fhem?XHR=1
command is: "%26cmd=set%2520Plug%2520on"
2023.07.15 20:25:15.996 4: [Shelly_webhook] 0 check is OK, nothing to do
Die ganze Sache funktioniert aber von Handling her auch ohne Modul genau so (aus meiner Sicht). Liegt aber vermutlich an noch fehlenden Anteilen für den PlusPlug.
Die Readings "webhook_cnt" & "webhook_ver" könnten verwendet werden.
Nach Reaktivierung des CSRF-Tokens wird es beim nächsten zyklischen Update eingefügt. VORTEIL Modul -> Satz und Sieg ;D ;)
Bedingung: fhem?XHR=1&cmd=... (in der Hilfe erwähnenswert)
Was kann ich dir zuliefern?
Diese Logzeile ist hilfreich und führt zur Zeile 2128 in 36_Shelly.pm. Die Zeile muss wie folgt lauten:
my $comp = AttrVal($name,"mode","relay");
Damit läuft es jetzt, Danke.
Zitat von: RalfRog am 15 Juli 2023, 21:35:01Was kann ich dir zuliefern?
Ich fasse mal deine Testergebnisse wie folgt zusammen:
- Der Webhook-Mechanismus funktioniert vom Grundsatz her
- Es gibt noch einige Schwächen/Fehler im Code (allgemein oder speziell bzgl. ShellyPlug)
- Die Bedeutung der ACTIONS der Shellies dürfte vielen Nutzern unbekannt sein.
zu 1.
Grundlagen sind in der Hilfe/Commandref dargestellt, aber wahrscheinlich viel zu "spröde". Der Mechanismus kann wahrscheinlich im FhemWiki "Modul Shelly" besser dargestellt werden.
--> Ich werde mir mal eine tiefergehende Struktur für den Artikel überlegen, Vorlagen gibt's wahrscheinlich reichlich. Vorschläge?
zu 2.
Punkt für Punkt abarbeiten. Ich selbst habe auch ein unerwünschtes Verhalten ("kaputt schreiben") im Zusammenhang mit dem Löschen von Devices entdeckt.
--> Fehler beheben --> neues Update
zu 3.
Das Thema ist an sich unabhängig von Fhem, da mit den Actions die Shellies untereinander oder auch mit anderen Geräten/Systemen kommunizieren können. Das schließt auch die Shellies der 1. Gen mit ein. Ich kann mir dafür einen eigenen Artikel im FhemWiki vorstellen. Wahrscheinlich findet man im Netz auch brauchbare Vorlagen.
--> das ist eine Einladung an die Community!
Hallo,
Ich habe die Vermutung, daß die Modelle irgendwie nicht gleich behandelt werden:
Ein shellyplus1pm:
Readings:
relay on 2023-07-15 10:08:58
state on 2023-07-15 17:35:07
bei state würde ich gerne OK sehen!
Ein shellyplus2pm:
Readings:
relay_0 on 2023-03-09 11:36:59
relay_1 on 2023-03-09 11:36:59
state OK 2023-07-16 11:46:02
Bei shellyplus1:
Readings:
relay off 2023-07-16 09:29:19
state off 2023-07-16 09:29:19
Auch hier bei state würde ich gerne OK sehen!
Das state reading ist doch der Status des Shelly oder sehe ich das falsch?
Könnte man das vereinheitlichen? Oder ist das so gewollt?
EDIT:
Als Erweiterung wären noch jeweils die Namen vom Shelly selbst mit Input und Output Namen als reading nicht schlecht.
Gruß
Hubert
Zitat von: carlos am 16 Juli 2023, 11:53:03Das state reading ist doch der Status des Shelly oder sehe ich das falsch?
Könnte man das vereinheitlichen? Oder ist das so gewollt?
Nun, was ist der Status?
Allgemein wird in Fhem das reading 'state' auf das Internal 'STATE' abgebildet, und dieses wiederum mittels devStateIcon grafisch dargestellt.
Das funktioniert aber nicht so einfach, wenn ein Gerät mehrere Kanäle hat (z.B. Shelly2.* im Relay-Modus). Hier muss der User das Verhalten mittels dem Attribut 'stateFormat' festlegen.
Insofern ist das beschriebene Verhalten genau so wie es sein soll.
Zitat von: carlos am 16 Juli 2023, 11:53:03Als Erweiterung wären noch jeweils die Namen vom Shelly selbst mit Input und Output Namen als reading nicht schlecht.
Naheliegend wäre es, den Namen des Shelly (aus Device Info des Shelly) mittels Attribut mit dem Namen des Fhem-Devices gleich zu schalten. Kommt mit dem nächsten Update.
Bei den Namen der Eingänge, Ausgänge bzw. Kanäle allgemein müssten das Attribut 'defchannel' und angelegte Proxy-Devices berücksichtigt werden. Das wird etwas länger dauern...
Hallo zusammen,
was muß man denn einstellen, wenn man vom shellyplus1pm die Meßreadings haben möchte (power usw.)?
Wenn man einen shellyplus1pm als fhem Device anlegt, kriegt er automatisch das model shellyplus1pm verpaßt. Wenn ich das model einmal auf generic umstelle und dann wieder shellyplus1pm auswähle, kommen auf einmal mehr Attribute, die man aber nicht verwenden kann. Wenn ich versuche, wie im Wiki empfohlen, mode auf "relay" zu stellen, kommt die Meldung, das sei für dieses Device nicht möglich.
Beim shellyplug z.B. tauchen die Meßreadings automatisch nach dem Define auf.
Gruß Roland
Hallo Roland,
es gibt noch einen kleinen Bug in der aktuellen Version, den kannst du durch Ändern in der Zeile 2128 der 36_Shelly.pm leicht ändern, siehe Beitrag hier:
Zitat von: benz_freak am 16 Juli 2023, 11:16:32Diese Logzeile ist hilfreich und führt zur Zeile 2128 in 36_Shelly.pm. Die Zeile muss wie folgt lauten:
my $comp = AttrVal($name,"mode","relay");
Wenn du das änderst, kommen alle Readings automatisch herein. Damit es besser lesbar ist, kannst du noch z.B.
attr <name> showunits normal2 festlegen (wird mit der nächsten Aktualisierung sichtbar).
Der Bug wird mit dem nächsten Update behoben.
Es wird stets die Möglichkeit angeboten, einen Shelly als model generic zu betreiben und dann werden alle Attribute sichtbar. Beim Zurückgehen auf das tatsächliche model werden die Attribute nicht erneut ausgeblendet. Das kannst du erreichen, indem das Device mittels DEF oder defmod ... neu definiert wird.
Die Empfehlung im Wiki bezieht sich im Übrigen auf die diversen Shelly2, weil die tatsächlich im relay oder roller mode betrieben werden können.
ShellyPlug ist mit Firmware der 1. Gen, das wird im Modul separat behandelt.
Zitat von: Starkstrombastler am 15 Juli 2023, 10:29:11Zitat von: curt am 15 Juli 2023, 01:34:54Real fehlt (mir) ein reading, welches die Zustände "fährt hoch", "fährt runter", "nix passiert" haben kann. Falls es das schon gibt habe ich es übersehen.
schau dir mal das Reading 'state' an: es nimmt beim Fahren die Werte 'drive-up' bzw. 'drive-down' an. Und im Stillstand zeigt es die ungefähre Position in der Form 'pct-ii'.
Ist nicht ganz ideal, aber das nehmen wir. Und damit spätere Nutzer auch etwas davon haben, beschreibe ich meinen Weg und das Ergebnis - es geht um die Einbindung in FTUI3. Hinweis: Das ist ein Template für FTUI3, ich habe ja viele einzubindende Rollläden...
Ausgangsbedingung ist, dass ich eine ganze Anzahl von Rollläden habe. Weiterhin gibt es in diesem Haus ein Nutzerverhalten, was für Rollläden nur die Zustände "auf" und "zu" gibt; das heißt, dass für die Bewohner ein halb geöffneter Rollladen im realen Leben als Fehlerzustand gilt.
Rechts gibt es Knöpfe für "aufmachen" und "zumachen", die Farbe signalisiert, welche Richtung sinnvoll ist: Wenn der Rollladen schon zu ist, ist "zumachen" ausgegraut. Links ist der Zustand des Rollladen, darauf kann man zudem auch klicken, dann wird "Stop" ausgelöst.
Hier der FTUI3-Code:
<ftui-row>
<ftui-label margin="-1px 0 0 0" class="size-0">{{Roll_Name}}</ftui-label>
</ftui-row>
<ftui-row>
<ftui-column>
<ftui-row>
<ftui-icon margin="0 -15px 0 0" size="3" @click="javascript:sendFhem('set {{Roll}} stop')"
[name]="{{Roll}}:state | map('drive-up:arrow-up, drive-down:arrow-down, pct-0:window-shutter, pct-100:window-shutter-open, .*:window-shutter-alert')"
[color]="{{Roll}}:state | map('drive-up:my_signalgreen, drive-down:my_signalgreen, pct-0:my_blue, pct-100:my_yellow, .*:my_signalred')">
</ftui-icon>
</ftui-row>
</ftui-column>
<ftui-column>
<ftui-row>
<ftui-button [(value)]="{{Roll}}"
states="open" fill="none">
<ftui-icon margin="-1px -10px 0 0" name="arrow-circle-up" class="size-0"
[color]="{{Roll}}:state | map('pct-0:my_green, pct-100:my_grey2, pct-.*:my_green, .*:my_grey2')">
</ftui-icon>
</ftui-button>
</ftui-row>
<ftui-row>
<ftui-button [(value)]="{{Roll}}"
states="closed" fill="none">
<ftui-icon margin="-1px -10px 0 0" name="arrow-circle-down" class="size-0"
[color]="{{Roll}}:state | map('pct-0:my_grey2, pct-100:my_green, pct-.*:my_green, .*:my_grey2')">
</ftui-icon>
</ftui-button>
</ftui-row>
</ftui-column>
</ftui-row>
Der Aufruf des Templates:
<ftui-grid-tile row="2" col="8" height="1" width="1" color="my_grey3">
<ftui-content file="./roll_unten/template_rollladen.html"
Roll_Name="Terrasse links"
Roll="Roll_WZ_Terrasse_links">
</ftui-content>
</ftui-grid-tile>
Zitat von: Starkstrombastler am 16 Juli 2023, 11:48:19- Der Webhook-Mechanismus funktioniert vom Grundsatz her
zu 1.
Grundlagen sind in der Hilfe/Commandref dargestellt, aber wahrscheinlich viel zu "spröde". Der Mechanismus kann wahrscheinlich im FhemWiki "Modul Shelly" besser dargestellt werden.
--> Ich werde mir mal eine tiefergehende Struktur für den Artikel überlegen, Vorlagen gibt's wahrscheinlich reichlich. Vorschläge?
Da biete ich mich doch glatt als Testuser, als Versuchskaninchen an:
* Ich würde gern wissen, was das eigentlich ist - es sind wohl verschiedene URL, die bezogen auf die IP des Shelly irgendwas auslösen. Damit ergibt sich die erste Frage: Wofür könnte man das brauchen? Kann das was, was man über FHEM nicht kann? Oder worin liegt der Vorteil?
* Wenn ich die URL genutzt habe, gibt es (las ich im Augenwinkel) ein Feedback. Wie sieht das aus? Was kann ich damit anstellen?
* Wichtig ist zudem ein simples, sofort einleuchtendes Beispiel.
Hoffe geholfen zu haben.
Zitat von: curt am 17 Juli 2023, 02:43:43Ich würde gern wissen, was das eigentlich ist - es sind wohl verschiedene URL, die bezogen auf die IP des Shelly irgendwas auslösen.
Zur Erläuterung zitiere ich mal aus der Wikipedia (https://de.wikipedia.org/wiki/Remote_Procedure_Call):
Remote Procedure Call (RPC; englisch für ,,Aufruf einer fernen Prozedur") ist eine Technik zur Realisierung von Interprozesskommunikation. Sie ermöglicht den Aufruf von Funktionen in anderen Adressräumen. Im Normalfall werden die aufgerufenen Funktionen auf einem anderen Computer als das aufrufende Programm ausgeführt.In einfachen Worten: Das wird vom Shelly-Modul zur Kommunikation zwischen Fhem und den Shellies benutzt. Dazu sendet Fhem eine Anfrage an den Shelly, und dieser liefert eine Antwort. Das ganze in einem festen Intervall, z.B. 60 Sekunden (Polling).
Die Shellies bieten aber auch die Möglichkeit bei Eintreten bestimmter Ereignisse von sich aus Meldungen abzusetzen, auf den Shellies nennt sich dies
actions.
Beispiel Ereignis: Ein am Shelly angeschlossener Schalter wurde betätigt
Ergebnis: Der Ausgang (Relais) des Shelly wurde eingeschaltet
Action: Der Shelly sendet eine Meldung an ein anderes Gerät (Shelly, Fhem, oder etwas anderes)
Die Action muss aber auf dem Shelly hinterlegt sein, wie sonst soll der Shelly wissen, was zu tun ist?
Und genau daraum kümmert sich der Webhook-Mechanismus im Shelly-Modul: Für alle Ereignisse, welche die diversen Shellies kennen, werden Meldungen in Richtung Fhem auf dem Shelly angelegt (URLs). Das hat den Vorteil, dass die Informationen nicht erst beim nächsten Polling, sondern sofort bei Fhem ankommen.
Zur Illustration stelle man sich einmal eine Bestandinstallation mit einem 230V Bewegungsmelder vor. Dessen Ausgang wird an einen
detached Eingang eines Shelly angeschlossen. Eine auf dem Shelly angelegte Action sendet eine URL an Fhem und Fhem kann mit den gewohnten Methoden reagieren. Im Beispiel wird der Ausgang des Shelly eingeschaltet, sofern es Nacht ist.
anderes Beispiel:
Nutzer betätigt Taste am Rollo -> Rollo fährt hoch -> Shelly meldet an Fhem 'Rollo fährt hoch'
Rollo kommt oben an -> Shelly meldet an Fhem 'Rollo geöffnet'
Der Webhook-Mechanismus des Shelly-Moduls ist derzeit noch in Entwicklung, es gibt noch ein paar Stellen wo es noch nicht richtig läuft. Aber wenn es dann funktioniert, muss sich ein Nutzer nicht zwangsläufig damit beschäftigen.
Zur Vollständigkeit muss aber noch erwähnt werden, dass die Shellies auch noch die Protokolle MQTT und ColoT (nur Gen1) beherrschen, aber diese sind nicht Bestandteil des hier diskutierten Shelly Moduls.
Hi
Curt schau dir das mit den Actions mal direkt auf dem Shelly an.
Ich hätte folgende Anwendung:
Ich nutze einen 1PM (Gen1) um den Ertrag meines BKW zu messen. Man kann den Eingang SW vom Shelly unabhängig vom Relais (Stichwort Detach) betreiben. Das tue ich - ein Reed-Kontakt gibt den Zustand des Garagentors auf SW weiter.
So kann ich den Zustand des Tores sehen. Abhängig davon wie das Poll-Intervall eingestellt ist - mehr oder weniger schnell.
Wenn man nun nicht jede Minute pollen möchte kann man eine Action auf dem Shelly hinterlegen. Sobald sich der Zustand am SW-Eingang ändert meldet der Shelly spontan und selbständig.
In meinem Fall könnte er dann per URL (Action im Shelly) etwas an Fhem senden (CSRF Token Problematik beachten)
http://FHEM-IP:8083/fhem?XHR=1&cmd=setreading Tor offen
Starkstrombastler unterstützt das mit dem Webhook-Mechanismus.
Er schaut unter anderem nach ob eine Action hinterlegt ist und korrigiert wenn nötig die hinterlegte URL - ergänzt z. B. das gerade aktuelle Token.
Gruß Ralf
Ich danke euch beiden für die Erklärung. Eigentlich wollte ich dazuschreiben, dass damit ein Teil des Wiki-Artikels schon geschrieben ist ... bis mir auffiel, dass die Problematik ja auch auf shellyplus2pm zutrifft: Die Teuerste bedient den Rolladen vom Tastenfeld. Gna.
Ich befürchte, ich werde auch ganz praktisch Versuchskaninchen. Aber nicht gleich heute ... die nächsten Tage.
Hallo zusammen,
ich habe einen Shelly Plus 1 per Shelly Modul angebunden. Im Shelly sind Action-URLs hinterlegt, um das Schalten des Relays und des (detached) Eingangs ("Button") an fhem zu signalisieren. Fhem selbst fragt den Shelly zusätzlich alle 60 Sekunden ab.
Was ich nicht hinbekomme, ist den Zustand der Readings button und relay sauber zu loggen - event-min-interval interessiert meinen Shelly nicht, es werden nach der eingestellten Zeit keine Events generiert und es landet nichts im FileLog. Für event-on-change und event-on-update habe ich unterschiedliche Einstellungen versucht, hat am Ergebnis nichts geändert.
Es werden nur state und inttemp regelmässig ins FileLog geschrieben, relay und button nicht. Und ich würde diese beiden Readings gerne einmal in der Minute sehen, auch wenn sie sich nicht geändert haben.
Damit mein Plot nicht abreißt, habe ich im FileLog
addLog Haustuer:button.*:60,Haustuer:relay.*:60
gesetzt, damit die Einträge dort auftauchen, aber das Verhalten von event-min-interval verstehe ich nicht.
Hätte jemand eine Erklärung parat?
Danke,
Sebastian
Internals:
DEF 192.168.251.40
DURATION 0
FUUID 643c0fc6-f33f-4699-c064-6862c9486b3b5bc9
INTERVAL 60
NAME Haustuer
NR 871
STATE Öffner
1:off
Schloss
2:on
Empfang
3:OK
TCPIP 192.168.251.40
TYPE Shelly
eventCount 94491
READINGS:
2023-07-19 15:02:32 button on
2023-07-19 15:24:22 inttemp 53.3
2023-07-19 04:01:47 network <html>connected to <a href="http://192.168.251.40">192.168.251.40</a></html>
2023-07-19 15:03:50 relay off
2023-07-19 15:24:22 state OK
Attributes:
comment devStateIcon = 1.on:10px-kreis-gruen:noFhemwebLink 1.off:10px-kreis-weiss:noFhemwebLink 2.on:10px-kreis-gruen:noFhemwebLink 2.off:10px-kreis-rot:noFhemwebLink 3.OK:10px-kreis-gruen:noFhemwebLink 3.*:10px-kreis-rot:noFhemwebLink .*::
stateFormat = {sprintf("Relay\n1:%s\nButton\n2:%s\nStatus\n3:%s", ReadingsVal($name,"relay","0"), ReadingsVal($name,"button","0"), ReadingsVal($name,"state","0"))}
devStateIcon 1.on:10px-kreis-gruen:noFhemwebLink 1.off:10px-kreis-weiss:noFhemwebLink 2.on:10px-kreis-gruen:noFhemwebLink 2.off:10px-kreis-rot:noFhemwebLink 3.OK:10px-kreis-gruen:noFhemwebLink 3.*:10px-kreis-rot:noFhemwebLink .*::
event-min-interval .*:60
group Haustür
interval 60
model shellyplus1
room EG,Status
shellyuser admin
stateFormat {sprintf("Öffner\n1:%s\nSchloss\n2:%s\nEmpfang\n3:%s", ReadingsVal($name,"relay","0"), ReadingsVal($name,"button","0"), ReadingsVal($name,"state","0"))}
userReadings button
webCmd :
Hallo
Um Events zu loggen müssen sie überhaupt erstmal erzeugt werden. Die Event* Attribute filtern die Events - wenn kein Event da war hilft auch keines der Attribute es her zu zaubern.
(andersherum wird ein Schuh draus: wenn alle 15 sek. ein Event entsteht würdest du mit "event-min-interval .*:60" dafür sorgen, dass es nur alle min. 60 sek. durchkommt und geloggt wird)
Ich meine beim OriginalModul irgendwo in den Erklärungen von PAH gelesen zu haben, dass intern im Modul nur dann Events erzeugt werden wenn die ausgelesenen Werte sich geändert haben. Da gibt es wohl unterschiedliche Funktionen (readingsBulkUpdateIfChanged) in FHEM für die Developer.
Wenn Starkstrombastler das Modul-Gerüst so belassen hat, wird sich daran nichts geändert haben.
Ich habe an meinem Shelly1PM gerade nachgeschaut. Das Reading relay hat auch einen "alten" Zeitstempel 3.6 (firmware sogar 16.5.).
Zitat von: RalfRog am 19 Juli 2023, 17:59:22Um Events zu loggen müssen sie überhaupt erstmal erzeugt werden. Die Event* Attribute filtern die Events - wenn kein Event da war hilft auch keines der Attribute es her zu zaubern.
(andersherum wird ein Schuh draus: wenn alle 15 sek. ein Event entsteht würdest du mit "event-min-interval .*:60" dafür sorgen, dass es nur alle min. 60 sek. durchkommt und geloggt wird)
sie werden ja erzeugt und landen im FileLog, nur halt selten. Und ich hätte gerne zwei der Readings wiederholt alle 60 Sekunden...
Zitat von: spi3845 am 19 Juli 2023, 18:12:21sie werden ja erzeugt und landen im FileLog, nur halt selten. Und ich hätte gerne zwei der Readings wiederholt alle 60 Sekunden...
Wenn selten z.B. alle 4 Stunden ist geht es nicht öfter als alle 4 Stunden oder das Modul muss umgeschrieben werden.
Das umgehst du ja mit der Ergänzung "addLog Haustuer:button.*:60,Haustuer:relay.*:60" um alle 60 Sekunden den letzten Wert nochmal zu schreiben.
Edit:
Oder du definierst mit JsonMod eine neues Device um den Shelly auszulesen.
Dann bekommst du die Werte ausgelesen sooft du pollst.
Beispiel Gen2
define shly JsonMod http://<IP>/rpc/Shelly.GetStatus/
--------------------------------
Ich habe im Livesystem noch das Originalmodul und hole den Zustand des Button für Shelly1PM alle 5 Minuten / es ist so definiert:
define shly JsonMod http://<IP>/status/
attr shly interval */5 * * * *
attr shly readingList single(jsonPath('$.inputs[0].input'),'Tor_Status');single(jsonPath('$.inputs[0].event_cnt'),'Tor_Count');
Hier war auch ein Beispiel Beiträge #426 #427
https://forum.fhem.de/index.php?msg=1279638
Zitat von: RalfRog am 19 Juli 2023, 17:59:22Ich meine beim OriginalModul irgendwo in den Erklärungen von PAH gelesen zu haben, dass intern im Modul nur dann Events erzeugt werden wenn die ausgelesenen Werte sich geändert haben. Da gibt es wohl unterschiedliche Funktionen (readingsBulkUpdateIfChanged) in FHEM für die Developer.
Wenn Starkstrombastler das Modul-Gerüst so belassen hat, wird sich daran nichts geändert haben.
Genau so ist das. Es gibt mehrere Möglichkeiten Events zu erzeugen. Im Modul werden die meisten Readings aber nur dann erzeugt, wenn sich deren Wert verändert hat. Dann nützen auch die diversen Attribute nichts - ohne Updates keine Events.
Auf der anderen Seite kann man bei jedem Update ein Event erzeugen. Es ist dann Aufgabe des Users, die Flut an Events mittels passend gesetzter Attribute einzudämmen. Bei großen Systemen und schwacher Hardware könnte das aber zum Problem werden.
Welche Readings sollten denn so, und welche anders behandelt werden? Wenn sich eine einfache Regel formulieren lässt, wäre das dann für alle Nutzer nachvollziehbar.
Vorschlag: "Systemreadings" (cloud, network, firmware, config) erzeugen nur bei Änderung ein Event
"zyklische Readings", also alle anderen, erzeugen bei jedem zyklischen oder azyklischen Update ein Event
Es bleiben einige Readings, die nur durch Actions/Webhooks gepusht werden (z.B. input...). Die ändern z.T. noch nicht einmal ihren Status (z.B. ein Taster der immer wieder "short-push" liefert).
Uhhh schwierige Frage... ::)
Bisher komme ich (spreche natürlich nur für mich) mit dem aktuellen Verhalten gut zurecht.
Hängt aber sicher stark davon ab was man machen möchte (z.B. alle 60 sek. Button/Relaiszustand ins Log schreiben) und wie man das (sinnvoll) erreichen kann - Beispiel spi3845 der sich statt per gewünschtem Event mit addLog beholfen hat.
Da mag der ein oder andere mit mehr Hintergundwissen und Gefühl für FHEM fundierter eine Aussage treffen können (ich nehme an PAH hatte Gründe für die Verwendung von "readingsBulkUpdateIfChanged").
Insbesondere beim Shelly 3EM kann ich mich seit Jahresanfang an einige Beiträge erinnern (weiss nur nicht mehr ob Modul oder MQTT) die die Datenflut und deren Eindämmung zum Thema hatten.
Ich habe nicht die ganze Gerätefamilie im Kopf - im Prinzip kommt ja für alles mit Messwerten eher häufig (abhängig vom Pollintervall) ein Event mit verändertem Wert (Power, Energie, Voltage, Current etc.). Andererseits verhindern zyklische Powerwerte besonders 0 Watt Plotabrisse.
-> Da muss man sowieso überlegen was man wie häufig haben/loggen will.
Relais und Buttons etc. sind demgegenüber deutlich träger und oft von geringerer Anzahl - wobei, beim 1PM-Gen1 verdoppelt sich mit zyklischen Updates die Anzahl der Readings mit vielen Events.
Gar nicht so einfach die passende Strategie zu finden - zählen zu Systemreadings auch inttemp*, overpower, source, timer, reason, protection.
Edit:
Auf der anderen Seite, wenn man die Pollintervalle nicht so ultrakurz haben möchte wäre MQTT wohl der Ausweg, da die Shellys darüber ihre Änderungen spontan und selbständig absetzen.
Zitat von: Starkstrombastler am 19 Juli 2023, 22:20:34Genau so ist das. Es gibt mehrere Möglichkeiten Events zu erzeugen. Im Modul werden die meisten Readings aber nur dann erzeugt, wenn sich deren Wert verändert hat. Dann nützen auch die diversen Attribute nichts - ohne Updates keine Events.
Ah, ok - dann hatte ich da einen Denkfehler. Ich bin davon ausgegangen, dass nach event-min-interval Sekunden ein Event generiert wird - und zwar unabhängig davon, ob es ein Update oder eine Änderung bei dem entsprechenden Reading gab. Hoffentlich verstehe ich das jetzt richtig, dass der Event ausgelöst wird, sofern es ein Update oder Änderung des Readings gab und mindestens event-min-interval Sekunden vergangen sind. Ich kann das Wiki immer wieder lesen und finde immer wieder Neues ;D
Zitat von: RalfRog am 19 Juli 2023, 23:22:07Edit:
Auf der anderen Seite, wenn man die Pollintervalle nicht so ultrakurz haben möchte wäre MQTT wohl der Ausweg, da die Shellys darüber ihre Änderungen spontan und selbständig absetzen.
Das mache ich auch mit allen anderen Shellies - nur diesen einen wollte ich nicht über MQTT anbinden. Wenn jemand die Pollintervalle nicht so kurz haben möchte, könnte er auch auf dem Shelly ein Script hinterlegen, das seinen Status regelmässig analog den Action-URLs an fhem sendet. Habe das für einige per MQTT angebundene Gen2-Shellies gemacht, um ein Verhalten der Gen1 zu imitieren (oder umgekehrt, erinnere mich nicht mehr ;)).
Hallo,
mit der letzten Version werden beim shelly Plus 2PM die urls der actions verändert.
Die IP wird gelöscht, es bleibt nur mehr "8084&cmd=get%20shelly_Bad_LiLu%20status%20" über.
Außerdem hat sich immer das devStateIcon rot verfärbt wenn eine Rollo gerade fährt. Das scheint jetzt auch nicht mehr zu funktionieren.
Habe jetzt die vorletzte Version 2023-05-06 in Verwendung und die pct Zeile abgeändert. Jetzt funktioniert wieder alles
Zitat von: bene80 am 26 Juli 2023, 21:10:01Die IP wird gelöscht, es bleibt nur mehr "8084&cmd=get%20shelly_Bad_LiLu%20status%20" über.
Hallo bene80, diesen Fehler habe ich auch schon gesehen, nur weiß ich noch nicht, wie er überhaupt entsteht. Wurde der Fhem-Server neu gestartet? Wurde die Action mittels des Attributs "webhook" generiert oder war das ein manueller Eintrag?
Was meinst du mit "die pct Zeile abgeändert"?
Hi, ich habe die Actions direkt im Shelly eingetragen.
Gestartet habe ich nichts neu. Es dauert auch nicht lange bis die Action geändert wird
Der Slider für Pct war ja bis zur letzten Version ausgeblendet. Das habe ich jetzt selber geändert.
LG Bernhard
Hallo,
ich hatte einen defekten Shelly 2.5 den ich heute durch einen Shelly 2 Plus PM ersetzt habe. Nun habe ich das Problem das das Modul das neue Model noch nicht kennt und dieser daher nicht funktioniert.
Weis zufällig jemand wie den neuen Shelly mit dem 36_Shelly Modul trotzdem ans laufen bekomme?
VG
Hallo Michi,
du musst die Version welche hier vor kurzem gepostet wurde verwenden. Die offizielle kennt glaube ich die neuen Shellies noch nicht
SG Bernhard
Zitat von: bene80 am 02 August 2023, 15:45:00Hallo Michi,
du musst die Version welche hier vor kurzem gepostet wurde verwenden. Die offizielle kennt glaube ich die neuen Shellies noch nicht
SG Bernhard
Vielen Dank für die Info!
Weist du evtl. noch auf welcher Seite das zu finden ist? ;D
::EDIT::
Habs gefunden Danke !!!
Hallo Shelly-Fans,
es gibt wieder ein Update des Shelly-Moduls
Neben einigen Korrekturen gibt es diese Neuerungen:
Attribut "ShellyName": Mit diesem Attribut wird der im Shelly gespeicherte Name in Fhem zur Verfügung gestellt. Ist im Shelly kein Name vorhanden, wird der Name des Fhem-Devices genutzt. Der Name kann mit diesem Attribut vom User geändert werden.
Attribut "Periodes" (nur für ShellyPro3EM): Es können mehrere Zeit-Perioden ausgewählt werden, zu denen die Total-Energy-Readings aggregiert werden:
Minuten, Stunden, Tage, Wochen sowie Viertelstunden, 6-Stunden und 8-Stunden. Die Readings werden immer zu vollen Minuten, Stunden etc. angelegt. Für die Perioden Tag und Woche werden Sommerzeit/Winterzeit und Zeitzone MEZ zu Grunde gelegt.
Wichtig: Da der Shelly Zähler nicht über die Phasen hinweg saldiert, entstehen in Perioden, in denen auf den Phasen zeitgleich unterschiedliche Energierichtungen bestehen, Abweichungen zu geeichten (saldierenden) Zählern.
Hallo,
leider habe ich mit den neuen Shelly Plus2PM immer noch Probleme. Es tut sich nichts...
Die Shelly 2.5 laufen einwandfrei mit der neusten Version.
state Error: JSON
network invalid JSON data
Hallo Michi1978,
bitte sicher stellen, dass die neuen Shelly die aktuelle Firmware haben.
Wurde der ShellyPlus2PM als neues Device angelegt?
Das kannst du auf jeden Fall auch parallel zu schon bestehenden Definitionen probieren:
define neuerName IP-des-Shelly
Zitat von: Starkstrombastler am 03 August 2023, 12:12:18Hallo Michi1978,
bitte sicher stellen, dass die neuen Shelly die aktuelle Firmware haben.
Wurde der ShellyPlus2PM als neues Device angelegt?
Das kannst du auf jeden Fall auch parallel zu schon bestehenden Definitionen probieren:
define neuerName IP-des-Shelly
Du hast Recht!
Nachdem ich die Shelly's gelöscht und neu eingefügt habe scheint es problemlos zu funktionieren.
Danke für deine Arbeit!
VG
Michael
Mal eine Frage an die Entwickler, die dankenswerterweise das Shelly-Modul weiterentwickeln:
Ich habe mehr als als 10 Shellies - alles "alte" mit Ausnahme eines Shelly plus 1PM, der ja mit dem Standardmodul funktioniert.
Jetzt habe ich einen Shelly plus 2PM angeschaft. Muss ich alle Devices neu anlegen, wenn ich jetzt die neue Version des Moduls testen will?
Zitat von: JWRu am 04 August 2023, 08:40:15Mal eine Frage an die Entwickler, die dankenswerterweise das Shelly-Modul weiterentwickeln:
Ich habe mehr als als 10 Shellies - alles "alte" mit Ausnahme eines Shelly plus 1PM, der ja mit dem Standardmodul funktioniert.
Jetzt habe ich einen Shelly plus 2PM angeschaft. Muss ich alle Devices neu anlegen, wenn ich jetzt die neue Version des Moduls testen will?
Also ich habe die device aus der fhem.cfg kopiert, dann gelöscht. Neustart, dann wieder in die Fhem.cfg eingefügt und gespeichert. Danach liefen die beiden wieder auf Anhieb.
Vielleicht hilft es dir ja auch
ZitatAlso ich habe die device aus der fhem.cfg kopiert, dann gelöscht.
Ich nutze configdb. Ich würde auch niemals in der fhem.cfg rumfummeln.
Ich musste nichts neu anlegen, nur den einen 2.5er der gegen den plus 2PM ausgetauscht wurde habe ich neu definiert
Zitat von: bene80 am 04 August 2023, 13:09:55Ich musste nichts neu anlegen, nur den einen 2.5er der gegen den plus 2PM ausgetauscht wurde habe ich neu definiert
Das hört sich gut an - ich werde es mal versuchen.
Hallo Bernhard,
Vielen Dank für deine Arbeit. Habe jetzt die letzte Version installiert. Webhook funktioniert jetzt auch, meine actions werden nicht mehr abgeschnitten.
Mir ist folgendes Aufgefallen
Attribut "ShellyName":
Hat der Name im Shelly ein Leerzeichen wird alles nach dem Leerzeichen abgeschnitten.
Alte Shellys funktionieren, man kann den Namen im modul mit dem attribut setzen.
Bei einem shellyplus2pm wird der Name ausgelesen, geändert wird er aber nicht, wenn man ihn im Modul ändert
Bei einem shellyrgbw2 habe ich folgendes Verhalten:
attr shelly_KiZi_RGB webCmd white:rgb:rgb ff0000:rgb 00ff00:rgb 0000ff
fhem_rgb_led.png
Wenn ich den slider für den weißen Kanal setze und danach den shelly einschalte, springt der slider wieder zurück auf 0. Der shelly schaltet aber mit dem Wert vom Slider ein. Beim rgb slider für die Helligkeit passiert das nicht. Schalte ich den shelly aus und wieder ein, behält der weiße Kanal den Wert der eingestellt war, bevor der shelly ausgeschaltet wurde. Ich muss dann den slider kurz bewegen damit der neue Wert übernommen wird. Ist das so gewollt oder mache ich etwas falsch?
SG Bernhard
Ich habe für die Steuerung eines Rollladens einen Shelly plus 2 PM und möchte ihn in FHEM einbinden.
Bei dem Attribut model steht im Dropdownmenu shellyplus2pm nicht zur Verfügung. Aktuell verwende ich als model shelly2.5. Mit diesem lässt sich auch der Rollladen schalten, doch ich erhalte im Status die Meldung ERROR.
Ich habe alle Optionen im Dropdownmenu für model ausprobiert und erhalte immer im Status ERROR.
Kennt jemand eine Lösung?
Internals:
DEF 192.168.15.39
DURATION 0
FUUID 64d37e5f-f33f-11f5-2f25-1037d2ddc18b6e90
INTERVAL 15
NAME Balkon_Mitte
NR 1390
STATE Error
TCPIP 192.168.15.39
TYPE Shelly
eventCount 4
READINGS:
2023-07-12 20:12:50 cloud enabled(connected)
2023-05-11 19:59:26 firmware v1.13.0
2023-07-14 02:56:35 inttemp 52.57
2023-08-10 11:07:42 network <html>connected to <a href="http://192.168.15.39">192.168.15.39</a></html>
2023-08-10 09:25:17 overpower_0 0
2023-08-10 09:25:17 overpower_1 0
2023-08-10 09:25:17 relay_0 off
2023-08-10 09:25:17 relay_1 on
2023-08-10 11:08:42 state Error
Attributes:
defchannel 1
interval 15
mode relay
model shelly2.5
room Balkon_unten
shellyuser admin
verbose 0
Hallo Elgardo,
probier mal folgendes:
- lösche die Attribute model und mode
- betätige die DEF Taste in der Webansicht, oder als Kommando defmod name ip-des-Shelly
Der Shelly wird dadurch neu definiert und die Auto-Erkennung erkennt, dass es sich um ein Gen2-Modell handelt.
Voraussetzung ist, dass der Shelly bereits fertig eingerichtet ist und sich über die App oder Web bedienen lässt.
Und natürlich die aktuelle (Test-) Version des Moduls (https://forum.fhem.de/index.php?action=dlattach;attach=172485).
Hallo zusammen,
ich hab für ein neues Projekt ein Auge auf die Shelly Pro geworfen.
Der Pro2 oder Pro3 könnten mir gut ins Konzept passen.
Nun ist in der Tabelle im Wiki lediglich von Pro4 die Rede, und auch im Modul kann ich als Model lediglich den 4er auswählen.
Wie sind denn die Chancen, das ich den 2er oder 3er trotzdem eingebunden bekomme?
Bestenfalls direkt, nicht per MQTT.
Danke,
vb
Hallo,
kann es sein das ASC Befehle ignoriert werden wenn Rollos manuell auf eine Position gefahren werden?
Gestern am Abend ist mir aufgefallen dass einige Rollos nicht in die "Privacy" bzw. danach in die "Nacht Position" gefahren sind. Alle Rollos habe ich im laufe des Tages einmal manuell betätigt.
Hallo VB90,
Zitat von: VB90 am 12 August 2023, 15:14:12Der Pro2 oder Pro3 könnten mir gut ins Konzept passen.
damit Shellies der Plus- und Pro-Serie eingebunden werden können, musst du die in diesem Thread diskutierte Testversion des Shelly-Moduls installieren.
Der Wiki-Artikel zu den Shellies ist noch Stand des regulär verteilten Moduls. Und der dort genannte Shelly4Pro ist ein Gerät der 1. Generation, nicht zu verwechseln mit ShellyPro4.
Hallo bene80,
Zitat von: bene80 am 12 August 2023, 15:46:43kann es sein das ASC Befehle ignoriert werden wenn Rollos manuell auf eine Position gefahren werden?
wenn dein Rollo an einem Shelly angeschlossen ist, und du einen Befehl über das Shelly-Modul absetzt, dann hat das nichts mit ASC zu tun.
@Starkstrombastler
Ok. Danke, das schaue ich mir mal an.
vb
Hallo,
Zitatwenn dein Rollo an einem Shelly angeschlossen ist, und du einen Befehl über das Shelly-Modul absetzt, dann hat das nichts mit ASC zu tun.
das ist mir klar. Vor meinem Update war es aber so, dass nach einer manuellen Fahrt, nach einer gewissen Zeit wieder automatisch in die Beschattungsposition gefahren wurde. Jetzt passiert da nichts mehr. Das hat aber vermutlich nichts mit deinem Modul zu tun, ich habe ja beide Module gleichzeitig upgedatet und war jetzt fälischlicherweise der Meinung es liegt am shelly modul.
Muss mir meine ASC Konfiguration anschauen, dann wird das hoffentlich wieder so funktionieren wie bisher.
Zitat von: Starkstrombastler am 10 August 2023, 13:46:55Hallo Elgardo,
probier mal folgendes:
- lösche die Attribute model und mode
- betätige die DEF Taste in der Webansicht, oder als Kommando defmod name ip-des-Shelly
Der Shelly wird dadurch neu definiert und die Auto-Erkennung erkennt, dass es sich um ein Gen2-Modell handelt.
Voraussetzung ist, dass der Shelly bereits fertig eingerichtet ist und sich über die App oder Web bedienen lässt.
Und natürlich die aktuelle (Test-) Version des Moduls (https://forum.fhem.de/index.php?action=dlattach;attach=172485).
Hallo Starkstrombastler,
herzlichen Dank für die rasche Antwort, das war die Lösung. Die Fehlermeldung ist endlich weg.
Sorry für meine späte Antwort.
Hallo Shelly-Fan-Gemeinde,
die Weiterentwicklung des Shelly-Moduls befindet sich auf der Zielgeraden, heute kommt nochmal eine Testversion, aber als nächstes steht die Übernahme in das SVN an.
Die von bene80 beschriebenen Fehler sollten nich mehr auftreten:
Zitat von: bene80 am 06 August 2023, 21:09:11Hat der Name im Shelly ein Leerzeichen wird alles nach dem Leerzeichen abgeschnitten.
Zitat von: bene80 am 06 August 2023, 21:09:11Ich muss dann den slider kurz bewegen damit der neue Wert übernommen wird.
Außerdem wird die mit Firmware 1.0.0 verfügbare Frequenz bei Plus/Pro-Devices mit Leistungsmessung im Modul angezeigt. Die Daten werden dabei 1:1 vom Shelly übernommen, leider nur mit einer Kommastelle. Von einer Messung so wie hier (https://www.netzfrequenz.info/) sind wir da leider weit enfernt.
Freue mich wie immer über Rückmeldungen.
VG
Starkstrombastler
Ich habe die neueste Version installiert - hat alles super funktioniert.
Die bereits definierten Devices wurden problemlos übernommen, ein neuer Shelly Plus 2PM erkannt und die xtrachannels eingerichtet.
Zitat von: JWRu am 18 August 2023, 22:45:59Ich habe die neueste Version installiert - hat alles super funktioniert.
Die bereits definierten Devices wurden problemlos übernommen, ein neuer Shelly Plus 2PM erkannt und die xtrachannels eingerichtet.
Update
Mein Shelly Plus 1PM, der lokal mit einem Taster bedient wird, liefert im Takt von "interval" (stand auf 10) im Log:
2023.08.22 00:00:15 3: [Shelly_proc2G:status] Shellyplus1PM01 has input 0 with state unknown
2023.08.22 00:00:15 3: [Shelly_proc2G:config] Shellyplus1PM01 has input 0: button straight momentary
2023.08.22 00:00:25 3: [Shelly_proc2G:config] Shellyplus1PM01 has input 0: button straight momentary
2023.08.22 00:00:25 3: [Shelly_proc2G:status] Shellyplus1PM01 has input 0 with state unknown
2023.08.22 00:00:35 3: [Shelly_proc2G:status] Shellyplus1PM01 has input 0 with state unknown
2023.08.22 00:00:35 3: [Shelly_proc2G:config] Shellyplus1PM01 has input 0: button straight momentary
2023.08.22 00:00:45 3: [Shelly_proc2G:status] Shellyplus1PM01 has input 0 with state unknown
2023.08.22 00:00:45 3: [Shelly_proc2G:config] Shellyplus1PM01 has input 0: button straight momentary
2023.08.22 00:00:55 3: [Shelly_proc2G:status] Shellyplus1PM01 has input 0 with state unknown
2023.08.22 00:00:55 3: [Shelly_proc2G:config] Shellyplus1PM01 has input 0: button straight momentary
2023.08.22 00:01:05 3: [Shelly_proc2G:status] Shellyplus1PM01 has input 0 with state unknown
2023.08.22 00:01:05 3: [Shelly_proc2G:config] Shellyplus1PM01 has input 0: button straight momentary
Hallo JWRu,
vermutlich ist in diesem Device der verbose level auf 3 gestellt. Bei einem kleineren Wert tauchen diese Meldungen nicht auf.
Zitat von: JWRu am 22 August 2023, 06:37:552023.08.22 00:00:15 3: [Shelly_proc2G:status] Shellyplus1PM01 has input 0 with state unknown
2023.08.22 00:00:15 3: [Shelly_proc2G:config] Shellyplus1PM01 has input 0: button straight momentary
Ansonsten spiegeln die Logeinträge das normale Verhalten mit einem momentary-Input wieder. Dieser ist bei Betätigung für eine kurze Zeit auf ON und geht danach in einen undefinierten Zustand.
Wenn du eine Zustandsänderung auf Grund des Inputs "schnell" in Fhem sehen willst, ist es effizienter entsprechende Actions auf dem Shelly zu hinterlegen.
Dies kannst du mit dem Attribut 'webhook' automatisiert durchführen.
Zitat von: Starkstrombastler am 22 August 2023, 11:52:49Dies kannst du mit dem Attribut 'webhook' automatisiert durchführen.
Frage am Rande da ich im letzten Monat wenig am Shelly aktiv war.
Hattest du zum Thema CSRF-Token und Webhook eventuell noch Ergänzungen für 1st Gen eingebaut?
Ich hatte mir im Juli etwas mit DOIF im Perlmodus und {$FW_CSRF} gestrickt um den Input vom 1PM per Webhook zeitnah zu erhalten.
Zitat von: Starkstrombastler am 16 Juli 2023, 11:48:19...
Punkt für Punkt abarbeiten. Ich selbst habe auch ein unerwünschtes Verhalten ("kaputt schreiben") im Zusammenhang mit dem Löschen von Devices entdeckt.
--> Fehler beheben --> neues Update
Das ist (im Kontext Webhook) vermutlich korrigiert. Bin bisher nicht dazu gekommen es am PlusPLug zu testen
Zitat von: RalfRog am 22 August 2023, 15:25:01Hattest du zum Thema CSRF-Token und Webhook eventuell noch Ergänzungen für 1st Gen eingebaut?
Der Bug "kaputt schreiben" im Webhook-Automatismus wurde behoben. Das automatisierte Erstellen von Webhooks ist derzeit nur für Gen2-Devices implementiert. Was aber bei allen vom Modul abgedeckten Gen1-Geräten funktionieren sollte, sind die Set-Endpoints, um Befehle wie set <name> out_on, set <name> button_on, set <name> short_push, etc. zu verarbeiten.
Zitatvermutlich ist in diesem Device der verbose level auf 3 gestellt. Bei einem kleineren Wert tauchen diese Meldungen nicht auf
Der verbose level ist bei mir schon immer in "global" auf 3 gestellt - bei den Shellies habe ich auf Device-Ebene nichts eingestellt.
Das "alte" Shelly-Modul hat ja den Plus 1PM schon unterstützt und mit verbose 3 keine solchen Meldungen produziert.
Es ist klar, dass der Eingang mit einem Taster meistens undefiniert ist. Somit ist das kein Fehler, den man mit verbose 3 protokollieren müsste.
ZitatWenn du eine Zustandsänderung auf Grund des Inputs "schnell" in Fhem sehen willst, ist es effizienter entsprechende Actions auf dem Shelly zu hinterlegen.
Dies kannst du mit dem Attribut 'webhook' automatisiert durchführen.
Welche Wirkung hat dann das attribut "interval"?
Hallo Starkstrombastler,
vielen Dank für deine Arbeit, jetzt funktioniert alles.
Mir ist gerade noch etwas beim shellyrgbw aufgefallen. Die Helligkeit für den Weißkanal wird auch direkt im Shelly Webinterface übernommen. Die Helligkeit der Farbkanäle ändert sich aber nicht. Das heißt auch, man muss die Helligkeit der Farbkanäle im Webinterface auf 100% stellen, sonst kann man aus FHEM heraus nicht mehr korrekt ansteuern, bzw gar nicht mehr die Frabkanäle einschalten wenn sie auf 0% gestellt ist. Nachdem ich den shellyrgbw nur aus FHEM steuere ist das für mich aber kein Problem.
Eine Frage hätte ich noch: Weiß vielleicht jemand wie man den shellyrgbw über einen längeren Zeitraum (ca 30-60 Minuten) hoch und runter dimmen kann? Es gäbe ja die Transition time, die kann man aber mit dem shelly modul nicht ansprechen und sie geht leider auch nur bis 5s.
SG Bernhard
Zitat von: JWRu am 22 August 2023, 19:44:48Das "alte" Shelly-Modul hat ja den Plus 1PM schon unterstützt und mit verbose 3 keine solchen Meldungen produziert.
Schön zu hören, dass das Modul funktioniert. Damit kann ich viele Meldungen hochsetzen oder ganz entfernen.
Zitat von: JWRu am 22 August 2023, 19:44:48Welche Wirkung hat dann das attribut "interval"?
Mit
interval wird die Zeitspanne festgelegt, nach der das Modul
spätestens Daten vom Shelly abruft. Wenn sich der Shelly via Actions/Webhook in Fhem meldet, wird das zugehörige Reading aktualisiert und das Modul ruft sofort danach die Daten vom Shelly ab. Das Intervall wird zurückgesetzt.
Man kann also lange Intervalle festlegen und hat trotzdem Veränderungen am Shelly nahezu verzögerungsfrei in Fhem.
ZitatMit interval wird die Zeitspanne festgelegt, nach der das Modul spätestens Daten vom Shelly abruft. Wenn sich der Shelly via Actions/Webhook in Fhem meldet, wird das zugehörige Reading aktualisiert und das Modul ruft sofort danach die Daten vom Shelly ab. Das Intervall wird zurückgesetzt.
Man kann also lange Intervalle festlegen und hat trotzdem Veränderungen am Shelly nahezu verzögerungsfrei in Fhem.
Super - danke für die Antwort!
ZitatWenn du eine Zustandsänderung auf Grund des Inputs "schnell" in Fhem sehen willst, ist es effizienter entsprechende Actions auf dem Shelly zu hinterlegen.
Dies kannst du mit dem Attribut 'webhook' automatisiert durchführen.
Das habe ich jetzt mal ausprobiert. Das Attribut 'webhook' habe ich auf meine aktuelle FHEMWEB-Instanz gesetzt.
Im Shelly passiert aber nichts. Die 'Actions' bleiben leer.
Zitat von: JWRu am 23 August 2023, 16:07:09Das habe ich jetzt mal ausprobiert. Das Attribut 'webhook' habe ich auf meine aktuelle FHEMWEB-Instanz gesetzt.
Im Shelly passiert aber nichts. Die 'Actions' bleiben leer.
Habe gerade die Terstinstallation nicht aktiv.
Ich glaube mich zu erinnern, dass du zunächst auch eine Action im Shelly definieren musst. Sie müssen glaube ich mit "_" beginnen.
Das Modul liest das aus und ergänzt den CSRF-Token.
ZitatIch glaube mich zu erinnern, dass du zunächst auch eine Action im Shelly definieren musst. Sie müssen glaube ich mit "_" beginnen.
Das Modul liest das aus und ergänzt den CSRF-Token
Das probiere ich später mal aus - vielen Dank!
Update: Hat nicht geklappt - um eine Action zu erstellen muss ich anscheined zwingend eine URL angeben.
Beim Shelly Plus 2PM hat übrigens das automatische Erstellen der Actions mit dem Attribut 'webhooks' problemlos geklappt.
Zitat von: JWRu am 23 August 2023, 16:35:01Ich glaube mich zu erinnern, dass du zunächst auch eine Action im Shelly definieren musst. Sie müssen glaube ich mit "_" beginnen.
Das Modul liest das aus und ergänzt den CSRF-Token
Nein, das ist so nicht erforderlich. Mit dem Setzen des Attributes 'webhook' auf eine FHEMWEB-Instanz sollte alles vollautomatisch ablaufen. Auf dem ShellyPlus1 sollten sich dann 4 bzw. 6 Actions befinden, je nachdem wie der Eingang des Shelly konfiguriert ist. Die Namen der automatisch angelegten Actions beginnen mit '_'.
Sollte das Problem weiterhin bestehen, müssen wir uns ein List des Devices und die Log-Daten für verbose=4 (oder 5) anschauen.
Die Actions können natürlich auch manuell angelegt werden. Beispielsweise sollte die URL für das Shelly-Event 'Switch toggled on' in etwa so aussehen:
http://192.168.178.100:8084/fhem?XHR=1&fwcsrf=csrf_368000985512399&cmd=set%20meinShelly%20out_on%200
ZitatSollte das Problem weiterhin bestehen, müssen wir uns ein List des Devices und die Log-Daten für verbose=4 (oder 5) anschauen.
Ich habe jetzt folgendes gemacht: 'webhook' auf 'none' gesetzt, 'verbose' auf 5 gesetzt, dann 'webhook' auf 'WEB' gesetzt.
Ausschnitt aus dem Log zum Zeitpunkt der letzten Aktion:
2023.08.24 07:10:00 5: [Shelly_Attr] Shellyplus1PM01: called with command set for attribute webhook and value WEB
2023.08.24 07:10:00 3: [Shelly_Attr:webhook] Shellyplus1PM01 command is set, attribute webhook old: none new: WEB
2023.08.24 07:10:00 3: [Shelly_Attr:webhook] the webhook attribute is now WEB, create webhooks
2023.08.24 07:10:00 3: [Shelly_Attr:webhook] we will call Shelly_webhook for device Shellyplus1PM01, command is Create
2023.08.24 07:10:00 5: [Shelly_Set] calling for device Shellyplus1PM01 with command ?, without value
2023.08.24 07:10:00 5: [Shelly_Set] calling for device Shellyplus1PM01 with command ?, without value
2023.08.24 07:10:00 5: [Shelly_Set] calling for device Shellyplus1PM01 with command ?, without value
2023.08.24 07:10:00 5: [Shelly_Set] calling for device Shellyplus1PM01 with command ?, without value
2023.08.24 07:10:00 4: [Shelly_Get] receiving command get Shellyplus1PM01 ?
2023.08.24 07:10:00 5: [Shelly_Get] Shellyplus1PM01: unknown argument ?, choose one of config model:noArg predefAttr:noArg registers:noArg shelly_status:noArg status:noArg version:noArg
2023.08.24 07:10:03 4: [Shelly_webhook] proceeding with command 'Create' for device Shellyplus1PM01
2023.08.24 07:10:03 4: [Shelly_webhook] device Shellyplus1PM01 was called with command=Create
2023.08.24 07:10:03 4: [Shelly_webhook] device Shellyplus1PM01 will be called by Webhook.
2023.08.24 07:10:03 4: [Shelly_webhook] Shellyplus1PM01: check number of components for component=
2023.08.24 07:10:03 4: [Shelly_webhook] Shellyplus1PM01: the number of '' is compCount=0
2023.08.24 07:10:03 4: [Shelly_webhook] Shellyplus1PM01: check number of components for component=input
2023.08.24 07:10:03 4: [Shelly_webhook] Shellyplus1PM01: the number of 'input' is compCount=1
2023.08.24 07:10:03 5: [Shelly_webhook] Shellyplus1PM01: evtsCnt=-1 <4>
2023.08.24 07:10:03 4: [Shelly_webhook] Shellyplus1PM01: check number of components for component=emeter
2023.08.24 07:10:03 4: [Shelly_webhook] Shellyplus1PM01: the number of 'emeter' is compCount=0Hier ist ein List (etwas anonymisiert):
Internals:
CMD Create
DEF AAA.BBB.CCC.DDD
FUUID 637f3434-f33f-c1fa-ac2b-9f48ad54be5a539b
INTERVAL 600
NAME Shellyplus1PM01
NR 448
SHELLY SNSW-001P16EU
SHELLYID shellyplus1pm-0cdc7ef76230
STATE off
TCPIP AAA.BBB.CCC.DDD
TYPE Shelly
eventCount 75280
units 0
Helper:
DBLOG:
cloud:
myDbLog:
TIME 1692277004.3344
VALUE disabled
config:
myDbLog:
TIME 1692797505.65621
VALUE register 'stage' not found or empty [channel e]
current:
myDbLog:
TIME 1692836157.04214
VALUE 0
energy:
myDbLog:
TIME 1692844059.03877
VALUE 79905.2
energy_lastMinute:
myDbLog:
TIME 1692844059.03877
VALUE 0.0
firmware:
myDbLog:
TIME 1692284173.39467
VALUE v1.0.0
input:
myDbLog:
TIME 1692839282.10977
VALUE unknown
input_mode:
myDbLog:
TIME 1692839282.16926
VALUE button straight momentary
inttemp:
myDbLog:
TIME 1692853690.0805
VALUE 50.1
network:
myDbLog:
TIME 1692839778.12175
VALUE <html>connected to <a href="http://AAA.BBB.CCC.DDD">AAA.BBB.CCC.DDD</a> (Wifi)</html>
network_disconnects:
myDbLog:
TIME 1692839777.16035
VALUE 8
network_rssi:
myDbLog:
TIME 1692853739.11128
VALUE -66
network_ssid:
myDbLog:
TIME 1692277004.44027
VALUE XXXXXXXXXXXXXXX
power:
myDbLog:
TIME 1692844059.03877
VALUE 0
powerDamped:
myDbLog:
TIME 1692844059.03877
VALUE 0
protection:
myDbLog:
TIME 1692839240.04192
VALUE none
reason:
myDbLog:
TIME 1692845242.04085
VALUE button
relay:
myDbLog:
TIME 1692836162.03787
VALUE off
state:
myDbLog:
TIME 1692839782.27964
VALUE off
voltage:
myDbLog:
TIME 1692853736.04034
VALUE 229.6
webhook_cnt:
myDbLog:
TIME 1692839282.19987
VALUE 0
webhook_ver:
myDbLog:
TIME 1692839282.19987
VALUE 0
OLDREADINGS:
READINGS:
2023-08-17 14:56:44 cloud disabled
2023-08-23 15:31:45 config register 'stage' not found or empty [channel e]
2023-08-24 02:15:57 current 0
2023-08-24 04:27:39 energy 79905.2
2023-08-24 04:27:39 energy_lastMinute 0.0
2023-08-17 16:56:13 firmware v1.0.0
2023-08-24 03:08:02 input unknown
2023-08-24 03:08:02 input_mode button straight momentary
2023-08-24 07:08:10 inttemp 50.1
2023-08-24 03:16:18 network <html>connected to <a href="http://AAA.BBB.CCC.DDD">AAA.BBB.CCC.DDD</a> (Wifi)</html>
2023-08-24 03:16:17 network_disconnects 8
2023-08-24 07:08:59 network_rssi -66
2023-08-17 14:56:44 network_ssid XXXXXXXXXXXXXXX
2023-08-24 04:27:39 power 0
2023-08-24 04:27:39 powerDamped 0
2023-08-24 03:07:20 protection none
2023-08-24 04:47:22 reason button
2023-08-24 02:16:02 relay off
2023-08-24 03:16:22 state off
2023-08-24 07:08:56 voltage 229.6
2023-08-24 03:08:02 webhook_cnt 0
2023-08-24 03:08:02 webhook_ver 0
helper:
a_Active_Power 0
b_Active_Power 0
c_Active_Power 0
power 0
powerCnt 1
Attributes:
ShellyName Shellyplus1PM01
alexaName Kaffeemaschine
alias Kaffeemaschine
cmdIcon on:general_an@green off:general_aus@red
devStateIcon on.*:general_an@green off.*:general_aus@red
genericDeviceType switch
icon sonos_play1
interval 600
model shellyplus1pm
room Küche,System->Alexa,System->Protokolle->Shelly
stateFormat relay
userReadings powerDamped:power.* { if ( ReadingsVal($name,"relay","off") eq "off" ) { return 0 }
else { sprintf( "%.0f", movingAverage("$name","power",600)) } }
verbose 5
webCmd on:off
webhook WEB
Die zuletzt berichteten Probleme werden mit diesem neuen Update behoben:
Zitat von: bene80 am 22 August 2023, 22:33:38Die Helligkeit für den Weißkanal wird auch direkt im Shelly Webinterface übernommen. Die Helligkeit der Farbkanäle ändert sich aber nicht. Das heißt auch, man muss die Helligkeit der Farbkanäle im Webinterface auf 100% stellen, sonst kann man aus FHEM heraus nicht mehr korrekt ansteuern, bzw gar nicht mehr die Frabkanäle einschalten wenn sie auf 0% gestellt ist.
Beim Setzten der Farbkanäle mit
set name rgb .... bzw.
set name rgbw .... wird die Verstärkung jetzt immer auf 100% gesetzt.
Außerdem wurde ein set-Befehl für die Verstärkung der Farbkanäle eingebaut:
set name gain <0...100>. Damit sollte es auch möglich sein, durch zyklisches Setzen des Gain-Wertes eine einfache Dimmfunktion zu realisieren.
Zitat von: bene80 am 22 August 2023, 22:33:38Es gäbe ja die Transition time, die kann man aber mit dem shelly modul nicht ansprechen und sie geht leider auch nur bis 5s.
Das stimmt so nicht ganz. Mit
set name config ... lassen sich im Prinzip alle Werte bei den Gen1-Geräten einstellen, z.B. so:
set name config transition 1500.
Die zur Verfügung stehenden Register erhält man mit:
get name register.
Einen bestimmten Wert erhält man mit:
get name config <register>. Das Ergebnis steht dann im Reading 'config'.
Auch die Webhooks für die ShellyPlus/Pro1-Geräte sollten jetzt funktionieren:
Zitat von: JWRu am 24 August 2023, 07:25:19ZitatSollte das Problem weiterhin bestehen, müssen wir uns ein List des Devices und die Log-Daten für verbose=4 (oder 5) anschauen.
Viel Erfolg beim Testen!
Das ging aber fix - vielen Dank!
Ich werde es später mal testen.
Update:
ZitatAuch die Webhooks für die ShellyPlus/Pro1-Geräte sollten jetzt funktionieren:
Funktioniert!
Jetzt habe ich noch eine Frage:
Ich betreibe meine FHEMWEB-Instanz mit HTTPS - csrfToken ist nicht gesetzt.
Der Automatismus des Shelly-Moduls legt als URL der Action eine http-Adresse mit csrf-Token an.
Das führt in FHEM zu einer Fehlermeldung:
FHEMWEB SSL/HTTPS error: SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http requestSelbst wenn ich "http" in der Action-URL durch "https" ersetze, bleibt der Fehler bestehen.
Ist es sinnvoll, für die Shelly-Webhooks eine eigene FHEMWEB-Instanz mit HTTP und csrfToken anzulegen?
Zitat von: JWRu am 24 August 2023, 16:01:19Ich betreibe meine FHEMWEB-Instanz mit HTTPS - csrfToken ist nicht gesetzt.
Warum OHNE csrfToken!!?
Zitat von: JWRu am 24 August 2023, 16:01:19Ist es sinnvoll, für die Shelly-Webhooks eine eigene FHEMWEB-Instanz mit HTTP und csrfToken anzulegen?
Es ist NICHT sinvoll (und total unnötig) eine FhemWeb-Instanz OHNE csrfToken anzulegen!
Minimum sollte ein fixer Token sein.
Gruß, Joachim
Zitat von: MadMax-FHEM am 24 August 2023, 16:19:16Zitat von: JWRu am 24 August 2023, 16:01:19Ich betreibe meine FHEMWEB-Instanz mit HTTPS - csrfToken ist nicht gesetzt.
Warum OHNE csrfToken!!?
Zitat von: JWRu am 24 August 2023, 16:01:19Ist es sinnvoll, für die Shelly-Webhooks eine eigene FHEMWEB-Instanz mit HTTP und csrfToken anzulegen?
Es ist NICHT sinvoll (und total unnötig) eine FhemWeb-Instanz OHNE csrfToken anzulegen!
Minimum sollte ein fixer Token sein.
Gruß, Joachim
Das ist ja nett, dass ich allgemeine Ratschläge zur Sicherheit von FHEM bekomme.
Leider ist es kein Beitrag zur Lösung meines Problems. Ich habe jetzt 'csrfToken' auf 'random' gesetzt und erhalte mit http und https haargenau die gleichen Fehlermeldung. (Die URLs habe ich natürlich neu anlegen lassen).
Und wenn man meinen Post genau liest, kann man verstehen, dass ich eine eigene FHEMWEB-Instanz mit http UND csrfToken vorgeschlagen habe.
Tipptopp, das ging ja schnell, jetzt funktioniert alles. Jetzt muss ich nur mehr raus finden wie ich den Dimmer umsetze :-). Wäre schon gut wenn man sich ein bisschen besser auskennen würde.
ZitatDas stimmt so nicht ganz. Mit set name config ... lassen sich im Prinzip alle Werte bei den Gen1-Geräten einstellen, z.B. so: set name config transition 1500.
Super, das wusste ich nicht, dachte mir transition wurde mit get nicht angezeigt als ich da das letzte Mal danach gesucht habe. Das war aber noch mit der offiziellen Version
Zitat von: JWRu am 24 August 2023, 16:01:19Jetzt habe ich noch eine Frage:
Ich betreibe meine FHEMWEB-Instanz mit HTTPS - csrfToken ist nicht gesetzt.
Der Automatismus des Shelly-Moduls legt als URL der Action eine http-Adresse mit csrf-Token an.
Das führt in FHEM zu einer Fehlermeldung:
FHEMWEB SSL/HTTPS error: SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http requestSelbst wenn ich "http" in der Action-URL durch "https" ersetze, bleibt der Fehler bestehen.
Ist es sinnvoll, für die Shelly-Webhooks eine eigene FHEMWEB-Instanz mit HTTP und csrfToken anzulegen?
So, ich habe es jetzt hingekriegt, allerdings nur mit http - https hat nicht funktioniert.
Ich hatte sowieso eine FHEMWEB api Instanz mit http und einer anderen Portnummer - darüber funktioniert es.
Habe mich auch nochmal zum Thema csrfToken schlau gemacht: Ich hatte das Attribut in FHEMWEB nicht explizit gesetzt - das bedeutet aber laut Commandref, dass es auf 'random'steht.
ZitatDefault ist random für featurelevel 5.8 und größer..
Ich habe die mit dem Attribut 'webhook' automatisiert erstellte Action auch verändert. Habe nicht verstanden, was z.B. 'set ... out_on 0' machen soll.
Ich stelle 'interval' runter, sobald der Shelly eingeschaltet wird (_SWITCH.ON_), um in kurzen Zeitabständen 'power'-Readings zu erhalten.
http://<FHEM-IP>:<PORT>/fhem?XHR=1&fwcsrf=<csrf-Token>cmd=attr%20-silent%20<Devicename>%20interval%2010Beim Ausschalten (_SWITCH.OFF_) stelle ich 'interval' wieder hoch.
Jetzt bin ich mal gespannt, ob das Shelly-Modul beim Neustart von FHEM in den veränderten Actions gezielt nur das csrf-Token austauscht.
Hallo JWRu,
das ist aber eine schöne Anwendung der Shelly-Actions.
Mit dem nächsten Modul-Update wird es einen Set-Befehl zum Ändern des Intervalls geben, so dass das Intervall-Attribut bei einer derartigen Anwendung unverändert bleiben kann.
Zitat von: JWRu am 25 August 2023, 19:43:02Habe nicht verstanden, was z.B. 'set ... out_on 0' machen soll.
Mit diesem Befehl wird dem Modul mitgeteilt, dass der erste Ausgang (channel=0) des Shelly eingeschaltet wurde, z.B. durch einen angeschlossenen Schalter oder durch einen Shelly-internen Timer. Das Modul setzt die Readings und löst Events aus, ohne dass abgewartet werden muss, bis die nächste zyklische Abfrage gem. Intervall durchgeführt wird. Mit einem Notify kann man dann darauf reagieren.
Vielleicht kann einer der Mitleser hier etwas zur HTTPS-Thematik beitragen, das würde ich dann noch im Modul berücksichtigen.
Hallo, kennt das Modul einen shelly motion2 bzw. kann dessen Werte auslesen?
Hallo zusammen,
ich habe seit heute einen Shelly Pro1 im Einsatz.
Dieser hat 2 SW Eingänge.
Ich habe dazu folgenden Änderungsvorschlag:
Alt:
"shellypro1" => [1,0,0, 0,1,1],
Neu
"shellypro1" => [1,0,0, 0,1,2],
funktioniert soweit
Schöne Grüße
Zitat von: alf.ele am 31 August 2023, 17:11:32ich habe seit heute einen Shelly Pro1 im Einsatz.
Dieser hat 2 SW Eingänge.
Danke für den Hinweis - und das Testen vorab.
Änderung ist im nächsten Update mit drin.
Zitat von: bene80 am 31 August 2023, 16:08:26Hallo, kennt das Modul einen shelly motion2 bzw. kann dessen Werte auslesen?
Batteriebetriebene Shellies werden vom Modul zwar erkannt, aber mit model
generic angelegt. Es werden keine spezifischen Readings angelegt.
Diese Shellies können jedoch via Colo-T-Protokoll mit dem Modul
ShellyMonitor ausgelesen werden (nur Gen1).
Zitat von: Starkstrombastler am 31 August 2023, 21:12:40via Colo-T-Protokoll mit dem Modul ShellyMonitor ausgelesen werden (nur Gen1).
Hatte ich das schon mal gefragt.... weiss nicht mehr.
Inwieweit vertragen sich das aktuelle Modul und der Shelly Monitor (klar für Gen1) noch? Die Namen der Readings müssen ja passen und auch sonst muss ja einiges zusammen spielen. Aktiv läuft bei mir noch das alte Modul und Deines ist z.Zt. auf dem Testsystem.
Gruß Ralf
Zitat von: RalfRog am 31 August 2023, 21:35:12Inwieweit vertragen sich das aktuelle Modul und der Shelly Monitor (klar für Gen1) noch?
Das kann ich nicht so genau sagen. Kompatibilität mit dem ShellyMonitor habe ich nicht getestet, es könnte schon sein, dass sich irgendwo der Name eines Readings geändert hat.
Auch wenn das Attribut
model automatisch gesetz wird, bleibt immer noch die Möglichkeit das Attribut
model auf
generic zu ändern. Dann werden die Readings nur vom ShellyMonitor gesetzt.
Auf der anderen Seite können im ShellyMonitor Devices mit dem Attribut
ignoreDevices ausgeblendet werden. Dann schreibt nur das ShellyModul.
Seit der Weiterentwicklung des Moduls gab es hier in diesem Thread so gut wie keine Diskussion dazu. Hinweise und Anregungen sind aber wie immer gerne gesehen.
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
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.
Zitat von: bene80 am 01 September 2023, 10:28:40Diese 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
Zitat von: MadMax-FHEM am 01 September 2023, 12:04:12MQTT?
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.
Zitat von: RalfRog am 31 August 2023, 22:12:34Ich 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).
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.
Zitat von: gvzdus am 10 September 2023, 09:59:49Moin, 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
ZitatShelly 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.
Hallo!
Habe einen Shelly Pro1PM.
Mit Modulversion neuer als 4.04e kann ich das relay nicht mehr via FHEM schalten.
im Log steht:
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!
Zitat von: gamauf am 12 September 2023, 12:25:47Mit 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:
Zitat von: alf.ele am 31 August 2023, 17:11:32ich habe seit heute einen Shelly Pro1 im Einsatz.
Ansonsten benötige ich mehr Daten.
Ich glaub ich habe die Ursache gefunden:
Ich hatte
attr PV_WR defchannel KanalNamegesetzt, was die neue Modulversion veranlasst hat im URL statt
http://192.168.1.86/relay/0?turn=offdas zu senden:
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???
Zitat von: gamauf am 12 September 2023, 13:46:22attr 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.
Zitat von: gamauf am 12 September 2023, 13:46:22Altlast, 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.
Für's Finetuning des Moduls:
Ich erhalte ab und zu folgende Warnung
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_Shelly.pm line 1890.
Zitat von: gvzdus am 10 September 2023, 09:59:49Moin, 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.
Zitat von: gvzdus am 13 September 2023, 14:13:13ShellyMonitor habe ich angepasst
heißt das, dass im Shelly Modul die Readings für den Shelly3EM so bleiben können wie sie sind?
Zitat von: gvzdus am 13 September 2023, 14:13:13Jetzt 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.
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
Zitat von: Starkstrombastler am 13 September 2023, 14:27:47heißt das, dass im Shelly Modul die Readings für den Shelly3EM so bleiben können wie sie sind?
Ich würde schon vorschlagen, von "energy_returned" auf "energyReturned" zu gehen. Ich habe das so aus der Shelly-Doku von CoIoT übernommen.
Zitat von: gvzdus am 13 September 2023, 14:13:13Jetzt 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.
[/quote]
Eigentlich bin ich ganz happy nach den ersten Stunden: Auch, wenn gerade mehrere kW Ströme auf den Phasen fließen, regelt das selbst berechnete "power" aus dem Shelly 3EM den Speicher ganz gut an die Stromzählerwerte dran.
Saldierend kann ich keine Abweichung berechnen, da ja beim Shelly die Phasen einzeln saldiert werden, während "für uns Stromkunden" der Gesamtsaldo relevant ist. Das müsste jemand ohne PV beobachten.
Zitat von: Starkstrombastler am 13 September 2023, 14:27:47Zitat von: gvzdus am 13 September 2023, 14:13:13ShellyMonitor habe ich angepasst
heißt das, dass im Shelly Modul die Readings für den Shelly3EM so bleiben können wie sie sind?
Hmmm...
Würde bedeuten, dass man 2 Sätze Readings hat. Einmal von Monitor energyReturned (per Multicast gepushed) und aus dem Modul energy_returned (per Intervall gepolled).
Die Bezeichnung des Monitors ist die, die auch in CoIot definiert ist (siehe <IP>/cit/d).
Edit
Hab ne Screenshot der cit/d - Ausgabe angehängt
Zitat von: gvzdus am 13 September 2023, 15:01:40Ich würde schon vorschlagen, von "energy_returned" auf "energyReturned" zu gehen.
Danke für die Klärung, hab' nicht gecheckt, was im Monitor angepasst wurde. Mein Vorschlag: In der nächsten Testversion werden beide Readings parallel gesetzt, "energy_returned" wird dann in der übernächsten Version entfernt. User können somit ihre Settings anpassen.
In meiner eigenen Testumgebung habe ich für einen ShellyBulb im White-Modus einen Readings-Konflikt mit dem Monitor:
cloud disabled
config transition=5000 [channel 0]
ct 3000
energy 0.20
firmware v1.13.0
network connected to 192.168.10.222
network_disconnects 10
pct 7
power 0
relay_0 off
source timer
state off
timer 0Da der ShellyBulb/white kein Relais und auch nur einen Kanal hat, wird im Modul der "state" auf "on" und "off" gesetzt.
Das Reading "relay_0" kommt vom Monitor und wirkt hier eher verwirrend.
Zitat von: Starkstrombastler am 12 September 2023, 21:26:39...
Solange wird hier mit Testversionen arbeiten, kann es schon mal vorkommen, dass Attribute in nicht vorgesehener Weise setzbar sind.
...
Das war nicht als Kritik, sondern als Frage/Feedback gemeint.
Mir ist schon klar, dass wir hier "work in progress" sind und mit soetwas zu rechnen ist.
Danke für deine Antworten!
Zitat von: Starkstrombastler am 13 September 2023, 15:23:53In meiner eigenen Testumgebung habe ich für einen ShellyBulb im White-Modus einen Readings-Konflikt mit dem Monitor:
...
Da der ShellyBulb/white kein Relais und auch nur einen Kanal hat, wird im Modul der "state" auf "on" und "off" gesetzt.
Das Reading "relay_0" kommt vom Monitor und wirkt hier eher verwirrend.
Tja, was schlägst Du vor?
Den Plug_S z.B. schreibt ShellyMonitor als "relay", während Shelly auch "state" nimmt.
Jetzt überlege ich: Sollte ich, wenn ein Gerät nur einen "relay" hat, immer "state" als Ziel nehmen?
Dann gäbe es also für alles von Shelly 1 über 1pm u.s.w. nur noch "state", während es beim 2.5 dann "relay_0" und "relay_1" hieße.
Zitat von: gvzdus am 13 September 2023, 15:55:31Den Plug_S z.B. schreibt ShellyMonitor als "relay"
- Beim 3EM ist es auch relay (cit/d = relay_0) und im state steht im alten Modul aber ok (woraus auch immer das abgeleitet wird) => neues Modul on/off
- Wie du schreibst bei 1PM, Plug-S, PlugPlus-S relay und state on/off altes und neues Modul (auch hier cit/d = relay_0)
Das relay (oder relay_0) ist irgendwie einleuchtender. Inhaltlich ist es identisch zu state - bei anderen Switches ist mit state on/off meist auch der Schaltzustand abbildet. Zu bedenken gäbe es vielleicht noch den Umstand der SW-Eingänge (Wert 0/1) an die ja (default, veränderbar) das Relais gekoppelt ist.
Allerding klappt wahrscheinlich ein einfaches set <device> on/off nur wenn es an den state gekoppelt ist, oder?
Zur anstehenden Diskussion zum Zusammenwirken der Shellies der ersten Generation mit dem ShellyMonitor habe ich nachstehende Zusammenfassung aufgestellt.
Im Shelly Modul ist für die Gen1-Devices folgende Logik wirksam:
A): Bei Geräten mit einem Relais wird der Zustand des Kanals gleichlautend in die Readings "state" und "relay" geschrieben ("on","off").
B): Bei Geräten mit einem Dimmer wird der Zustand des Kanals in das Reading "state" geschrieben ("off" oder Prozentwert).
C): Bei Geräten mit mehreren Relais wird der Zustand der Kanäle in Readings "relay_0|1..." geschrieben, das Reading "state" erhält den Wert "OK".
D): Bei Geräten mit zwei Relais im Roller-Mode wird der Zustand des Rollos in das Reading "state" geschrieben.
E): Bei Geräten mit mehreren Dimmern wird der Zustand der Kanäle in Readings "state_0|1..." geschrieben, das Reading "state" erhält den Wert "OK".
Bei allen Geräten wird im Fehlerfall eine Fehlermeldung (z.B. "Error") in das Reading "state" geschrieben.
zu den Geräten A) gehören alle Shelly1, ShellyPlug, ShellyUni, aber auch ShellyEM und Shelly3EM.
zu den Geräten B) gehören ShellyDimmer und alle ShellyBulb sowie ShellyRGBW im Color Mode
zu den Geräten C) gehören alle Shelly2 (im Relay Mode), Shelly4Pro
zu den Geräten D) gehören alle Shelly2 (im Roller Mode)
zu den Geräten E) gehört nur der ShellyRGBW im White Mode
Wie sieht die Logik für den ShellyMonitor aus?
ShellyMonitor ist viel systematischer gefasst (hoffe, pah bleibt jetzt ruhig).
Du hast im Code die Tabelle, die 1:1 vom Shelly-Modul kopiert ist:
Zitat# Copied from 36_Shelly, keep up to date..:
my %shelly_models = (
#(relays,rollers,dimmers,meters,NG)
"generic" => [4,4,4,4,0],
"shellygeneric" => [4,4,4,4,0],
Im Monitor-Modul sind die Zeilen ab ca. 724 relevant: Im Prinzip wird alles in den nativen Reading-Namen geschrieben. Gibt es in der "shelly_models"-Tabelle nur eine 1, dann heißt der Wert "power" (und nicht "power_0"). Daher auch "relay_0": Der Bulb hat in der Definition keinen Relay, daher wird auch "relay_0" beschrieben (denn 0!=1).
"state" wird nur beim Roller-Mode beschrieben - ich fand' "state" immer einen unsystematischen Bastard.
Aber wir können das jetzt gerne mal sauber ziehen, sodass es wirklich keinen Unterschied macht, ob ShellyMonitor oder Shelly den Status schreibt.
Zitat von: gvzdus am 13 September 2023, 23:14:15ShellyMonitor ist viel systematischer gefasst (hoffe, pah bleibt jetzt ruhig).
Das kann schon sein, ShellyMonitor kam später und macht auch weniger. Das ist sicher von Vorteil, wenn Code neu aufgesetzt wird. Für mich ist das, was im Shelly Modul für die Gen1 codiert ist gewisssermaßen "Erbmasse", nicht zuletzt weil dies so bei hunderten Usern produktiv im Einsatz ist. Neben ein paar Bugs habe ich den Code hier und da etwas generischer gefasst, aber Readings sind vom Ansatz her unverändert geblieben.
Zitat von: gvzdus am 13 September 2023, 23:14:15Im Prinzip wird alles in den nativen Reading-Namen geschrieben.
Die Shellies haben vom Design her drei verschiedene Outputs, nämlich relay, roller und lights (dimmer). Außerdem gibt es noch meters und inputs.
Bei einkanaligen Shellies wird der Kanalstatus in
state geschrieben. Ausnahme: Relais-Typen, hier wird zusätzlich das Reading
relay beschrieben (*).
Bei mehrkanaligen Shellies wird der Kanalstatus in Readings entsprechend der Output-Typen geschrieben, nämlich:
relay_0|1...roller_0|1... (wird erst mit dem Gen2-Dual-Shutter relevant)
state_0|1... (müsste eigentlich dimmer_0|1... etc heißen oder light_0|1...) (**)
Das erscheint mir doch logischer als bei einem Shelly, welcher definitiv kein Relais besitzt, ein Reading
relay_0 zu beschreiben.
Zur Ausnahme (*) kann ich mir vorstellen, auf das Reading
relay zu verzichten, damit weiterhin Befehle
set device on|off|... ohne Zusatzaufwand funktionieren. Bei den mehrkanaligen Shellies wird dies durch das Attribut
defchannel bzw. durch das Generien von readingsProxy-Devices erreicht.
Zu Ausnahme (**) hat vielleicht jemand einen griffigen Namen für entsprechende Readings, um somit nicht in Konflikt mit
state zu stehen. dimmer oder light sind auch nicht optimal, wenn z.B. mit einem ShellyRGBW 24V-Heizkörperventile angetrieben werden.
Ich kann die Hässlichkeit schon nachvollziehen.
Ich habe erstmal geändert, dass bei allen Geräten, die laut Spec "0 Relais" haben (also Bulb, Dimmer, u.s.w.) nicht relay_0 geschrieben wird, sondern "state".
Die Version packe ich vorerst nicht ins SVN, sondern hänge sie an.
Nach dem Einspielen (+ "reload 36_ShellyMonitor") der Tipp:
Aufräumen (Löschen aller Bestandsreadings) mit "deletereading .* relay_0"
Nur zur Sicherheit:
Trotz Angabe "$Id: 36_ShellyMonitor.pm 26929 2022-12-29 19:28:42Z gvzdus $" im Anhang der #564
basiert die Version aber auf dem letzten
Update im SVN 27691 "$Id: 36_ShellyMonitor.pm 27961 2023-09-13 12:05:24Z gvzdus $"
Also quasi "alles drin".
Gruß
Ja! :D
Ich pfusche auf meinem Live-System rum, teste, und kopiere dann rüber auf den Laptop und checke ein.
Die Version war buggy.
Ich habe eine korrigierte Version jetzt mit diversen Geräten (Bulb, Plug-S, 2.5 Rollermode, 2.5 Relaismode) getestet und ins SVN eingespielt.
Ok
Oberflächlich scheint/schien 3EM,1PM Energy ok.
Schau ich mal genauer mit der SVN-Version und steck den Plug-S und Shelly1 dazu.
Falls Du heute Abend noch nichts vor hast :-)
Hier ist sie schon mal (bis auf die SVN-Versionsnummer) :-)
Danke, geholt hatte ich sie (27968) schon...
Bin aber unterwegs ;) - denke morgen vormittag oder Nachtschicht
Habe das Monitor-Modul am Livesystem aktualisiert in Zusammenarbeit mit dem alten Shelly Modul und per Reload neu gestartet.
Es gab (für mich) erstmal keine Auffälligkeiten bei Shelly1, Plug-S, 1PM & 3EM.
Nach dem löschen der Readings (Shelly1, Plug-S) wurden -interval = 0- am Shelly1 "relay" und am Plug-S "energy, power, relay" neu erzeugt.
Soweit so richtig denke ich -- da 1PM und 3EM aktiv laufen wollte ich meine Readings nicht löschen (mache ich auf dem Testsystem).
Da in den Internals sich die FVERSION nicht aktualisiert hatte, habe ich dann doch noch einen "shutdown restart" FHEM gemacht. Ergebnisse wie oben und im Log ein paar Warnings (Hinweis aktualisierter Monitor & altes ShellyModul:
2023.09.16 11:03:11.192 0: Server shutdown
2023.09.16 11:03:11.196 2: DbLog DBLogging - stopping SubProcess PID >15080< ...
2023.09.16 11:03:11.209 2: DbLog DBLogging - SubProcess PID >15080< stopped
...
2023.09.16 11:03:14.333 1: Including fhem.cfg
2023.09.16 11:03:22.149 2: DbLog DBLogging - Subprocess >1235< initialized ... ready for non-blocking operation
2023.09.16 11:03:22.275 3: telnetPort: port 7072 opened
2023.09.16 11:03:22.979 3: WEB: port 8083 opened
2023.09.16 11:03:22.993 3: WEBphone: port 8084 opened
2023.09.16 11:03:23.001 3: WEBtablet: port 8085 opened
2023.09.16 11:03:23.926 2: eventTypes: loaded 6400 lines from ./log/eventTypes.txt
...
2023.09.16 11:03:39.028 2: Shelly-Module loaded supports models: shellypro2pm,shelly3em,shellyuni,shelly1pm,shellypro1pm,shellyplus1,shellypro4,shellyem,shelly4,generic,shelly2.5,shellypro4pm,shellyplug,shellybulb,shellyrgbw,shellyplus2pm,shellydimmer,shellyplus1pm,shellypro2,shelly1,shelly2,shellypro1
2023.09.16 11:03:45.623 1: Including ./log/fhem.save
2023.09.16 11:03:46.712 1: Messages collected while initializing FHEM
...
2023.09.16 11:05:01.597 0: Featurelevel: 6.2
2023.09.16 11:05:01.599 0: Server started with 247 defined entities (fhem.pl:27498/2023-04-30 perl:5.032001 os:linux user:fhem pid:1225)
2023.09.16 11:05:04.271 2: Defined real device shelly_1_987654321f for 198.2.3.9 as model generic
2023.09.16 11:05:04.275 1: Assigning device shelly_1_987654321f SHELLYID 987654321F
2023.09.16 11:05:04.277 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_ShellyMonitor.pm line 686.
2023.09.16 11:05:04.280 1: PERL WARNING: Use of uninitialized value $model in hash element at ./FHEM/36_ShellyMonitor.pm line 733.
2023.09.16 11:05:04.281 1: PERL WARNING: Use of uninitialized value $no_relais in numeric eq (==) at ./FHEM/36_ShellyMonitor.pm line 734.
2023.09.16 11:05:06.748 2: Defined real device shelly_plug_s_df9876 for 198.2.3.8 as model shelly1pm
2023.09.16 11:05:06.751 1: Assigning device shelly_plug_s_df9876 SHELLYID E653E598656
2023.09.16 11:05:06.820 2: Defined real device shelly_3em_haus for 198.2.3.7 as model shelly3em
2023.09.16 11:05:06.822 1: Assigning device shelly_3em_haus SHELLYID 356DEF63EC5A
2023.09.16 11:05:06.969 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 5018.
...
2023.09.16 11:06:56.291 2: Defined real device shelly_plug_s for 198.2.3.6 as model shellyplug
2023.09.16 11:08:22.078 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/36_ShellyMonitor.pm line 872.
2023.09.16 11:08:22.079 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/36_ShellyMonitor.pm line 873.
2023.09.16 11:08:22.080 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/36_ShellyMonitor.pm line 873.
2023.09.16 11:08:22.081 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/36_ShellyMonitor.pm line 879.
...
2023.09.16 11:10:26.842 1: PERL WARNING: Use of uninitialized value $net in pattern match (m//) at ./FHEM/36_Shelly.pm line 1654.
Ich probiere es auf dem Testsystem noch mit dem aktuellen Test ShellyModul
Hallo Starkstrombastler
Bevor ich die falsche Version verwende. Die letzte Version die ich "finde" ist: my $version = "4.09a 24.08.2023", korrekt?
Gruß Ralf
Prüfe bitte, ob bei allen Shelly's model gesetzt ist!
Die Fehler hatte ich mit Geräten, bei denen das nicht der Fall war
Beim Plug-S ist das Model gesetzt gewesen, beim Shelly1 (habe ich über den Monitor definiert, Model fehlte zunächst) bin ich mir nicht mehr sicher ob ich das Model nach dem Reload Monitor (und vor Restart) oder erst nach dem Restart gesetzt habe.
Ich checke es beim Testsystem dann gezielt, warte nur noch auf die Versionsangabe von Starkstrombastler.
Zitat von: RalfRog am 16 September 2023, 11:51:00Die letzte Version die ich "finde" ist: my $version = "4.09a 24.08.2023", korrekt?
Ja
Habe gerade auf dem Testsystem beide Module aktualisiert/geprüft und vor dem FHEM "shutdown restart" gecheckt, dass alle Modelle und Attribut "Intervall = 0" gesetzt sind.
=> ok
- Nichts Ungewöhnlichews im Log :)
Nach dem Neustart sind natürlich durch das Modul alle Readings wieder da. Ich habe sie per deletereading gelöscht um zu sehen was der Monitor hochbringt:
ZitatShelly1
relay
Plug-S
energy
power
relay
Shelly 1PM
energy
power
relay
Shelly 3EM
power_0|1|2
energy_0|1|2
energyReturned_0|1|2
relay
Die Werte (s.o.) werden auf den ersten Blick korrekt aktualisiert (nicht gegen den Sniffer geprüft).
Die einzige Auffälligkeit ist, im Monitor stehen die Shellies auf n.s. (not supported)
IP Name Model
1.2.3.6 Plug shellyplug, n.s.
1.2.3.7 S1PM shelly1pm, n.s.
1.2.3.8 shelly_generic_shem_3_354acb34ec7b shelly3em, n.s.
1.2.3.9 shelly_1_47845371a86e shelly1, n.s. Edit
Hatte heute Nachmittag den Plug-S und den Shelly1 vom Stromnetz getrennt. Der Shelly1 wurde aus dem Monitor ausgetragen der Plg-S nicht - gibt es unterschiedliche Timeouts?
Log:
2023.09.17 15:30:00.764 1: Device shelly_1_47845371a86e has expired, no messages seen
2023.09.17 15:30:30.430 1: PERL WARNING: Use of uninitialized value $state in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3708.
2023.09.17 15:30:30.432 1: PERL WARNING: Use of uninitialized value $net in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3708.
2023.09.17 15:30:30.434 1: PERL WARNING: Use of uninitialized value $net in pattern match (m//) at ./FHEM/36_Shelly.pm line 3709.
So, ich hatte versehentlich das Starkstrombastler-Modul mit der Originalversion überbügelt.
Da ich beim Parsen der Modelle, die "Shelly" unterstützt, auf ein " " vor "model:" prüfte, konnte ich die Liste nicht parsen.
Konsequenzen:
- Anzeige von "n.s."
- Model wird beim Anlegen mit "Define"-Button nicht gesetzt
Habe eine neue, korrigierte ShellyMonitor-Version eingecheckt.
@Starkstrombastler: Eine Sache ist nicht so hübsch: Teste bitte mal das Modul, wenn die IP auf ein Gerät zeigt, dass auf Port 80 antwortet, aber kein Shelly ist. Dann wird das Logfile "geflutet".
Der Fall kann auftreten, wenn die IP eines längst vergessenes Shelly-Devices wiederverwendet wird.
2023.09.17 16:43:41 1: [Shelly_get_model] standard decoding: has invalid JSON data for device shelly_button_84cca8ac420f
2023.09.17 16:43:41 1: [Shelly_get_model] device shelly_button_84cca8ac420f has error "relaxed decoding: invalid JSON data, try to call /shelly"
2023.09.17 16:43:41 1: [Shelly_get_model] standard decoding: has invalid JSON data for device shelly_button_84cca8ac420f
2023.09.17 16:43:41 1: [Shelly_get_model] device shelly_button_84cca8ac420f has error "relaxed decoding: invalid JSON data, try to call /shelly"
2023.09.17 16:43:41 1: [Shelly_get_model] standard decoding: has invalid JSON data for device shelly_button_84cca8ac420f
2023.09.17 16:43:41 1: [Shelly_get_model] device shelly_button_84cca8ac420f has error "relaxed decoding: invalid JSON data, try to call /shelly"
2023.09.17 16:43:41 1: [Shelly_get_model] standard decoding: has invalid JSON data for device shelly_button_84cca8ac420f
2023.09.17 16:43:41 1: [Shelly_get_model] device shelly_button_84cca8ac420f has error "relaxed decoding: invalid JSON data, try to call /shelly"
2023.09.17 16:43:41 1: [Shelly_get_model] standard decoding: has invalid JSON data for device shelly_button_84cca8ac420f
Ich habe noch einen Bug:
Mein FHEM-System ist gerade mit folgender Meldung gecrasht:
Can't take sqrt of -45.5724 at ./FHEM/36_Shelly.pm line 2746.
Die Zeile lautet so:
$reactivePower = sprintf("%4.1f",sqrt( ($apparentPower * $apparentPower) - ($power * $power) )) if($apparentPower>$power);
Die if-Bedingung am Ende sollte eigentlich sicherstellen, dass der Wert zum Wurzelziehen niemals negativ werden kann. Kann er aber doch: Nämlich, wenn die Werte negativ sind :-), und apparentPower nicht so negativ wie power :-)
Das solltest Du fixen, z.B. so:
my $v = ($apparentPower * $apparentPower) - ($power * $power);
$reactivePower = sprintf("%4.1f",sqrt( $v )) if($v>0);
Ansonsten: Habe heute einen Shelly EM (das Gen1-Gerät, um 1-2 Kanäle zu messen) bekommen. Dafür wird es noch eine Anpassung an ShellyMonitor geben, damit das Gerät automatisch erkannt wird.
Die Physik des Wechselstroms hat so seine Tücken...
Zitat von: gvzdus am 18 September 2023, 13:28:33$reactivePower = sprintf("%4.1f",sqrt( $v )) if($v>0);
Der Blindstrom wird bei negativem Wurzeloperanten negativ, daher sollte Folgendes zutreffender sein:
my $v = ($apparentPower * $apparentPower) - ($power * $power);
$reactivePower = sprintf("%4.1f",($v<=>0)*sqrt( abs($v) ));
Mir doch alles wurscht: Blind-, Schein-, Wirkleistung. Hauptsache, FHEM kachelt nicht :-)
Hallo
habe gerade einen ShellyPlus i4 integriert.
Das Attribut webhooks scheint nicht zu funktionieren
Internals:
CFGFN
CMD Create
DEF 192.168.0.78
FUUID 650c1b07-f33f-547c-ce95-1717fde51d0f759b
INTERVAL 60
NAME shelly_Kizi_i4
NR 132437
SHELLY SNSN-0024X
SHELLYID shellyplusi4-90380c35e5e4
STATE OK
TCPIP 192.168.0.78
TYPE Shelly
eventCount 101
units 0
READINGS:
2023-09-21 12:29:43 cloud disabled
2023-09-21 12:29:43 firmware v1.0.3
2023-09-21 12:29:41 input_0 unknown
2023-09-21 12:29:43 input_0_mode button straight
2023-09-21 12:29:41 input_1 unknown
2023-09-21 12:29:43 input_1_mode button straight
2023-09-21 12:29:41 input_2 unknown
2023-09-21 12:29:43 input_2_mode button straight
2023-09-21 12:29:41 input_3 unknown
2023-09-21 12:29:43 input_3_mode button straight
2023-09-21 12:29:43 network <html>connected to <a href="http://192.168.0.78">192.168.0.78</a> (Wifi)</html>
2023-09-21 14:15:17 network_rssi -46
2023-09-21 12:29:43 network_ssid ddwrt
2023-09-21 13:42:17 state OK
2023-09-21 13:48:17 webhook_cnt 1
2023-09-21 14:11:17 webhook_ver 29
helper:
a_Active_Power 0
b_Active_Power 0
c_Active_Power 0
power 0
powerCnt 1
Attributes:
ShellyName shelly_Kizi_i4
model shellyplusi4
room 10 System
verbose 5
webhook WEB
Ich habe jetzt eines manuell mit dem Namen _button.zu_ angelegt
http://192.168.0.3:8088/fhem?XHR=1&cmd=set%20shelly_Rollo_KiZi%20closed%20
Wenn ich jetzt den Button am i4 betätige, wird der Befehl dann ca. alle 16s genau 4mal ausgeführt.
Zitat von: bene80 am 21 September 2023, 14:32:22Das Attribut webhooks scheint nicht zu funktionieren
Danke für den Hinweis. Im Modul (Version 4.09a) muss in Zeile 3893 wie folgt geändert werden:
my $subs= $compCount>1 ? "_$c\_mode" : "_mode" ;Wird im nächsten Update berücksichtigt.
Zitat von: bene80 am 21 September 2023, 14:32:22Ich habe jetzt eines manuell mit dem Namen _button.zu_ angelegt
Das geht natürlich auch. Allerdings sollte der Name der selbst erstellten Action nicht mit einem Unterstrich anfangen. Wenn das Attribut webhook gelöscht oder der Wert auf 'none' geändert wird, werden alle Actions, deren Namen mit Unterstrich beginnen, vom Shelly entfernt. --> Action auf dem Shelly umbenennen.
Zitat von: bene80 am 21 September 2023, 14:32:22http://192.168.0.3:8088/fhem?XHR=1&cmd=set%20shelly_Rollo_KiZi%20closed%20
Dieser Webhook geht gewissermaßen am Shelly-Modul vorbei, da ja der set-Befehl direkt an den Rollo-Shelly gerichtet ist. Das beschriebene Verhalten hat also nichts mit dem Shelly-Modul zu tun.
Der via Attribut webhook angelegte webhook würde in deinem Fall in etwa so aussehen (Taster am Eingang 1, entspricht Kanal=0):
http://192.168.0.3:8088/fhem?XHR=1&cmd=set%20shelly_KiZi_i4%20single_push%200 Diesen Webhook kannst du am Shelly mit +AddURL hinzufügen, um zu sehen was am i4 passiert.
Das geht natürlich auch. Allerdings sollte der Name der selbst erstellten Action nicht mit einem Unterstrich anfangen. Wenn das Attribut webhook gelöscht oder der Wert auf 'none' geändert wird, werden alle Actions, deren Namen mit Unterstrich beginnen, vom Shelly entfernt. --> Action auf dem Shelly umbenennen.
Oha, vielen Dank für den Hinweis, das werden ich noch ändern
http://192.168.0.3:8088/fhem?XHR=1&cmd=set%20shelly_KiZi_i4%20single_push%200
Hmm, verstehe einen eingehenden Befehl vom i4 müsste ich dann noch in FHEM mit dem Rollo verbinden, so sollte es funktionieren.
Ich finde es trotzdem ein wenig komisch, ich habe auch einen Shelly Button 2 der funktioniert genau so wie von mir oben beschrieben. Der Webhook geht ja trotzdem an einen shelly, also wieder ins Modul rein. Muss ich mir noch einmal anschauen
Zitat von: bene80 am 22 September 2023, 10:08:07Der Webhook geht ja trotzdem an einen shelly, also wieder ins Modul rein.
Ja, das stimmt gewissermaßen. Aber dein Rollladenaktor ist halt nur (zufällig) ein Shelly, es könnte auch ein anderes FHEM-Device oder irgendein anderes Gerät sein, welches in der Lage ist URLS zu interpretieren.
Zitat von: bene80 am 22 September 2023, 10:08:07Hmm, verstehe einen eingehenden Befehl vom i4 müsste ich dann noch in FHEM mit dem Rollo verbinden, so sollte es funktionieren.
Ich habe das so vorgeschlagen (eine Action mit zwei URLs), um zu sehen was im FHEM-i4-Device ankommt. Du hast schließlich ein merkwürdiges Verhalten an deinem Rolloaktor beschrieben.
Ansonsten ist mMn immer die einfachste ausreichende Lösung zu bevorzugen, also URL direkt an den Rollo-Aktor. Wenn es einen Grund für etwas komplizierteres gibt, dann sollte die URL auf den i4 gehen und die Readings des i4 triggern bspw. ein Notify.
Ich glaube das ist ein bug im shelly i4. Ich habe es jetzt so gelöst, dass ich mit dem i4 direkt ein shelly Relay schalte und nicht mit dem Umweg über fhem. Dann funktioniert es, das relay wird nur einmal geschaltet
Den Status lasse ich mir trotzdem an das fhem shelly i4 device schicken, so wie von dir vorgeschlagen. Da kommen dann genau 4 Befehle im Abstand von 16s an
2023-09-22_20:04:21 shelly_Kizi_i4 input_3: ON
2023-09-22_20:04:05 shelly_Kizi_i4 input_3: ON
2023-09-22_20:03:49 shelly_Kizi_i4 input_3: ON
2023-09-22_20:03:32 shelly_Kizi_i4 input_3: ON
Wüsste nicht wo ich das im shelly einstellen kann und warum es mit mit direkten HTTP-Requests funktioniert
Mir ist gerade aufgefallen, dass das alle V2 shellys so machen. Bei einem shely plus1 mit activierten output webhooks, sieht man in fhem, dass das device mehrmals einen Befehl erhält.
Hi zusammen,
vorab vielen Dank für das Shelly Modul, gefällt mir sehr gut.
Ich habe es bei mir eingebunden und nutze es mit einem Shelly3em. Dabei ist mir aufgefallen, dass bei den Readings nur ein Teil der verfügbaren Daten vorhanden zu sein scheint.
Konkret vermisse ich das total_returned bei den emeters. (ist unter https://shelly-api-docs.shelly.cloud/gen1/#shelly-3em-emeter-index auch dokumentiert.) Ich habe mal den Code im Github angeschaut und dort habe ich gesehen, dass der Teil einfach nicht mit eingelesen wird.
Jetzt kenne ich mich damit nicht so gut aus, könnte man das noch mit dazu nehmen?
(Hintergrund ist, dass ich eine Solaranlage hat, diese an einer Phase einspeist, aber an einer anderen wird noch was verbraucht. In Summe speise ich eigentlich noch ein, aber da es pro Phase betrachtet wird bleibt das "total" bei der einen stehen, bei der anderen läuft es weiter. In Summe geht der Energieverbrauch hoch, obwohl ich sogar einspeise.)
Hallo Boris,
herzlich Willkommen im Forum!
Zitat von: Boris am 23 September 2023, 16:09:12Konkret vermisse ich das total_returned bei den emeters
Der Shelly3EM kumuliert für jede Phase einerseits die bezogene Energie (total), andererseits die eingespeiste Energie (total_returned).
Das Modul liest diese Werte und legt sie in den Readings 'energy_0|1|2' und 'energy_returned_0|1|2' ab. Außerdem berechnet das Modul jedesmal die Summe von 'energy_0'+'energy_1'+'energy_2' und legt den Wert im Reading 'energy_TTL' ab. Entsprechend wird 'energy_returned_TTL' ermittelt.
Diese Readings sollten also vorhanden sein. Benutze das Attribut 'showunits', um die Einheiten zu sehen, dadurch wird das verständlicher.
Allerdings ermittelt der Shelly3EM keinen Saldo. Vereinfacht lässt sich der Saldo aus der Differenz von 'energy_TTL'-'energy_returned_TTL' ermitteln. Das stimmt aber nur, wenn die Leistungen auf den drei Phasen während des Erfassungsintervalls konstant sind. Liegt dagegen auf der Phase von der Solaranlage ein getakteter Verbraucher (z.B. Induktionskochfeld), so kann es passieren das auf dieser Phase in kurzen Abständen eingespeist und bezogen wird. Der Shelly zählt dann seine beiden Werte hoch.
Eine Verbesserung könnte durch ein hinreichend kleines Intervall erreicht werden. Zumindest beim ShellyPro3EM funktioniert das aber nicht, weil der Shelly mit einem internen Intervall von 60 Sekunden arbeitet. Dies wird sichtbar, wenn im Modul ein kleines Intervall eingestellt wird: neue Werte kommen dann trotzdem nur im Minutentakt.
Zumindest wird im nächsten Modulupdate für den Shelly3EM die oben erwähnte Differenz berechnet und als Reading ausgewiesen. Vielleicht liefert das ja trotzdem brauchbare Ergebnisse.
Hi Starkstrombastler,
vielen dank für das herzliche willkommen und die schnelle Antwort.
Vielleicht muss ich da dann was anders einstellen oder so, aber bei mir sehe ich die Readings energy_returned_0 etc nicht. Das aufsummieren der energy_* habe ich selbst manuell gemacht, da ich auch das energy_TTL nicht sehe.
Kann man irgendwo eine Versionsnummer des Shelly Moduls sehen um sicher zu sein, dass ich da nichts zu altes habe?
Update von FHEM habe ich allerdings ausgeführt. Und in dem code im Github habe ich auch keine Zeilen für energy_returned gefunden.
Was mache ich hier noch falsch?
Habe was bezüglich Version gefunden, mittels "update" kommt bei mir wohl folgendes Shelly Modul:
36_Shelly.pm 26017 2022-05-02 07:04:23Z phenning
Passt das?
Also zur Erklärung: Das Shelly-Modul wurde von P. Henning entwickelt, per update erhält man die letzte von ihm erstellte Version. Ab Dezember '22 habe ich mich an das Thema herangewagt und insbesondere Ergänzungen für die Plus- und Pro-Shellies entwickelt. Das überarbeitete Modul wurde von mir zunächst immer als Testversion hier im Forum zur Verfügung gestellt.
Die aktuell letzte Version findet sich hier (https://forum.fhem.de/index.php?action=dlattach;attach=172757) zum Herunterladen. Diese Datei ersetzt die auf deinem System vorhandene 36_Shelly.pm.
Damit die neue Version nicht durch das nächste Update überschrieben wird:
attr global exclude_from_update 36_Shelly.pm
Die aktuelle Version erhälst du im Shelly-Device mittels get <name> version.
Zitat von: bene80 am 22 September 2023, 20:25:14Ich glaube das ist ein bug im shelly i4. Ich habe es jetzt so gelöst, dass ich mit dem i4 direkt ein shelly Relay schalte und nicht mit dem Umweg über fhem. Dann funktioniert es, das relay wird nur einmal geschaltet
Den Status lasse ich mir trotzdem an das fhem shelly i4 device schicken, so wie von dir vorgeschlagen. Da kommen dann genau 4 Befehle im Abstand von 16s an
Ich kann das Verhalten des ShellyPlusI4 inzwischen auch auf meinem Testsystem sehen. Im Modul finde ich keine Ursache, ich denke dass die Shelly FW 1.0.3 eine nicht parametrierbare Wiederholfunktion hat.... Aber es wundert mich, dass dein Relais immer nur einen Schaltbefehl erhält.
Zitat von: Boris am 23 September 2023, 21:25:34....
36_Shelly.pm 26017 2022-05-02 07:04:23Z phenning
...
Es ist definitiv so, dass das "alte Original von Mai 2022" energyReturned nicht kann.
Ich habe Starkstrombastlers tolle Version zwar nur auf dem Testsystem - läuft bei mir mit Shelly1, 1PM, Plug-S, PlugPlus-S und 3EM ohne Auffälligkeiten.
Zitat von: Starkstrombastler am 23 September 2023, 22:17:08Ich kann das Verhalten des ShellyPlusI4 inzwischen auch auf meinem Testsystem sehen. Im Modul finde ich keine Ursache, ich denke dass die Shelly FW 1.0.3 eine nicht parametrierbare Wiederholfunktion hat.... Aber es wundert mich, dass dein Relais immer nur einen Schaltbefehl erhält.
Wie gesagt dieser Befehl funktioniert nicht, der wird immer 4 Mal ausgeführt.
http://192.168.0.3:8088/fhem?XHR=1&cmd=set%20shelly_Rollo_KiZi%20closed%20Dieser Befehl, der direkt an den shelly geschickt wird funktioniert. Der Status wird trotzdem 4Mal an fhem weitergeschickt. Klar dass der Rollo mehrmals färht
http://192.168.0.100/roller/0?go=closeEin shelly plus1 und 2 zeigt das selbe Verhalten. Bei denen ist das allerdings nicht immer und nur einmal. Außerdem ist mir aufgefallen, wenn man einen Schalter mehrmals hintereinander betätigt, dass diese Befehle nicht mehr direkt in FHEM ankommen, sondern erst mit Verzögerung. So als ob das Web Interface mit dem senden der Befehle nicht hinterherkommt
Hallo Zusammen,
Danke für die Erstellung und ständige Verbesserung dieses Moduls.
Ich habe mir vor kurzem auch zwei shellysi4 mit den dazugehörigen Shelly 4-fach Wandtastern für die Steuerung verschiedener zigbee Lampen zugelegt.
Nach langem Studium dieses Themas (leider funktioniert die Suchfunktion nicht) bin ich nun auch bei dem Problem, dass beide Shellyi4 jeden befehl viermal alle 16s senden. Das ist der Fall sowohl bei "Button" wie auch "Switch" Konfiguration im Shellyi4.
Hat jemand eine Idee wie man das im FHEM abfangen könnte, sodass das notify nicht viermal hintereinander ausgelöst wird?
Zitat von: RAM5869 am 26 September 2023, 08:54:58sodass das notify nicht viermal hintereinander ausgelöst wird
versuche mal die Events, auf welche das Notify reagiert mit
event-min-interval zu "drosseln", z.B. so:
attr ShellyPlusI4 event-min-interval input_0:60,input_1:60
Danke dir, das funktioniert erst einmal.
Hat nur den Nachteil, dass man den Taster erst wieder nach 60s benutzen kann.
Ich habe mir inzwischen das Debug Log vom Shelly angeschaut.
Leider geht ständig die Verbindung zum WebUI verloren:
Bildschirmfoto vom 2023-09-26 12-49-09.png
Das macht es schwierig das Debug log vom Shelly auszuwerten, da die Daten bei jedem Verbindungsverlust gelöscht werden. Ich habe deshalb mal ein Bildschirmvideo aufgezeichnet und daraus dann die Screenshots genau vor den Verbindungsverlusten geholt und hier zusammengesetzt:
Bildschirmfoto vom 2023-09-26 12-38-27.png
Bildschirmfoto vom 2023-09-26 12-41-04.png
Bildschirmfoto vom 2023-09-26 12-42-23.png
Bildschirmfoto vom 2023-09-26 12-43-25.png
Bildschirmfoto vom 2023-09-26 12-45-09.png
Darin ist zum Einen zu sehen, dass das WebUI die Verbindung immer bei der Statusabfrage verliert und zum Anderem das vierfache Senden des Shellys.
Es sieht so aus, als würde der Shelly auf eine Rückmeldung vom Modul warten, welche er nicht bekommt und deshalb noch einmal sendet "DEADLINE_EXCEEDED: Timed out". Nach dem vierten Versuch gibt er dann auf "failed too many times".
Vielleicht hilft dir diese Auswertung weiter.
Hallo RAM5860,
danke für die Analyse. Das Logging sehe ich jetzt auch so bei mir. Damit bestätigt sich, dass das Verhalten eigentlich ein Thema für das Shelly Support Forum ist.
Interessant wäre das Verhalten des ShellyPlusI4 mit älterer Firmware als 1.0.3. Ich kann das leider nicht nachstellen, weil es für die Gen-2 keine Firmware zum Download gibt.
Zitat von: RAM5869 am 26 September 2023, 13:17:20Leider geht ständig die Verbindung zum WebUI verloren:
Das passiert, wenn das Modul eine Anfrage an den Shelly sendet. Für "ungestörtes" Logging kann das Interval vorübergehend auf 0 gesetzt werden.
Das Shelly-Log lässt sich im Übrigen ganz komfortabel als Textdatei herunterladen. Interessante Abschnitte können dann hier im Forum in Code-Tags gesetzt werden.
Dabei kannst du auch deine ggf. sichtbaren Passwörter etc. verschleiern.
Hallo Starkstrombastler,
die Anfrage beim Shelly Support habe ich heute schon gestartet:
https://www.shelly-support.eu/forum/thread/22320-actions-werden-4x-im-abstand-von-16s-gesendet/?postID=231843#post231843 (https://www.shelly-support.eu/forum/thread/22320-actions-werden-4x-im-abstand-von-16s-gesendet/?postID=231843#post231843)
Allerdings habe ich auch dort das Problem, dass ich kein vollständiges Logfile über das vierfache senden zur Verfügung stellen kann.
Das Interval habe ich auf 0 gesetzt wie von dir empfohlen.
Beim Betätigen des Tasters wird aber dann die Anfrage gesendet, das WEBUI verliert die Verbindung und die Logeinträge werden gelöscht. Dadurch gibt es auch nichts zum herunterladen als Textdatei.
Das vierfache Senden kann ich also leider immer noch nicht in einem Logfile für den Shelly Support zur Verfügung stellen.
Dein Hinweise zu den Code-Tags werde ich gern umsetzen.
Danke für deine Unterstützung!
Moin zusammen,
hat schon jemand erfolgreich geschafft, einen ShellyPro3EM über FHEM einzubinden?
In dem FHEM commandref & in dem 36_Shelly.pm Modul taucht der ShellyPro3EM leider nicht mit auf ( <attr <name> model generic|shelly1|shelly1pm|shelly2|shelly2.5|shellyuni|shelly4|shellyplug|shellydimmer|shellyrgbw ).
Die Vermutung liegt daher nahe, dass dieser leider noch nicht von dem FHEM Modul supportet wird.
Allerdings taucht im FHEM wiki für das Modul bereits das Gerät "ShellyPro3EM" in einem Beispiel mit auf. ( https://wiki.fhem.de/wiki/Modul_Shelly )
Ich habe es trotzdem mit einem der anderen Modelle ausprobiert, doch es erscheint bei allen modellen nur im Fhem log ein Eintrag "[Shelly_configure] invalid JSON data for device <DEVICENAME>".
EDIT:
Falls noch jemand das gleiche Probleme haben sollte
-> Ich bin auf die angepasste Version für das Shelly Modul von Starkstrombastler gestoßen [ https://forum.fhem.de/index.php?topic=111905.msg1285498#msg1285498 ].
Hiermit funktioniert es, vielen Dank hierfür! :)
LG
LuWoody
Zitat von: LuWoody am 30 September 2023, 14:29:01Moin zusammen,
hat schon jemand erfolgreich geschafft, einen ShellyPro3EM über FHEM einzubinden?
...
Am 24.8.23 hat Starkstrombastler hier ein modifizierte Modul veröffentlicht. Damit klappt es.
ErdnaR
Hallo ErdnaR,
oh hat sich überschnitten, danke dir für deine schnelle Antwort :))
Zitat von: gvzdus am 13 September 2023, 15:01:40Gibt es eigentlich Erfahrungserte zur Genauigkeit der Shelly-Meter? Ein User hier im Forum hatte über 5% Abweichung bei einem ShellyPro3EM berichtet.
Habe seit ein paar Wochen einen Shelly Plus Plug S vor ein Energiemessgerät Brennenstuhl PM231E gesteckt. Die angeschlossene Durchschnittsleistung ist ca. 17 W und pendelt zwischen 13 W und 40 W. Der Brennenstuhl maß 12,800 kWh und der Shelly 12,353 kWh in derselben Periode von einem Monat (Differenz der Ablesezeiten Anfang Ende je max. 1 Minute). Das entspricht ca. 3,5 % relative Abweichung. Ohne ein geeichtes Gerät ist es aber nicht möglich, die Genauigkeit verbindlich zu bestimmen. Ich vergleiche hier ja auch nur zwei ungenaue Geräte miteinander.
@Boris
Vergessen darf man auch immer nicht den Eigenverbrauch der Geräte.
Grundsätzlich kalkuliere ich Shelly etc. - zugegeben sehr grob - mit 0,5Watt, pro Gerät. Shelly selbst gibt "<1Watt" in den Unterlagen an.
Wenn man mal unterstellt, das die Brennenstuhl ähnlich viel verbraucht (die Batterien dienen ja nur als Buffer für den internen Speicher), dann muss! die Shelly mehr messen, als die Brennenstuhl. Nämlich eben jene 0,5Watt Eigenverbrauch der Brennstuhl.
So gesehen sind deine beiden Geräte zwar nicht geeicht, aber im direkten Vergleich doch zumindest annähernd gleich (un-)genau und die Abweichung dürfte deutlich geringer sein?
Wieviel misst die Shelly denn ohne Last hinter der Brennenstuhl?
Wegen des Teils hohen Eigenverbrauch macht es - um Energie zu sparen - in meiner Welt keinen Sinn, jede Steckdose smart zu machen.
Auch die 0,5Watt summieren sich, so das der Spargedanke schnell ad absurdum geführt wird.
Zum Thema Genauigkeit:
Vom 31.08. - 30.09 hat mein offizieller Zähler 131,2kWh gemessen.
Im gleichen Zeitraum hat mein Shelly 3EM 124,4kWh ermittelt.
Ein Grund für einen Teil der Abweichung:
Die Ablesung erfolgte am 31. nachmittags.
Der Shelly zählte aber für September erst ab 01.09. 00:00Uhr
Die Stunden dazwischen verschwinden also in der Betrachtung erstmal im Nirvana.
Ich hoffe, das sie im Jahresmittel wieder in Erscheinung treten.
Weiterer Grund: der Eigenverbrauch des 3EM
Der wird zwar natürlich vom Zähler erfasst, aber nicht vom 3EM selbst.
Shelly selbst gibt auch hier den Eigenverbraucht mit "<1Watt" an.
1Watt..., wenn ich richtig rechne liegt der Eigenverbrauch des 3EM dann auf 30 Tage schon bei 0,7kWh!?
Wenn man all das in Betracht zieht, ist der direkte Vergleich der Werte immer mit einer gewissen "Unschärfe" versehen.
Von daher bin ich aktuell zufrieden.
vb
Tolles Modul, vielen Dank an den Entwickler!
Ein Featurewunsch hätte ich noch: Eine "disable" Funktion finde ich nicht. Das wäre sehr hilfreich, denn momentan habe ich den Shelly nicht im Betrieb und das Modul meldet ständig "nicht erreichbar".
Zitat von: FhemPiUser am 03 Oktober 2023, 15:45:35Ein Featurewunsch hätte ich noch: Eine "disable" Funktion finde ich nicht. Das wäre sehr hilfreich, denn momentan habe ich den Shelly nicht im Betrieb und das Modul meldet ständig "nicht erreichbar".
attr Devicename interval 0
Gruß, Joachim
Zitat von: VB90 am 03 Oktober 2023, 14:26:32Vergessen darf man auch immer nicht den Eigenverbrauch der Geräte.
Das ist ein wichtiger Hinweis.
Ich habe mir gerade das Setup angeschaut und festgestellt, dass es anders herum ist als eben geschildert: der Shelly steckt im Brennenstuhl. Der Brennenstuhl misst also das, was der Shelly misst, plus den Eigenverbrauch des Shelly. So gesehen ist es also erst einmal plausibel, dass der Brennenstuhl mehr Energie als der Shelly gemessen hat.
Die Messung betraf den September mit 30 Tagen à 24 Stunden. 1 Watt im Dauerbetrieb verbrät 0,720 kWh. Der Brennenstuhl hat 0,447 kWh mehr als der Shelly gemessen. Mal angenommen, beide Geräte würden exakt gleich messen, dann hätte der Shelly eine Leistungsaufnahme von 0,6 W. Und das ist konsistent mit der Tatsache, dass der Durchschnittsverbrauch des Setups (gemessen mit dem Brennenstuhl) nach dem Anstecken des Shelly um ca. 0,6 W (von 17,2 auf 17,8) gestiegen ist.
Super das sich jemand des Moduls angenommen hat und die Gen.2 Geräte integriert.
Ich habe vor einer Weile das letzte 36_Shelly.pm, das ich in diesem Threat finden konnte eingespielt in mein Operativsystem und bisher keine Probleme feststellen können.
Der state ist zwar nicht mehr Error wenn die Verbindung gestört ist aber das habe ich über die Abfrage von Network auf "not connected" gelöst.
Gibt es noch Gründe warum das Modul nicht im FHEM Modulstamm aktualisiert werden sollte ?
Hallo zusammen,
nachdem ich einen 3EM erfolgreich integriert habe (Danke für das Modul und die Erweiterung), habe ich mir direkt mal ein paar Shelly Plus PMMini (https://www.shelly.com/de/products/shop/shelly-plus-pm-mini) bestellt.
Nach der Einrichtung musste ich feststellen, dass sie "nur" als generic erkannt werden und eine JSON Error anzeigten.
Es war Sonntag und ich ungeduldig. Also habe ich mich durch den Modulcode und die API-Beschreibung gewühlt...
Ein ../rpc/Shelly.GetStatus liefert neben den Statusinformationen auch die Werte zurück, die ich haben wollte: Current, Voltage, Power und Energy. Allerdings sind die hier verschachtelt unter "pm1:0".
Ein ../rpc/pm0.GetStatus?id=0 liefert die Daten direkt (also ohne die anderen Statusmeldungen zurück). Das erfordert dann aber einen zusätzlichen HTTP-Aufruf.
Daher habe ich mich entschieden, das Device "Quick&Dirty" über Shelly.GetStatus auszulesen.
Folgende Änderungen am Modul habe ich dazu eingebaut:
Zeile 41 -> damit man das unterschiden kann
my $version = "4.09_pmmini 09.10.2023";
Zeile 293 in shelly_vendor_ids
my %shelly_vendor_ids = (
...
"SNSW-001X16EU" => "shellyplus1",
"SNPM-001PCEU16" => "shellypluspmmini",
"SNSW-001P16EU" => "shellyplus1pm",
...
Zeile 340 in shelly_models
my %shelly_models = (
...
"shellyplus1pm" => [1,0,0, 1,1,1],
"shellypluspmmini" => [0,0,0, 1,1,0],
"shellyplus2pm" => [2,1,0, 2,1,2],
...
und letztlich in der Shelly.GetStatus Auswertung nach diesem wifi block
if( $wifi_status eq "got ip"){
readingsBulkUpdateIfChanged($hash,"network_ssid",$jhash->{'wifi'}{'ssid'});
readingsBulkUpdateIfChanged($hash,"network_rssi",$jhash->{'wifi'}{'rssi'}.$si_units{'rssi'}[$hash->{units}]);
}else{ # if( $wifi_status eq "disconnected"){
readingsBulkUpdateIfChanged($hash,"network_ssid",'-');
readingsBulkUpdateIfChanged($hash,"network_rssi",'-');
}
## hier folgt das auslesen des shellypluspmmini
if($model eq "shellypluspmmini" && $meters > 0)
{
Log3 $name,4,"[Shelly_proc2G] $name of $model as $comp returned $data";
#checking for errors (if present)
$errors = $jhash->{'errors'}[0]; ##R new
$errors = "none"
if (!$errors);
$voltage = $jhash->{'pm1:0'}->{'voltage'}.$si_units{'voltage'}[$hash->{units}];
$current = $jhash->{'pm1:0'}->{'current'}.$si_units{'current'}[$hash->{units}];
$power = $jhash->{'pm1:0'}->{'apower'} .$si_units{'power'}[$hash->{units}];
$pfactor = $jhash->{'pm1:0'}->{'pf'};
$freq = $jhash->{'pm1:0'}->{'freq'};
$energy = shelly_energy_fmt($hash,$jhash->{'pm1:0'}->{'aenergy'}{'total'},"Wh");
$minutes = shelly_energy_fmt($hash,$jhash->{'pm1:0'}->{'aenergy'}{'by_minute'}[0],"mWh"); # Energy consumption by minute (in Milliwatt-hours) for the last minute
Log3 $name,4,"[Shelly_proc2G] $name $comp voltage=$voltage, current=$current, power=$power";
readingsBulkUpdateMonitored($hash,"voltage",$voltage);
readingsBulkUpdateMonitored($hash,"current",$current);
readingsBulkUpdateMonitored($hash,"power",$power);
readingsBulkUpdateMonitored($hash,"pfactor",$pfactor) if( defined($pfactor) ); # PF not supported by all models, eg. ShellyPlusPlugS
readingsBulkUpdateMonitored($hash,"frequency",$freq) if( defined($freq) ); # frequency supported from fw 1.0.0
readingsBulkUpdateMonitored($hash,"energy",$energy);
readingsBulkUpdateMonitored($hash,"energy_lastMinute",$minutes);
readingsBulkUpdateMonitored($hash,"protection",$errors);
if( defined($jhash->{'temperature'}{'tC'}) ){
readingsBulkUpdateMonitored($hash,"inttemp",$jhash->{'temperature'}{'tC'}.$si_units{'tempC'}[$hash->{units}]);
}elsif( defined($jhash->{'temperature:0'}{'tC'}) ){
readingsBulkUpdateMonitored($hash,"inttemp",$jhash->{'temperature:0'}{'tC'}.$si_units{'tempC'}[$hash->{units}]);
}
}
...
Ich häng das geänderte 36_Shelly.pm-Modul mal hier dran in der Hoffnung es hilft jemanden. Vielleicht kann das jemand korrekt oder besser integrieren und vll finden die neuen Shellys ja so auch irgendwann den weg ins offizielle Repo?
Gruß,
Tobias
Zitat von: bombardi am 09 Oktober 2023, 10:17:18Gibt es noch Gründe warum das Modul nicht im FHEM Modulstamm aktualisiert werden sollte ?
na ja, wenn man das noch nie gemacht hat muss man sich dafür ein bischen Zeit nehmen...
Zitat von: tobi01001 am 09 Oktober 2023, 12:30:09Vielleicht kann das jemand korrekt oder besser integrieren und vll finden die neuen Shellys ja so auch irgendwann den weg ins offizielle Repo?
In der nächsten Version wird dieser Vorschlag übernommen, er scheint ja so zu funktionieren.
Zitat von: Starkstrombastler am 09 Oktober 2023, 16:32:41ZitatVielleicht kann das jemand korrekt oder besser integrieren und vll finden die neuen Shellys ja so auch irgendwann den weg ins offizielle Repo?
In der nächsten Version wird dieser Vorschlag übernommen, er scheint ja so zu funktionieren.
Jeeeiiinnn.
Im Prinzip funktionierte es ganz gut. Allerdings fehlt da eine gewisse Fehlerbehandlung. Hatte da seltsame Effekte bei denen sich Readings außerhalb des Intervals aber dennoch im Intervallabstand gelöscht haben und sich Warnigns im Log häuften...
Also Fehlersuche....
Im define macht das Modul erst:
Shelly_status mittels Timer und dann Shelly_shelly ebenfalls mittels Timer.
Shelly_status kann auch manuell über get angestoßen werden...
/rpc/Shelly.GetStatus wird über Shelly_shelly für die 2g Shellies abgefragt.
Soweit so gut....
Wenn man allerdings einmal "shelly_status" aufgerufen hat, erfolgt im Zweig für die 2g Devices ein
my $comp = AttrVal($name,"mode","relay");Nachdem das attr nicht gesetzt ist, haben wir den Ersatzwert "relay" und der führt in der Folge durch das if..elsif..else zu einem Aufruf von:
http://ShellyURL/rpc/Switch.GetStatus?id=0 nonblocking mit Shelly_proc2G als callback (wegen 2g Shelly). Das wird vom pmmini mit:
{"code":404,"message":"No handler for Switch.GetStatus"} beantwortet.
Da das gültiges JSON ist, erfolgt keine direkte Fehlerbehandlung und die Readings werden fälschlicherweise mit nichts überschrieben.
Das Problem dabei ist, dass Shelly_proc2G den Timer erneut auf Shelly_status setzt, und das beim normalen Durchlauf, als auch in der Fehlerbehandlung.
Bei Shelly_shelly erfolgt das Setzen der Timer in Shelly_shelly direkt. Da dort aber ebenfalls Shelly_proc2G Callback ist, werden die Timer für shelly_status wieder gesetzt...
Long Story short:Ich habe mir jetz quick&dirty dadurch beholfen, in der Shelly_status for der HTTP-Aufruf-Schleife (bzw. direkt nach dem else für 2g devices) ein
return undef if($model eq "shellypluspmmini"); da die entsprechenden Readings ja über Shelly_shelly bereits im gleichen Intervall aktualisiert werden und merh abfragen für den pmmini nicht erforderlich sind.
Das schaut aber insgesamt recht suboptimal aus und wirkt hinsichtlich Modul wohl eher in Richtung Fragemtierung. Vielleicht habe ich mal Zeit und Lust das zu optimieren und strukturieren....
Zitat von: tobi01001 am 11 Oktober 2023, 22:03:11Das schaut aber insgesamt recht suboptimal aus und wirkt hinsichtlich Modul wohl eher in Richtung Fragemtierung.
Der Versuch zeigt mir aber, dass das Modul zwar wegen seiner Größe unübersichtlich erscheinen mag, aber trotzdem gelingt es zusätzliche Funktionalität einzubauen.
Vom Grundsatz her ist aber die Schleife für das PMmini falsch eingebaut. Sie gehört nicht in Shelly_shelly() sonder in Shelly_status():
Shelly_status() erledigt das operative zyklische Abfragen des Shelly, evtl. mit sehr kurzen Intervallen;
Shelly_shelly() ist für das Abfragen von Randbedingungen, wie z.B. Firmwarestand, zuständig und kommt mit langen Intervallen aus.
Das wird in den nächsten Tagen in einer Testversion richtig eingebaut sein. Diese Testversion wird auch eine
Saldierung für den ShellyPro3EM enthalten.
Damit die Erweiterungen für alle Modulnutzer ohne Umwege zur Verfügung stehen, muss das aktuelle Modul noch im SVN eingecheckt werden. Hierzu steht noch eine Freigabe des ursprünglichen Modulentwicklers aus. Falls PAH hier mitliest möge er bitte mal in sein PM-Postfach schauen.
Zitat von: Starkstrombastler am 13 Oktober 2023, 08:42:43Zitat von: tobi01001 am 11 Oktober 2023, 22:03:11Das schaut aber insgesamt recht suboptimal aus und wirkt hinsichtlich Modul wohl eher in Richtung Fragemtierung.
Der Versuch zeigt mir aber, dass das Modul zwar wegen seiner Größe unübersichtlich erscheinen mag, aber trotzdem gelingt es zusätzliche Funktionalität einzubauen.
Vom Grundsatz her ist aber die Schleife für das PMmini falsch eingebaut. Sie gehört nicht in Shelly_shelly() sonder in Shelly_status():
Shelly_status() erledigt das operative zyklische Abfragen des Shelly, evtl. mit sehr kurzen Intervallen;
Shelly_shelly() ist für das Abfragen von Randbedingungen, wie z.B. Firmwarestand, zuständig und kommt mit langen Intervallen aus.
Das war mir aufgefallen. Aber (aktuell):
- wird Shelly_shelly im gleichen Intervall aufgerufen
- liefert ein /rpc/Shelly.GetStatus die Messwerte unter pm1:0 direkt mit.
Um den Traffic nicht doppelt zu haben, hatte ich das über Shelly.GetStatus ausgelesen und eingebaut.
Wenn man jetzt natürlich das Intervall für Shelly_shelly auf ein vielfaches von INTERVAL setzt, und evtl. ein minimum von x Minuten, ist es mit dedizierter Abfrage des Kanals ../rpc/pm0.GetStatus?id=0 in Shelly_status besser aufgehoben.
Solange sich die Namen der Readings nicht ändern, sollte sich das ja rückwirkungsfrei ändern lassen.
Zitat von: tobi01001 am 13 Oktober 2023, 10:29:18Zitat von: Starkstrombastler am 13 Oktober 2023, 08:42:43Zitat von: tobi01001 am 11 Oktober 2023, 22:03:11Das schaut aber insgesamt recht suboptimal aus und wirkt hinsichtlich Modul wohl eher in Richtung Fragemtierung.
Der Versuch zeigt mir aber, dass das Modul zwar wegen seiner Größe unübersichtlich erscheinen mag, aber trotzdem gelingt es zusätzliche Funktionalität einzubauen.
Vom Grundsatz her ist aber die Schleife für das PMmini falsch eingebaut. Sie gehört nicht in Shelly_shelly() sonder in Shelly_status():
Shelly_status() erledigt das operative zyklische Abfragen des Shelly, evtl. mit sehr kurzen Intervallen;
Shelly_shelly() ist für das Abfragen von Randbedingungen, wie z.B. Firmwarestand, zuständig und kommt mit langen Intervallen aus.
Das war mir aufgefallen. Aber (aktuell):
- wird Shelly_shelly im gleichen Intervall aufgerufen
- liefert ein /rpc/Shelly.GetStatus die Messwerte unter pm1:0 direkt mit.
Um den Traffic nicht doppelt zu haben, hatte ich das über Shelly.GetStatus ausgelesen und eingebaut.
Wenn man jetzt natürlich das Intervall für Shelly_shelly auf ein vielfaches von INTERVAL setzt, und evtl. ein minimum von x Minuten, ist es mit dedizierter Abfrage des Kanals ../rpc/pm0.GetStatus?id=0 in Shelly_status besser aufgehoben.
Solange sich die Namen der Readings nicht ändern, sollte sich das ja rückwirkungsfrei ändern lassen.
Alsooo: Das lange Intervall in Shelly_shelly wird lediglich für den shellypro3em auf ein vielfaches von 60 gesetzt. Alle anderen werden mit dem eingestellten intervall aktualisiert. Schaut nach "Copy/Paste" vom 3em aus.
Ich habe das jetzt auskommentiert und den shellypluspmmini in Shelly_status als "eMeter" eingebaut.
Bedeutet:
Shelly.(GetStatus|GetConfig|GetDeviceInfo) nur noch alle x*60 Sekunden.
Shelly_status im normalen Intervall.
Saldierung für den 3em ist da nicht drin, da ich die nicht kenne....
Kannst du von hier gerne übernehmen: 36_Shelly.pm
LG,
Tobias
Hallo,
ich verzweifele gerade :'(
Gestern habe ich einen Shelly Plus 1PM mini verbaut und wollte ihn gerade in FHEM integrieren.
Eingerichtet habe ich ihn analog zum Plus 1PM (ohne mini). Ich "sehe" auch alle Daten, kann aber zum Verrecken nicht schalten.
Per http Kommando <IP>/rpc/Switch.Set?id=0&on=false oder true kann ich den Shelly ansprechen.
Kann mir da jemand weiterhelfen?
Falls noch weitere Informationen benötigt werden, stelle ich diese gerne zur Verfügung.
Danke und ein schönes Wochenende!
Zitat von: mannil am 14 Oktober 2023, 14:00:16Hallo,
ich verzweifele gerade :'(
Gestern habe ich einen Shelly Plus 1PM mini verbaut und wollte ihn gerade in FHEM integrieren.
Eingerichtet habe ich ihn analog zum Plus 1PM (ohne mini). Ich "sehe" auch alle Daten, kann aber zum Verrecken nicht schalten.
Per http Kommando <IP>/rpc/Switch.Set?id=0&on=false oder true kann ich den Shelly ansprechen.
Kann mir da jemand weiterhelfen?
Falls noch weitere Informationen benötigt werden, stelle ich diese gerne zur Verfügung.
Danke und ein schönes Wochenende!
Was steht jeweils im attribut model?
Ist ein attribut mode gesetzt?
Jeweils ein
.../rpc/Shelly.GetConfig
und das Log bei Verbose 5 beim Versuch zu schalten...
Könnte für eine Analyse helfen...
Zitat von: mannil am 14 Oktober 2023, 14:00:16Gestern habe ich einen Shelly Plus 1PM mini verbaut und wollte ihn gerade in FHEM integrieren.
Eingerichtet habe ich ihn analog zum Plus 1PM (ohne mini). Ich "sehe" auch alle Daten, kann aber zum Verrecken nicht schalten.
Per http Kommando <IP>/rpc/Switch.Set?id=0&on=false oder true kann ich den Shelly ansprechen.
Die bisherigen Shelly-Plus sind bezüglich der Schaltbefehle kompatibel zu den Geräten der 1. Generation, daher sind die Gen2-Schaltbefehle noch nicht im Shelly-Modul implementiert. Diese Kompatibilität scheint bei den Shelly-Minis nicht mehr der Fall zu sein.
Zur überprüfung kannst du dir den Befehl, der beim Schalten an den Shelly geschickt wird mit verbose=4 im Log anschauen. Dort sollte ein Eintrag in der Form
"issue a non-blocking call to <ip-des-shelly>...." erscheinen. Was passiert wenn du diesen Gen1-Befehl direkt im Browser eingibst?
Guten Abend,
das Attribut model steht auf "shellyPlus_1pm".
Im Gerät habe ich verbose auf 5 gestellt.
Wenn ich nun einen Schaltbefehl aus FHEM absetzte erscheint im FileLog des Gerätes überhaupt nichts. Ich habe da nur die minütlichen Übertragungen:
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 params_switch_0_aenergy_total: 115.507
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 method: NotifyStatus
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 params_ts: 1697391660.37
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 params_switch_0_aenergy_by_minute_3: 205.528
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 dst: shelly1pmmini-6055f9a00144/events
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 params_switch_0_aenergy_by_minute_1: 205.528
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 params_switch_0_aenergy_by_minute_2: 205.528
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 params_switch_0_aenergy_minute_ts: 1697391659
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 params_switch_0_id: 0
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 set_on
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 voltage: 236.6
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 source: switch
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 id: 0
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 output: true
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 current: 0.076
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 temperature_tF: 107.7
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 freq: 50.0
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 aenergy_minute_ts: 1697391659
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 aenergy_total: 115.507
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 aenergy_by_minute_2: 205.528
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 aenergy_by_minute_3: 205.528
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 aenergy_by_minute_1: 205.528
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 temperature_tC: 42.0
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 apower: 12.0
2023-10-15_19:41:00 MQTT2_shelly1pmmini_6055f9a00144 Kosten_Euro: 0.04
Wenn ich den <IP>/rpc/Switch.Set?id=0&on=true absetze, ändert sich im Logfile auch nichts.
Kann mir da jemand nochmal helfen? Ich glaube, ich mache da etwas falsch und die Informationen helfen nicht weiter.
Schönen Abend!
Edit:
Im großen Logfile kommt (auch bei verbose 5) nur folgendes:
2023.10.15 19:46:13 3: MQTT2_DEVICE set MQTT2_shelly1pmmini_6055f9a00144 on
und im Minutenrhythmus
2023.10.15 19:47:00 4: MQTT2_DEVICE_Parse: MQTT2_shelly1pmmini_6055f9a00144 shelly1pmmini-6055f9a00144/events/rpc => { json2nameValue($EVENT) }
2023.10.15 19:47:00 4: MQTT2_DEVICE_Parse: MQTT2_shelly1pmmini_6055f9a00144 shelly1pmmini-6055f9a00144/status/switch_0 => { json2nameValue($EVENT) }
Hallo mannil,
in diesem Thread diskutieren wird das Shelly-Modul 36_Shelly.pm. Hier im Thread wurden diverse Testversionen vorgestellt, die letzte vom 24.08.2023.
MQTT ist aber eine andere Baustelle. Wenn du statt des Shelly-Moduls lieber MQTT nutzen möchtest, solltest du die Probleme im zugehörigen Thread posten.
Gruß
Starkstrombastler
Hallo Starkstrombastler,
das habe ich übersehen. Sorry!
Zitat von: Starkstrombastler am 23 September 2023, 21:57:49Also zur Erklärung: Das Shelly-Modul wurde von P. Henning entwickelt, per update erhält man die letzte von ihm erstellte Version. Ab Dezember '22 habe ich mich an das Thema herangewagt und insbesondere Ergänzungen für die Plus- und Pro-Shellies entwickelt. Das überarbeitete Modul wurde von mir zunächst immer als Testversion hier im Forum zur Verfügung (https://www.deutsche-rechtsschutzversicherung.de/rechtsschutz-gegen-allgemeinverfuegung/)gestellt.
Die aktuell letzte Version findet sich hier (https://forum.fhem.de/index.php?action=dlattach;attach=172757) zum Herunterladen. Diese Datei ersetzt die auf deinem System vorhandene 36_Shelly.pm.
Damit die neue Version nicht durch das nächste Update überschrieben wird:
attr global exclude_from_update 36_Shelly.pm
Die aktuelle Version erhälst du im Shelly-Device mittels get <name> version.
Nichts ist für den Menschen als Menschen etwas wert, was er nicht mit Leidenschaft tun kann.
Hi, ich kann die o.g. aktuell letzte Version nicht downloaden, weiß aber auch nicht so recht, wie ich bei meinem Problem weitermachen soll? Wende mich deshalb wie von Beta-user empfohlen an euch!
Zitat von: uron am 20 Oktober 2023, 13:06:11Ich komme mit der Installation meines neuen Shelly Plus 2PM als Rollladenschalter auch nach Lesen der Beiträge nicht klar:
Zunächst die Info, dass ich das Rollo über die App steuern kann, eine ordnungsgemäße Verbindung steht also.
Nun zur FHEM-Integration und dem list
Internals:
DEF 192.168.2.171
FUUID 65323e84-f33f-aab4-9081-68dac3f93798e562
INTERVAL 40
NAME EG_Rollo_Gaeste_WC_R
NR 1422
STATE pct
TCPIP 192.168.2.171
TYPE Shelly
eventCount 9
OLDREADINGS:
READINGS:
2023-10-20 11:26:59 network <html>connected to <a href="http://192.168.2.171">192.168.2.171</a></html>
2023-10-20 11:51:37 state Error
Attributes:
alias EG_Rollo_Gaeste_WC_R
devStateIcon 100:fts_shutter_10@green 0:fts_shutter_100@black
event-on-change-reading inttemp:2
eventMap open:öffnen closed:schließen
icon shutter_4
interval 40
maxtime 20
mode roller
model shelly2.5
room Favourites,Gäste-WC,Shelly-Devices
stateFormat pct
timeout 10
verbose 3
webCmd öffnen:schließen:stopIm Reading state fällt natürlich direkt "Error" auf.
Wenn ich den Rollladen per FHEM starte, entpuppt sich der Fehler als
Error: roller blind EG_Rollo_Gaeste_WC_R still moving, wait for some time
Als Modell habe ich "shelly2.5" eingetragen, ein "shelly2PM" ist ja nicht in der Modell-Auswahlliste enthalten.
Die Konfiguration entspricht genau der eines weiteren Rollladenmotors, der jedoch über einen Shelly 2.5 angesteuert wird.
Kann mir jemand weiterhelfen?
Zitat von: Beta-User am 21 Oktober 2023, 12:13:27Zitat von: uron am 20 Oktober 2023, 13:06:11Ich komme mit der Installation meines neuen Shelly Plus 2PM
[...]
Kann mir jemand weiterhelfen?
Für die "Plus"-Modelle musst du ein gepatchtes Shelly-Modul verwenden, bitte den support-Thread dazu konsultieren.
Zitat von: uron am 21 Oktober 2023, 14:56:20Hi, ich kann die o.g. aktuell letzte Version nicht downloaden, weiß aber auch nicht so recht, wie ich bei meinem Problem weitermachen soll? Wende mich deshalb wie von Beta-user empfohlen an euch!
Welche o.g. Version meinst du? Die aus dem Beitrag #526 vom 24.8?
https://forum.fhem.de/index.php?topic=118446.msg1284884#msg1284884
Die musst du manuell in das Verzeichnis /opt/fhem/FHEM kopieren (und "reload 36_Shelly.pm" / vielleicht besser Restart FHEM) und momentan auch das Modul 36_Shelly.pm vom Update ausschließen, sonst wird wieder die alte Vesion installiert.
Das "offizielle" Modul hat einen älteren Stand und kann mit vielen der neuen Shellies nicht umgehen.
Daher hat Starkstrombastler Anfang des Jahres eine Weiterentwicklung angestoßen, die hier im Beitrag diskutiert wird. Noch ist es nicht in der "offiziellen" FHEM-SW enthalten.
Ob der Shelly Plus 2PM schon abgedeckt ist, weiss ich aber nicht. Mein Testsystem läuft gerade nicht daher kann ich auch nicht nachschauen.
Gruß Ralf
Edit:
Denke ist drin. Steht in der Deviceliste im Code.
Danke, hab's kapiert, konnte nun die aktuelle Version doch downloaden ???, hab sie in das Verzeichnis kopiert und einen Restart gemacht.
Fazit: Der 2PM ist in der Modellauswahl enthalten, beim Ansteuern des Rollladens ändert sich allerdings nur die Fehlermeldung im state, die "position" ist falsch, da der Rolladen voll geöffnet istm hier das list:
Internals:
CMD open
DEF 192.168.2.171
DURATION 0
FUUID 65323e84-f33f-aab4-9081-68dac3f93798e562
INTERVAL 40
MOVING drive-down
NAME EG_Rollo_Gaeste_WC_R
NR 1422
SHELLY SNSW-102P16EU
STATE pct
TARGETPCT 0
TCPIP 192.168.2.171
TYPE Shelly
eventCount 9
units 0
OLDREADINGS:
READINGS:
2023-10-21 15:49:22 network invalid JSON data
2023-10-21 15:49:22 network_disconnects 1
2023-10-21 07:53:42 position closed
2023-10-21 15:49:22 state Error: JSON
helper:
a_Active_Power 0
b_Active_Power 0
c_Active_Power 0
power 0
powerCnt 1
Attributes:
ShellyName G�ste-WC Rollo rechts
alias EG_Rollo_Gaeste_WC_R
devStateIcon 100:fts_shutter_10@green 0:fts_shutter_100@black
event-on-change-reading inttemp:2
eventMap open:öffnen closed:schließen
icon shutter_4
interval 40
maxtime 20
mode roller
model shellyplus2pm
room Favourites,Gäste-WC,Shelly-Devices
stateFormat pct
timeout 10
verbose 3
webCmd öffnen:schließen:stopMerkwürdigerweise steht "pct" auf "0", obwohl der Rollo geöffnet ist, aber egal ob ich öffne oder schließe, es gibt keine Systemreaktion und der Rollladen bewegt sich nicht.
Immerhin Schritt 1 vollzogen.
Als Rolladensteuerung nutze ich die Shellies nicht. Da hat aber bestimmt jemand Erfahrung und meldet sich ;)
Gruß Ralf
Danke für den ersten Schritt, bisher bin ich mit der Rollladensteuerung per Shelly doch sehr zufrieden!
Konnte mein Problem mit dem falsch angezeigten Status lösen in dem ich
get EG_Rollo_Gaeste_WC_R statusaufgerufen habe, danach war die Steuerung kein Problem mehr - bin nun wieder zufrieden :)
Hi,
seit ner Woche hab ich nun nen neuen Shelly PlusPlug S.
Unter attributes, hab ich model shellyplug eingestellt.
Nicht nur das die Web-GUI komplett neu aussieht, als bei meinen anderen ShellyPlugs, FEHM liest das Gerät auch nicht mehr komplett aus.
Mit dem von Starkstrombastler vorgestellten Modul werden nur folgende Werte zurückgegeben:
READINGS:
2023-10-22 12:22:02 network invalid JSON data
2023-10-22 12:22:02 network_disconnects 2
2023-10-22 05:47:16 overpower 0
2023-10-22 05:47:16 relay on
2023-10-22 12:22:02 state Error: JSON
Mit dem "original" Modul, sieht es dann so aus:
READINGS:
2023-10-22 12:22:02 network invalid JSON data
2023-10-22 12:22:02 network_disconnects 2
2023-10-22 05:47:16 overpower 0
2023-10-22 05:47:16 relay on
2023-10-22 12:27:45 state Error
Versuch ich das Gerät per MQQT auszulesen kann ich in FHEM kein passendes attrTemplate zuweisen, der Eintrag für "shellyplug" wird sogar nicht mal aufgelistet.
Aber dies nur als Neben-Info, MQQT soll hier nicht das Thema sein.
Muss am Device etwas eingestellt werden, oder muss ich lediglich warten, bis das Modul angepasst ist?
Danke und
Gruß aus Oberfranken
matt
Zitat von: matt_577 am 22 Oktober 2023, 12:36:55Muss am Device etwas eingestellt werden, oder muss ich lediglich warten, bis das Modul angepasst ist?
Ich habe die Modulversion vom 16.08.2023. Bei mir werden viel mehr Readings angezeigt, u.a. Verbrauch. Ich habe das model-Attribut auf shellyplus1pm gesetzt.
Zitat von: matt_577 am 22 Oktober 2023, 12:36:55Unter attributes, hab ich model shellyplug eingestellt.
In der Testversion des Moduls wird versucht, das
model automatisch zu ermitteln. Lösche hierzu das Attribut
model und setze
get <device> model
Zitat von: Dr. Boris Neubert am 22 Oktober 2023, 12:41:52Zitat von: matt_577 am 22 Oktober 2023, 12:36:55Muss am Device etwas eingestellt werden, oder muss ich lediglich warten, bis das Modul angepasst ist?
Ich habe die Modulversion vom 16.08.2023. Bei mir werden viel mehr Readings angezeigt, u.a. Verbrauch. Ich habe das model-Attribut auf shellyplus1pm gesetzt.
Danke, das half auf Anhieb!
Gruß aus Oberfranken
matt
Zitat von: Starkstrombastler am 22 Oktober 2023, 12:44:32Zitat von: matt_577 am 22 Oktober 2023, 12:36:55Unter attributes, hab ich model shellyplug eingestellt.
In der Testversion des Moduls wird versucht, das model automatisch zu ermitteln. Lösche hierzu das Attribut model und setze get <device> model
Hi,
auch das hat wunderbar funktioniert!
Danke und
Gruß aus Oberfranken
matt
Ab dem 27.10. wird das Shelly-Modul via regulärem Update verfügbar sein.
Mega update, vielen Dank Starkstrombastler!
Viele neue Funktionen und Readings für meinen shellyplusplugs. 8)
Würde damit auch der Passwortschutz der '2nd Gen PLUS devices' funktionieren? Da wird ja nur ein Passwort gesetzt, ohne Benutzernamen.
Aktuell scheint die Firmware aber kaputt zu sein... hatte mich fast ausgesperrt. :o
https://www.shelly-support.eu/forum/thread/21937-password-protected-device-funktioniert-nicht-richtig/
Gruß,
Thomas
Leider musste ich feststellen, dass bei mir seit gestern abend viele Funktionen unserer Rolladensteuerung (Auf/Ab via IT-Funkfernbedienungen, diverse Zeitschaltungen usw.) nicht mehr funktionierten und habe gesehen, dass das Shelly-Modul durch eine neue Version ersetzt wurde. Wir nutzen 6 Shelly-2.5-Module (1. Generation), die mit der alten Version bisher immer super funktioniert haben.
Hauptproblem ist nach meiner ersten Analye, dass der "state" nicht mehr "stopped" zurückgibt, wenn der Rolladen steht, sondern "pct-xx". Einige meiner Skripte fragen aber explizit das "stopped" ab, um Doppelbelegungen von Tasten zu ermöglichen (Auf/Stop/Ab/Stop im Wechsel).
Was ist der Grund für diese doch große Änderung (die man als "breaking change" bezeichnen könnte, was sie ja bei uns auch war)?
Eigentlich ist diese Info im state ja redundant, da es ja schon das "pct"-Reading gibt. Und es gibt, wenn ich das richtig sehe, jetzt kein Reading mehr, bei dem man direkt ablesen kann, ob der Rolladen gerade fährt oder steht. Oder?
Ich stehe jetzt vor der Möglichkeit, das alte Modul wiederherzustellen und vom Update auszuschließen (nebenbei ist das Modul doch auch um einiges größer geworden) oder meine Skripte alle umzubasteln und statt state eq "stopped" auf sowas wie substr(ReadingsVal("...","state",""), 0, 4) eq "pct-") oder so umzubauen.
Daher die Frage: wurde/wird sowas berücksichtigt und ist evtl. in Aussicht, dass diese Änderung im Verhalten des Moduls wieder rückgängig gemacht wird? Dachte ich frage mal, bevor ich jetzt mit dem Drumrumarbeiten anfange. ;-)
(Ist nicht als Kritik gemeint bzw. wenn, dann nur als Konstruktive - ich sehe schon, warum das neue Modul nötig wurde, angesichts der Vielfalt der neuen Module der 2. Generation, die vorher nicht unterstützt wurden, ich frage nur ob diese state-Änderung wirklich notwendig war/ist...).
Ist nur ne Frage. :)
Ein schönes Wochenende und viele Grüße!
Hallo x86,
in den vergangenen Monaten hatten wir in diesem Thread einige Testversionen, wo diese Änderung dargestellt wurde. Bei den an den Tests beteiligten Usern gab es dazu keine Einwände. Aber es gibt natürlich eine Erklärung.
Zitat von: x86 am 28 Oktober 2023, 12:44:12Hauptproblem ist nach meiner ersten Analye, dass der "state" nicht mehr "stopped" zurückgibt, wenn der Rolladen steht, sondern "pct-xx".
Grund für die Änderung ist die Darstellung des Zustandes mit devStateIcon siehe dazu auch diesen Beitrag (https://forum.fhem.de/index.php?msg=1281352).
Das Reading state nimmt die Zustände drive-up, drive-down und pct-xx an, wobei xx die auf 10er-Schritte gerundete Position ist. Damit ist der Unterschied zwischen Bewegung und Stillstand auch eindeutig.
Es gibt dann noch das Reading position, was die Werte opened, closed und pct-ii annimmt. ii ist hier der prozentgenaue Zwischenwert.
Außerdem das Reading pct um mit Alexa u.ä. kompatibel zu sein. pct nimmt immer prozentgenaue Werte 0...100 an.
Auch mit dem Reading Power kann zwischen Stillstand (power=0) und Bewegung unterschieden werden. Falls das attr showunits gesetzt ist, sollte dafür das Reading mit readingsNum() gelesen werden.
Die von dir beschriebene Funktion Auf/Stop/Ab/Stop entspricht dem one-button-mode (Gen.1) bzw. single-button-mode (Gen.2), welche direkt von den Shellies unterstützt werden. Ist das bei dir so in den Shellies eingestellt? Oder machst du das durch zusätzlichen Code? Beschreibe doch deinen Aufbau und Funktion etwas ausführlicher, dann wird sich sicher auch eine zweckmäßige Darstellung im Modul realisieren lassen.
Zitat von: loetmeister am 28 Oktober 2023, 11:38:58Würde damit auch der Passwortschutz der '2nd Gen PLUS devices' funktionieren? Da wird ja nur ein Passwort gesetzt, ohne Benutzernamen.
Vom Anspruch her sollte der Passwortschutz funktionieren, in dieser Form ist er aber nicht getestet.
Hi Starkstrombastler,
danke für deine schnelle und umfassende Antwort!
Zitat von: Starkstrombastler am 28 Oktober 2023, 16:54:38in den vergangenen Monaten hatten wir in diesem Thread einige Testversionen, wo diese Änderung dargestellt wurde. Bei den an den Tests beteiligten Usern gab es dazu keine Einwände. Aber es gibt natürlich eine Erklärung.
Hab ich jetzt auch gelesen, aber wenn alles läuft, schaut man halt nicht unbedingt regelmäßig in einen Support-Thread vorbei ;)
Daher traf mich die Änderung halt etwas unverhofft. Aber - alles gut!
Ich konnte es jetzt durch zwei kleine Code-Änderungen (wie im vorigen Beitrag beschrieben) lösen.
Zitat von: Starkstrombastler am 28 Oktober 2023, 16:54:38Die von dir beschriebene Funktion Auf/Stop/Ab/Stop entspricht dem one-button-mode (Gen.1) bzw. single-button-mode (Gen.2), welche direkt von den Shellies unterstützt werden. Ist das bei dir so in den Shellies eingestellt? Oder machst du das durch zusätzlichen Code? Beschreibe doch deinen Aufbau und Funktion etwas ausführlicher, dann wird sich sicher auch eine zweckmäßige Darstellung im Modul realisieren lassen.
Das, was letztlich Probleme gemacht hat, war die Funktion "Auf/Stop" bzw. "Ab/Stop", mit der ich die "ON" und "OFF" Tasten einiger IT-Funksteckdosen-Fernbedienungen belegt habe. Mit der linken Tastenreihe (die ON-Tasten) kann man die entsprechenden Rolläden AUF fahren und mit der rechten (OFF-Tasten) AB, und wenn man eine der Tasten nochmal drückt während der jeweilige Rolladen fährt, kann man ihn stoppen.
Aber wie du schon schreibst: am state lässt sich auch jetzt noch ablesen ob der Rolladen steht, nämlich wenn der state mit "pct-" beginnt. Alles wieder gut! :)
Aber noch was: bei mir läuft FHEM auf einem alten, noch übrigen, für sonst nichts mehr zu gebrauchendem aber für FHEM (macht bei uns nicht viel mehr als die Rolladensteuerung per Funk und noch ein paar andere Zeitschaltungen) noch sehr gut läuft. Aber - viel Reserve ist halt nicht, insofern bin ich immer einer der ersten, der Performanceeinbußen bei "komplexer gewordenen" Modulen zu spüren bekommt (von so Sachen wie fhempy ganz zu schweigen)...
Und so fiel mir nach dem Update jetzt auf, dass der Pi etwas mehr "zu tun" hat, das sehe ich an der CPU- und Temperaturkurve und ich habe auch den Eindruck, dass die Rolläden etwas träger auf die Tasten reagieren. Als erste Maßnahme habe ich mal die verbosity auf 2 runtergestellt, bei 3 (hatte ich bislang) loggt das neue Modul jede Minute in die Logdatei (Flash, langsame SD-Karte...), dass es in 60 Sekunden wieder was loggt. ;)
Gibt's noch irgendwas, mit dem man die Performance des neuen Moduls etwas streamlinen könnte?
Aber: es läuft alles, die Unterschiede sind kaum merklich, man sieht es halt nur im CPU-Graph, dachte nur, ich frag trotzdem mal. Eventuell hat ja noch jemand die Feststellung gemacht.
Beste Grüße und in jedem Fall nochmal tausend Dank fürs Kümmern um das Modul!! :)
Hallo x86, ich freue mich, dass es jetzt wieder bei dir läuft.
Zitat von: x86 am 29 Oktober 2023, 00:07:30Gibt's noch irgendwas, mit dem man die Performance des neuen Moduls etwas streamlinen könnte?
Das umfangreiche Loggen ist der Entwicklung geschuldet. Wenn aber keine Probleme auftauchen reicht verbose=1 aus.
Das Shelly-Modul pollt die verknüpften Devices, d.h. es werden regelmäßig Abfragen gesendet und dann die Antworten ausgewertet.
Wenn du auf dem Shelly2.5 ColoT aktivierst, kannst du auch den ShellyMonitor nutzen, z.B.:
define Monitor ShellyMonitorDamit sendet der Shelly von sich aus Statusmeldungen, die in das Device geschrieben werden. Das Polling Intervall kann dann auf einen deutlich größeren Wert gestellt werden.
Außerdem kannst du auf dem Shelly Actions ROLLER OPEN URL, ROLLER CLOSED URL und ROLLER STOP URL definieren. Damit sendet der Shelly bei entsprechender Statusänderung, z.B. nach Tasterbetätigung, von sich aus an FHEM und du bekommst eine nahezu verzögerungsfreie Aktualisierung.
http://192.168.178.107:8083/fhem?cmd=get <device-name> status
Leerzeichen sind mit %20 zu maskieren.
Auch damit können die Polling Intervalle deutlich vergrößert werden.
Vielen Dank an Starkstrombastler für das überarbeitete Modul.
Ich habe eine kleine Fehlerkorretur: Bei meinem Shelly Pro 2 wird kein reading inttemp erstellt.
Wenn man Zeile 3383-3388 (# temperature not provided by all devices) aus der vorherigen if-Abfrage (Zeile 3352: if($comp eq "roller" ...) rausnimmt, dann funktioniert es.
Ich habe einen Wunsch. Könnte man für Shelly Gen 1 noch die reading rssi, ssid mitaufnehmen? Ich habe das bei mir folgend gelöst. Nach Zeile 2581:
if($jhash->{'wifi_sta'}{'rssi'}) { readingsBulkUpdateMonitored($hash,"network_rssi",$jhash->{'wifi_sta'}{'rssi'}.$si_units{rssi}[$hash->{units}]); }
if($jhash->{'wifi_sta'}{'ssid'}) { readingsBulkUpdateMonitored($hash,"network_ssid",$jhash->{'wifi_sta'}{'ssid'});}
ZitatAb dem 27.10. wird das Shelly-Modul via regulärem Update verfügbar sein.
Ich habe vorhin mein "exclude_from_update" gelöscht und ein vollständiges FHEM-Update gezogen.
Die Shellies scheinen zu fuktionieren, aber mein Log wird seitdem mit solchen Meldungen vollgespamt:
2023.10.29 11:44:59 3: [Shelly_status] ShellyPlug05: next update in 60 seconds
2023.10.29 11:44:59 3: [Shelly_status] ShellyPlug04: next update in 60 seconds
2023.10.29 11:44:59 3: [Shelly_status] ShellyPlug01: next update in 60 seconds
2023.10.29 11:44:59 3: [Shelly_status] ShellyPlug02: next update in 60 seconds
2023.10.29 11:44:59 3: [Shelly_status] ShellyPM102: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_status] ShellyPlug08: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_status] ShellyPlug03: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_webhook] proceeding with command 'Check' for device Shellyplus2PM01
2023.10.29 11:45:01 3: [Shelly_webhook] proceeding with command 'Count' for device Shellyplus2PM01
2023.10.29 11:45:01 3: [Shelly_shelly] Shellyplus2PM01: long update in 60 seconds, Timer is Shelly_shelly
2023.10.29 11:45:01 3: [Shelly_status] ShellyDimmer01: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:45:01 3: [Shelly_webhook] proceeding with command 'Check' for device Shellyplus2PM01
2023.10.29 11:45:01 3: [Shelly_webhook] proceeding with command 'Count' for device Shellyplus2PM01
2023.10.29 11:45:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:45:58 3: [Shelly_status] ShellyPlug06: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPM101: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPlug05: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPlug01: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPlug04: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPlug02: next update in 60 seconds
2023.10.29 11:45:59 3: [Shelly_status] ShellyPM102: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_status] ShellyPlug08: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_webhook] proceeding with command 'Check' for device Shellyplus2PM01
2023.10.29 11:46:01 3: [Shelly_webhook] proceeding with command 'Count' for device Shellyplus2PM01
2023.10.29 11:46:01 3: [Shelly_shelly] Shellyplus2PM01: long update in 60 seconds, Timer is Shelly_shelly
2023.10.29 11:46:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_webhook] proceeding with command 'Check' for device Shellyplus2PM01
2023.10.29 11:46:01 3: [Shelly_webhook] proceeding with command 'Count' for device Shellyplus2PM01
2023.10.29 11:46:01 3: [Shelly_status] Shellyplus2PM01: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_status] ShellyPlug03: next update in 60 seconds
2023.10.29 11:46:01 3: [Shelly_status] ShellyDimmer01: next update in 60 seconds
Zitat von: JWRu am 29 Oktober 2023, 11:50:49Die Shellies scheinen zu fuktionieren, aber mein Log wird seitdem mit solchen Meldungen vollgespamt:
attr TYPE=Shelly verbose 2beendet das.
Alternativ könnte @Starkstrombastler diese Einträge ja in verbose 4 verschieben.
Ansonsten: Tolle Arbeit. Danke!
Hallo Starkstrombastler,
nach dem update auf die neue Version ist mir aufgefallen, das es bei den Shellyplug sehr lange dauert, bis eine Rückmeldung im device angezeigt wird.
Auch ein Erhöhen des timeout auf 60s hat keine Besserung gebracht.
Dadurch wird im Log immer angezeigt:
2023.10.29 14:14:31 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 5167.
2023.10.29 14:14:31 1: stacktrace:
2023.10.29 14:14:31 1: main::__ANON__ called by fhem.pl (5167)
2023.10.29 14:14:31 1: main::readingsBulkUpdate called by ./FHEM/36_Shelly.pm (4555)
2023.10.29 14:14:31 1: main::readingsBulkUpdateMonitored called by ./FHEM/36_Shelly.pm (2841)
2023.10.29 14:14:31 1: main::Shelly_proc1G called by ./FHEM/36_Shelly.pm (2453)
2023.10.29 14:14:31 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (2389)
2023.10.29 14:14:31 1: main::__ANON__ called by FHEM/HttpUtils.pm (755)
2023.10.29 14:14:31 1: main::__ANON__ called by fhem.pl (781)
2023.10.29 14:14:55 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 5167.
2023.10.29 14:14:55 1: stacktrace:
2023.10.29 14:14:55 1: main::__ANON__ called by fhem.pl (5167)
2023.10.29 14:14:55 1: main::readingsBulkUpdate called by ./FHEM/36_Shelly.pm (4555)
2023.10.29 14:14:55 1: main::readingsBulkUpdateMonitored called by ./FHEM/36_Shelly.pm (2841)
2023.10.29 14:14:56 1: main::Shelly_proc1G called by ./FHEM/36_Shelly.pm (2453)
2023.10.29 14:14:56 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (2389)
2023.10.29 14:14:56 1: main::__ANON__ called by FHEM/HttpUtils.pm (755)
2023.10.29 14:14:56 1: main::__ANON__ called by fhem.pl (781)
2023.10.29 14:15:19 1: PERL WARNING: Use of uninitialized value $1 in concatenation (.) or string at ./FHEM/36_Shelly.pm line 3971.
2023.10.29 14:15:19 1: stacktrace:
2023.10.29 14:15:19 1: main::__ANON__ called by ./FHEM/36_Shelly.pm (3971)
2023.10.29 14:15:19 1: main::Shelly_onoff called by ./FHEM/36_Shelly.pm (1958)
2023.10.29 14:15:19 1: main::Shelly_Set called by fhem.pl (3975)
2023.10.29 14:15:19 1: main::CallFn called by fhem.pl (1966)
2023.10.29 14:15:19 1: main::DoSet called by fhem.pl (1998)
2023.10.29 14:15:19 1: main::CommandSet called by fhem.pl (1278)
2023.10.29 14:15:19 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2859)
2023.10.29 14:15:19 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (981)
2023.10.29 14:15:19 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (609)
2023.10.29 14:15:19 1: main::FW_Read called by fhem.pl (3980)
2023.10.29 14:15:19 1: main::CallFn called by fhem.pl (784)
2023.10.29 14:15:20 1: PERL WARNING: Use of uninitialized value $1 in string ne at ./FHEM/36_Shelly.pm line 4015.
2023.10.29 14:15:20 1: stacktrace:
2023.10.29 14:15:20 1: main::__ANON__ called by ./FHEM/36_Shelly.pm (4015)
2023.10.29 14:15:20 1: main::Shelly_onoff called by ./FHEM/36_Shelly.pm (3977)
2023.10.29 14:15:20 1: main::__ANON__ called by FHEM/HttpUtils.pm (755)
2023.10.29 14:15:20 1: main::__ANON__ called by fhem.pl (781)
2023.10.29 14:15:20 1: [Shelly_onoff] returns without success for device Shelly6, cmd=http://192.168.2.235/rpc/Switch.GetStatus? but ison=off
Beim Einschalten beträgt die Verzögerung ca. 5s, beim Ausschalten > 25s.
Interval steht auf 30s.
Bin daher wieder auf die letzte Version von pah zurückgewechselt.
Damit habe ich keine signifikante Verzögerung in der Rückmeldung.
Norbert
Zitat von: Starkstrombastler am 29 Oktober 2023, 10:27:01Außerdem kannst du auf dem Shelly Actions ROLLER OPEN URL, ROLLER CLOSED URL und ROLLER STOP URL definieren. Damit sendet der Shelly bei entsprechender Statusänderung, z.B. nach Tasterbetätigung, von sich aus an FHEM und du bekommst eine nahezu verzögerungsfreie Aktualisierung.
Genauso hab ich es sogar tatsächlich von Anfang an gehabt, und bei externer Bewegung der Rollläden (via Wandtaster) updatet sich das Ganze auch sofort. Ich hab "interval" nie gesetzt, es war immer auf 60, auch wenn's nicht nötig war, aber es hat auch irgendwie nie wirklich geschadet.
Aber du hast recht, ich habe es jetzt mal auf 300 gesetzt. Der einzige Wert, der sich automatisch updated ist die inttemp der Shellys und die interessiert mich eigentlich herzlich wenig, vor allem nicht minütlich.
Somit hoffe ich mal, dass es jetzt evtl. etwas weniger CPU-Last erzeugt.
Unabhängig davon:
Zitat von: Nobbynews am 29 Oktober 2023, 11:58:38Alternativ könnte @Starkstrombastler diese Einträge ja in verbose 4 verschieben.
Ja, da wär ich auch für. ;-) Also dieser Eintrag "next update in nnn seconds", das ist ja wirklich eher was sehr debug-mäßiges, das würd ich mindestens bei 4 sehen. ;-)
Viele Grüße und einen schönen restlichen Sonntag!
Zitat von: Nobbynews am 29 Oktober 2023, 14:29:26nach dem update auf die neue Version ist mir aufgefallen, das es bei den Shellyplug sehr lange dauert, bis eine Rückmeldung im device angezeigt wird.
Hier hat sich bei der Vorbereitung auf Shellies, welche nur Gen-2-Befehle annehmen, ein Bug eingeschlichen. Das betrifft alle Shellies mit Relais! Eine neue Version wird eingestellt und ist morgen via regulärem Update verfügbar.
Zitat von: JWRu am 29 Oktober 2023, 11:50:49Die Shellies scheinen zu fuktionieren, aber mein Log wird seitdem mit solchen Meldungen vollgespamt:
Na ja, Meldungen sind ja gewollt, daher kein Spam. Sind aber auf einen höheren Level geändert.
Zitat von: DerTom71 am 29 Oktober 2023, 11:00:26Ich habe eine kleine Fehlerkorretur: Bei meinem Shelly Pro 2 wird kein reading inttemp erstellt.
Der Pro2 hat keine Leistungsmesseung, richtig? Daher habe ich die Temp-Abfrage nach dem if der Leistungsmessung verschoben.
Zitat von: DerTom71 am 29 Oktober 2023, 11:00:26Könnte man für Shelly Gen 1 noch die reading rssi, ssid mitaufnehmen?
Ist im nächsten Update auch mit drin.
Hallo Starkstrombastler,
In der Version "5.00 26.10.2023" und neuer, sind 2 Bugs drin:
Einmal in Zeile 890:
sub Refresh {
fhem("trigger WEB JS:location.reload(true)"); # try a browser refresh ??
}-> Bei mir und bei vermutlich anderen Usern gibt es keine fhemweb Instanz "WEB", die heissen bei mir anders.
Dann in Zeile 4027:
fhem("sleep 0.75");-> WARNING: sleep without additional commands is deprecated and blocks FHEM
-> Ausser Du beabsichtigst wirklich, fhem jedesmal für 0.75 Sekunden zu blockieren.
Das sleep hat mich den ganzen Abend gekosten, um herauszufinden wo das herkommt, weil ich dachte das wäre irgendwo in meiner eigenen 99_MyUtils.pm. Falls ein sleep gebraucht wird, sollte es immer eine ID also einen Namen haben, dann kannn man danach suchen. Ich habe mir aus der fhem.pl die ID ausgeben lassen, in diesem Fall war das immer so was wie WARNING: sleep .sleep_3225 ..... Gefunden habe ich es dann über die Dauer, weil bei mir in der 99_MyUtils.pm kein sleep mit 0.75 vorhanden war.
Hallo Jamo,
danke für die Recherche.
Zitat von: Jamo am 29 Oktober 2023, 23:30:43Bei mir und bei vermutlich anderen Usern gibt es keine fhemweb Instanz "WEB"
Korrekt. Muss das selbst mal probieren, zu welchen Fehler(n) das führt. Vielleicht gibt es aber einen grundsätzlich eleganteren Weg, einen Refresh einzuleiten.
Das
fhem("sleep 0.75"); ist ein Relikt aus einem (quick & dirty) Experiment, was ich versäumt hatte wieder zu entfernen. Bei anderen Usern ist das auch schon durch sehr lange Reaktionszeiten aufgefallen. Das sollte aber mit dem morgigen Update eliminiert sein.
Gruß und gute Nacht / sleep 21600
Bei der mit Update verteilten Version gibt es auch ein Problem mit dem Attribut "interval". Ich habe es bei meinem Shelly Plus 1PM auf 10 gestellt, damit ich in kurzen Zeitabständen "power"-Readings bekomme. Trotzdem wird "power" meistens nur etwa alle 7 Minuten aktualisiert. Das einzige Reading, das in deutlich kürzeren Zeitabständen aktualisiert wird (aber auch nicht durchgängig im 10-Sekunden-Rhythmus), ist "network_rssi".
Wenn das Modul noch wie das Original arbeitet, werden die Readings nur bei Änderungen aktualisiert (analog zu Attribut event-on-change).
Gruß Ralf
ZitatWenn das Modul noch wie das Original arbeitet, werden die Readings nur bei Änderungen aktualisiert (analog zu Attribut event-on-change).
Das Reading "power" ändert sich aber dauernd. Mit der letzten über diesen Thread verteilten Version hat das super geklappt - erst mit der über Update verteilten Version gibt es die Probleme.
Ok.
War selber mal drüber gestolpert, daher der Hinweis.
on-for-timer und off-for-timer sollten jetzt auch bei Gen.2-Geräten funktionieren. Kann das mal jemand mit einem Walldisplay prüfen - bei mir macht das Walldisplay Probleme (mag keine Timer).
Zitat von: JWRu am 30 Oktober 2023, 15:17:00Bei der mit Update verteilten Version gibt es auch ein Problem mit dem Attribut "interval".
Das sollte jetzt gefixt sein. Ursache waren Änderungen, damit bei einem ablaufendem Timer mit Restlaufzeit < Intervall eine Aktualisierung direkt nach dem Ablauf angestoßen wird.
Zitat von: Jamo am 29 Oktober 2023, 23:30:43Bei mir und bei vermutlich anderen Usern gibt es keine fhemweb Instanz "WEB", die heissen bei mir anders.
FHEM stellt hierfür eine Konstante zur Verfügung, also ganz einfach. Der Refresh sollte jetzt überall funktionieren.
Guten Morgen,
ich habe gerade aktualisiert.
nach dem shutdown kommt auf meinem Testsystem mit einem einzelnen schellyplug folgende Meldung im Log-File
2023.10.31 08:17:42 1: PERL WARNING: Use of uninitialized value $comp in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2479.
2023.10.31 08:17:42 1: PERL WARNING: Use of uninitialized value $comp in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2491.
Norbert
Hallo Starkstrombastler,
in der aktuellsten Version 5.03 ist in Zeile 3649 die Berechnungsfunktion der EM-Shellys für die übergebenen Werte des Smartmeter-Offstes deaktiviert.
Hab's wieder aktiviert und läuft seit einer halben Stunde Fehlerfrei.
Hardware: Shelly Pro 3EM
FW-Version: 1.0.6
Verbindung erfolgt über LAN
Danke für das überarbeitete Modul!
Schöne Grüße
Hallo Ibex,
willkommen im Forum und Danke für die Nachricht.
Zitat von: Ibex am 31 Oktober 2023, 21:37:37in der aktuellsten Version 5.03 ist in Zeile 3649 die Berechnungsfunktion der EM-Shellys für die übergebenen Werte des Smartmeter-Offstes deaktiviert.
Der Grund dafür ist, dass die Shellies nicht saldieren. D.h. wenn es durch eine PV-Anlage zu einer Einspeisung auf einer Phase kommt, dann wird diese eingespeiste Energie nicht mit den anderen Phasen verrechnet. Im Ergebnis sind die Werte des Shelly für bezogene und eingespeiste Energie zu hoch.
Im Modul versuche ich die Saldierung so gut wie möglich nachzubilden. Es werden Readings mit der Endung '_S' für die originalen Shelly-Werte und mit '_T' (für Total), das sind die saldierten Werte, berechnet.
Das setzt aber voraus, dass ein niedriges Polling-Intervall (bei mir: 3 sec) eingestellt ist. Gut sichtbar wird dies, wenn mit dem Attribut Periods mindestens eine Kumulierungsperiode ausgewählt wird.
Das ganze muss noch für die Energymeter angepasst werden, daher waren die herausgenommen. Es wird aber trotzdem immer Abweichungen gegenüber den "amtlichen" Zählern geben.
Mit dem nächsten Update wird die Berechnung wieder frei geschaltet, aber bitte die Energymeter-Readings als experimentell betrachten!
Gruß
Starkstrombastler
Hallo Starkstrombastler,
danke für deine freundliche Rückmeldung.
Da ich derzeit noch keine PV-Anlage habe, war dieses Thema für mich bis jetzt nur am Rande interessant.
Vielleicht kann ich aber ein bisschen etwas zu dem Thema beitragen.
Die Berechnungen sollten meiner Meinung nach am Gerät selbst so Hardwarenahe wie möglich erfolgen und das am besten jede Sekunde. Da die Shellys seit Version 0.9.0 über eine Script-Komponente verfügen, ist der naheliegendste Schritt dies darüber zu implementieren. Habe die Shelly-Script-Features überflogen und alle Funktionen sind hierfür gegeben. Somit entfällt das Polling von 3 Sekunden. Selbst die Einstellungen (Script-Handling) im Shelly-Gerät könnten über FHEM erfolgen und gepflegt werden.
Da ich gerne den Weg des geringsten Widerstandes gehe, habe ich mal das Shelly-Support-Forum durchforstet und siehe da, es gibt bereits eine "einfache" Lösung.
Forumslink:
https://www.shelly-support.eu/forum/thread/19204-saldierung-pro-3em-ja-nein-vielleicht/?pageNo=3
GitHub-Quelle für den "fast" fertigen Code:
https://github.com/sicanins/shelly-pro3EM-energycounter/tree/main
Shelly-Api für das Scriptehandling:
https://shelly-api-docs.shelly.cloud/gen2/Scripts/ShellyScriptLanguageFeatures
Wenn ich nun das ganze etwas weiterspinne, würde ich folgendes dazubauen:
1. Übergabe der SmartMeter-Daten [kWh] über HTTP-Post
2. Einrichten des Scripts per HTTP-Post-Daten
Die 2 Punkte hätten den Vorteil alles über FHEM pflegen zu können.
Derzeit läuft das Script bei mir mit folgenden Änderungen:
1. MQTT und die Ausgabe über den Namen habe ich deaktiviert.
2. Die periodische Abarbeitung habe ich auf 1000ms erhöht und die dahinterliegenden Berechnungen mit einer Variable angepasst.
So läuft es bei mir seit ein paar Stunden. Allerdings kann ich keine Aussage zur Saldierung im Bezug auf die Einspeisung treffen.
Schöne Grüße
Ibex
Hallo Ibex,
da stimme ich dir voll und ganz zu:
Zitat von: Ibex am 02 November 2023, 23:38:07Die Berechnungen sollten meiner Meinung nach am Gerät selbst so Hardwarenahe wie möglich erfolgen und das am besten jede Sekunde. Da die Shellys seit Version 0.9.0 über eine Script-Komponente verfügen, ist der naheliegendste Schritt dies darüber zu implementieren. Habe die Shelly-Script-Features überflogen und alle Funktionen sind hierfür gegeben. Somit entfällt das Polling von 3 Sekunden. Selbst die Einstellungen (Script-Handling) im Shelly-Gerät könnten über FHEM erfolgen und gepflegt werden.
Ich habe auch schon mit einem Script.Saldierung.json experimentiert. Allerdings ging dann die Performance des Systems zurück - das muss aber nicht unbedingt am Script gelegen haben. Ich habe das Thema dann erstmal aufgeschoben. Was mir auch nicht gefallen hat, war die Krücke mit der Rückgabe über den Namen....
In der Anlage das Script, welches ich mit /rpc/Script.GetCode gespeichert habe, für alle ShellyEM3Pro-User, die damit experimentieren möchten.
LG
Starkstrombastler
(nächste drei Tage offline)
Hallo Starkstrombastler,
ich habe hier immer mal wieder folgende Meldung im Log stehen:
2023.11.04 05:40:08 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 5167.
2023.11.04 05:40:08 1: stacktrace:
2023.11.04 05:40:08 1: main::__ANON__ called by fhem.pl (5167)
2023.11.04 05:40:08 1: main::readingsBulkUpdate called by ./FHEM/36_Shelly.pm (4628)
2023.11.04 05:40:08 1: main::readingsBulkUpdateMonitored called by ./FHEM/36_Shelly.pm (2882)
2023.11.04 05:40:08 1: main::Shelly_proc1G called by ./FHEM/36_Shelly.pm (2490)
2023.11.04 05:40:08 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (2426)
2023.11.04 05:40:08 1: main::__ANON__ called by FHEM/HttpUtils.pm (755)
2023.11.04 05:40:08 1: main::__ANON__ called by fhem.pl (781)
Norbert
Hallo zusammen,
mir wurde beim Nachkaufen ein Shelly Plus Plug S (https://www.shelly.com/de/products/shop/shelly-plus-plug-s-1) geliefert.
Schalten lässt sich das Teil, das passende reading relay_0 zeigt den Status auch korrekt an.
Als State wird kurz OK angezeigt, danach nur "error". Im Log finde ich
[Shelly_proc1G] invalid JSON data for device shelly1Die Gerätedaten könnte ich komplett zur Verfügung stellen, evtl. hilft der Anfang:
"deviceInfo": {
"name": null,
"id": "shellyplusplugs-80646fe13cd0",
"mac": "80646FE13CD0",
"slot": 0,
"key": "entfernt",
"batch": "2307-BroadwellCuco",
"fw_sbits": "04",
"model": "SNPL-00112EU",
"gen": 2,
"fw_id": "20231031-152250/1.0.7-g5db02bd",
"ver": "1.0.7",
"app": "PlusPlugS",
"auth_en": false,
"auth_domain": null
},
Lässt sich die Unterstützung für das Gerät noch einbauen?
Zitat von: pcbastler am 05 November 2023, 13:09:33Auswählen Erweitern
[Shelly_proc1G] invalid JSON data for device shelly1
Die 2ndGen Plus Geräte hat Starkstrombastler bereits integriert. Die Fehlermeldung liest sich als wäre das Modul auf der "alten" Version und/oder das Attrribut "model" noch auf ein "1st Gen Plug" gesetzt.
Zitat von: tobi01001 am 05 November 2023, 15:55:43Die Fehlermeldung liest sich als wäre das Modul auf der "alten" Version und/oder das Attrribut "model" noch auf ein "1st Gen Plug" gesetzt.
Neue Shellies werden am zuverlässigsten als neues Device angelegt, d.h.:
define <name> Shelly <ip-adr> Nach ca. 30 Sekunden können dann die Attribute gesetzt werden. Das Attribut model wird im Gegensatz zur älteren Modulversion automatisch ermittelt und sollte in diesem Fall
shellyplusplug lauten.
Alternativ sollte auch
get <name> model helfen.
Die aktuelle Modulversion 5.04 ist über reguläres Update verfügbar.
Zitat von: Nobbynews am 04 November 2023, 09:44:12ich habe hier immer mal wieder folgende Meldung im Log stehen:
Sollte mit dem morgigen Update behoben sein.
Zitat von: Starkstrombastler am 05 November 2023, 18:51:53Zitat von: tobi01001 am 05 November 2023, 15:55:43Die Fehlermeldung liest sich als wäre das Modul auf der "alten" Version und/oder das Attrribut "model" noch auf ein "1st Gen Plug" gesetzt.
Neue Shellies werden am zuverlässigsten als neues Device angelegt, d.h.: define <name> Shelly <ip-adr> Nach ca. 30 Sekunden können dann die Attribute gesetzt werden. Das Attribut model wird im Gegensatz zur älteren Modulversion automatisch ermittelt und sollte in diesem Fall shellyplusplug lauten.
Alternativ sollte auch get <name> model helfen.
Die aktuelle Modulversion 5.04 ist über reguläres Update verfügbar.
Update hat geholfen :) Vielen Dank!
Hi Starkstrombastler,
das Modul läuft bei mir auch auf dem alten Pi jetzt gut und ohne Verzögerungen oder nennenswert höhere CPU-Last. Super, danke!
Allerdings habe ich einen neuen Effekt festgestellt: das neue Modul hat ja ein neues Attribut, "ShellyName", eingeführt, das ja scheinbar den in der Shelly-GUI vergebenen Namen enthalten soll und automatisch ausgelesen wird. Jetzt habe ich leider den Effekt, dass es beim Neustart von FHEM (z.B. nach einem Update) regelmäßig passiert (aber zufällig), dass bei einem oder mehreren meiner 5 Shellys plötzlich das "ShellyName" mit dem Wert seines FHEM-Namens überschrieben wird statt des Shelly-Namens.
Abgesehen davon, dass mir der Sinn dieses Attributs nicht ganz klar ist, frage ich mich: könnte man die Logik nicht dahingehend erweitern, dass nur dann versucht wird, den ShellyName auszulesen und als Attribut zu setzen, wenn das Attribut ShellyName nicht bereits besteht?
Meine Vermutung ist nämlich, dass es hin und wieder passiert, dass einer der Shellys gerade mal für ein paar Sekunden aus dem WLAN geflogen ist (passiert bei dem am weitesten entfernten hin und wieder) und wenn das genau bei FHEM-Neustart der Fall ist, wird der ShellyName auf einmal geändert - vom richtigen "sprechenden" Shelly-Namen zum FHEM-Namen.
Nicht, dass das ein großartiger Beinbruch wäre, aber es führt dazu, dass sich die fhem.cfg bei Neustarts regelmäßig "ungewollt" ändert (ich mache regelmäßig Backups der cfg und wenn sich dabei die Dateigröße ändert, ohne dass ich selbst Änderungen vorgenommen habe, werde ich immer erstmal hellhörig.. ;).
Vielleicht könnte man eine entsprechende Logik wie oben vorgeschlagen einbauen, oder aber das ShellyName-Attribut abschaltbar machen?
Danke schonmal und viele Grüße,
Fabian
ZitatDie Berechnungen sollten meiner Meinung nach am Gerät selbst so Hardwarenahe wie möglich erfolgen und das am besten jede Sekunde. Da die Shellys seit Version 0.9.0 über eine Script-Komponente verfügen, ist der naheliegendste Schritt dies darüber zu implementieren. Habe die Shelly-Script-Features überflogen und alle Funktionen sind hierfür gegeben. Somit entfällt das Polling von 3 Sekunden. Selbst die Einstellungen (Script-Handling) im Shelly-Gerät könnten über FHEM erfolgen und gepflegt werden.
Das ist, pardon, ziemlicher Unsinn (und da ich seit 16 Jahren eine PV-Anlage betreibe, weiß ich hoffentlich, was ich sage).
Erstens hat inzwischen jeder einigermaßen brauchbare Wechselrichter eine Möglichkeit zur Abfrage diverser Daten. Das ist heute sogar viel besser gelöst, als noch bei meinem alten NT5000 - für den musste ich ein eigenes FHEM-Modul schreiben, siehe contrib-Ordner. Und bevor ich FHEM kannte, habe ich das sogar über einen Mikro-Webserver abgefragt.
Zweitens ist die Energiemessung in den meisten Shelly-Devices, vorsichtig gesagt, ziemlich ungenau (wenn es sich nicht um ein dezidiertes Modul zum Messen der Wirkleistung handelt...). Damit auch noch Berechnungen irgendeiner Art zu machen, ist nicht sehr erfolgversprechend.
Drittens: Was um Himmels Willen sollte man mit einer Energiemessung im Sekundentakt anfangen? Für so etwas interessiert sich kein rational denkender Mensch. Gerade bei PV-Anlagen kann es zu sehr kurzfristigen Schwankungen der erzeugten Leistung kommen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 07 November 2023, 15:45:28Was um Himmels Willen sollte man mit einer Energiemessung im Sekundentakt anfangen?
Wir reden hier über den ShellyPro3EM Dreiphasen-Leistungs- und Energiezähler im Einsatz als "SmartMeter" in der Zuleitung hinter dem Zähler des Netzbetreibers.
Der ShellyPro3EM verfügt leider über keine phasenübergreifende Saldierung. Solange das nicht in der Firmware vorhanden ist, kann man versuchen das mittels Fhem oder (besser) mittels Script zu realisieren. Dazu muss die bezogene und eingespeiste Leistung in kurzen Intervallen vom Shelly über alle drei Phasen hinweg integriert werden. Im Ergebnis erhält man getrennte Werte für die bezogene und die eingespeiste Energie, was dann (hoffentlich) einigermaßen mit dem "amtlichen" Zähler übereinstimmt. Der Shelly stellt keine derartigen Werte zur Verfügung und die schlichte Addition der Werte der einzelnen Phasen führt zu abweichenden Werten, wenn gleichzeitig eingespeist und auf einer anderen Phase bezogen wird.
Hallo Starkstrombastler,
in der aktuellen Version des Moduls hast Du in Zeile 4662 ein Logging mit verbose 3 hinterlegt, dass mir sekündlich das Log ergänzt. Ich halte das für echt übertrieben. Aus meiner Sicht gehört hier ein Verbose 5 oder mindesten 3 hin.
Grüße Jörg
Log3 $hash->{NAME},3,"$reading: maxAge=$MaxAge ReadingsAge="
.ReadingsAge($hash->{NAME},$reading,0)." new value=$value vs old="
.ReadingsVal($hash->{NAME},$reading,"")
#.($changed?":: $changed":" ::-0-")
;
Zitat von: JoWiemann am 08 November 2023, 08:34:18hier ein Verbose 5 oder mindesten 3 hin.
Wohl eher 5 oder 4.
Denn 3 ist es ja schon 8)
Zitat von: betateilchen am 08 November 2023, 08:48:25Zitat von: JoWiemann am 08 November 2023, 08:34:18hier ein Verbose 5 oder mindesten 3 hin.
Wohl eher 5 oder 4.
Denn 3 ist es ja schon 8)
Krumme Finger. Gemeint war 4.
Grüße Jörg
moin zusammen,
bin gestern erst auf das Modul 36_Shelly.pm gestoßen, weil meine neuen ShellyPlusPlugS mangels template nicht mehr (so richtig) mit MQTT funktionieren.
Ich frag mich jetzt ob ich meine 6 Stück Shelly1, Shelly1L, ShellyPlugS nicht auch von MQTT auf 36_Shelly.pm umstellen soll oder doch für die neuen MQTT templates entwickeln/suchen soll (gibt ja einen entspr. thread).
Die Frage gehört hier nicht her, aber vlt. könnt ihr mir doch paar Anregungen Pro und Contra geben.
Danke, Dieter
Grundsätzlich binde ich alle meine Shelly nur per mqtt ein.
Da muss man nicht auf die Umsetzung und Anpassung in einem speziellen Modul warten, denn mqtt kann man jederzeit als Anwender auch selbst und ohne bereitgestelltes template so einrichten, wie man es gerne hätte. (Ich habe noch nie irgendein template verwendet, das ist mir viel zu suspekt.)
Moin,
kann es sein, daß die neue Version irgendwo in Sachen set- oder toggle-Steuerung umgestrickt wurde? Seit dem letzten Update Anfang Nov. (vorher hatte ich die 36_shelly.pm vom Update ausgenommen) kann ich Shellys nur noch über die WebUI von fhem schalten, jedoch nicht mehr über FUIP (s.a. in diesem Thread (https://forum.fhem.de/index.php?topic=135709.0))
Bekomme statt dessen nur
2023.11.10 10:51:11.661 1: [Shelly_Set] Error: wrong channel 'on' for device ShellyPlugS_Buero_3dPrinter, must be <integer>
2023.11.10 10:51:13.360 1: [Shelly_Set] Error: wrong channel 'off' for device ShellyPlugS_Buero_3dPrinter, must be <integer>
wenn ich mittels FIUP zu schalten versuche ...
Gruß, Christoph
Zitat von: caldir65 am 10 November 2023, 10:59:41kann es sein, daß die neue Version irgendwo in Sachen set- oder toggle-Steuerung umgestrickt wurde?
Ja, das stimmt.
Welchen Befehl sendet denn FUIP?
Bitte den Schaltvorgang mit verbose=5 loggen und hier posten.
Hallo grappa24,
Zitat von: grappa24 am 08 November 2023, 09:48:35Ich frag mich jetzt ob ich meine 6 Stück Shelly1, Shelly1L, ShellyPlugS nicht auch von MQTT auf 36_Shelly.pm umstellen soll oder doch für die neuen MQTT templates entwickeln/suchen soll (gibt ja einen entspr. thread).
So ähnlich haben bisher nur Einsteiger gefragt, ohne MQTT Erfahrung. Für diese sollte sich das Shelly-Modul zunächst als die einfachere Variante darstellen.
Ansonsten könntest du es einfach mal auf einen Versuch ankommen lassen und das Shelly-Modul ausprobieren. Mir ist nicht bekannt, dass das nicht parallel zu MQTT gehen sollte.
Hallo x86,
Zitat von: x86 am 06 November 2023, 16:58:12Allerdings habe ich einen neuen Effekt festgestellt: das neue Modul hat ja ein neues Attribut, "ShellyName", eingeführt, das ja scheinbar den in der Shelly-GUI vergebenen Namen enthalten soll und automatisch ausgelesen wird. Jetzt habe ich leider den Effekt, dass es beim Neustart von FHEM (z.B. nach einem Update) regelmäßig passiert (aber zufällig), dass bei einem oder mehreren meiner 5 Shellys plötzlich das "ShellyName" mit dem Wert seines FHEM-Namens überschrieben wird statt des Shelly-Namens.
Es ist wahrscheinlich ausreichend, den im Shelly eingetragenen Namen als Reading anzuzeigen. Das werde ich in einer der nächsten Versionen vereinfachen.
Zitat von: Starkstrombastler am 10 November 2023, 13:10:16Zitat von: caldir65 am 10 November 2023, 10:59:41kann es sein, daß die neue Version irgendwo in Sachen set- oder toggle-Steuerung umgestrickt wurde?
Ja, das stimmt.
Welchen Befehl sendet denn FUIP?
Bitte den Schaltvorgang mit verbose=5 loggen und hier posten.
Moin,
das Problem kommt jedenfalls aus den Änderungen - mit der letzten Version von PAH vom April funktioniert es ... Ich habe einmal versucht, ein umfangreicheres Log zu erhalten, aber hisher habe ich nur dies alles erhalten:
Fhem-Log mit Verbose 5 für diesen Shelly
2023.11.11 16:17:07.537 5: [Shelly_Set] calling for device ShellyPlugS_Buero_3dPrinter with command ? (without value)
2023.11.11 16:17:07.541 5: [Shelly_Set] calling for device ShellyPlugS_Buero_3dPrinter with command ? (without value)
2023.11.11 16:17:07.733 5: [Shelly_Set] calling for device ShellyPlugS_Buero_3dPrinter with command ? (without value)
2023.11.11 16:17:07.734 5: [Shelly_Set] calling for device ShellyPlugS_Buero_3dPrinter with command ? (without value)
2023.11.11 16:17:07.735 5: [Shelly_Get] ShellyPlugS_Buero_3dPrinter: unknown argument ?, choose one of config model:noArg registers:noArg shelly_status:noArg status:noArg version:noArg
2023.11.11 16:17:07.983 5: [Shelly_Set] calling for device ShellyPlugS_Buero_3dPrinter with command ? (without value)
2023.11.11 16:17:07.987 5: [Shelly_Set] calling for device ShellyPlugS_Buero_3dPrinter with command ? (without value)Erwartet das Modul evtl. immer auch einen Kanal als Angabe? Also in der Art
set ShellyPlugS_Buero_3dPrinter on 0Gruß, Christoph
Zitat von: caldir65 am 11 November 2023, 16:36:45das Problem kommt jedenfalls aus den Änderungen - mit der letzten Version von PAH vom April funktioniert es
seit der von dir genannten Version hat sich zwar sehr viel im Modul getan, aber die Funktion
set ... on ist unverändert.
Zitat von: caldir65 am 11 November 2023, 16:36:45Erwartet das Modul evtl. immer auch einen Kanal als Angabe?
Die Kanalangabe ist nur bei mehrkanaligen Geräten erforderlich, sofer
defchannel nicht gesetzt ist.
Beim ShellyPlugS ist die Kanalangabe nicht erforderlich, schadet aber auch nicht.
Bitte wie folgt vorgehen:
Aktualisiere auf die letzte Modul-Version (vom 12.11.)
Probiere mal aus die Device-Definition zu erneuern (mittels DEF).
Lässt sich der Shelly über die FHEM Deviceansicht steuern?
Und über die FHEM-Command-Zeile?
Und FIUP?
Poste die Devicedaten mittels
Copy for forum.fhem.deLöse eine Schaltung aus und logge dies mit verbose=4. In der Log-Zeile "[Shelly_Set] calling for device ..." wird der übergebene Befehl und die Parameter ausgegeben.
Zitat von: Starkstrombastler am 10 November 2023, 13:21:48So ähnlich haben bisher nur Einsteiger gefragt, ohne MQTT Erfahrung.
na ja, ist jetzt mein 10. Shelly, den ich per MQTT einbinde, nur dass es der erste GEN2 war; das ShellyPlus_1pm Template funktioniert beim PlusPlugS.
Und ja, das Shelly-Modul läuft bei mir auch.
Zitat von: Starkstrombastler am 12 November 2023, 00:42:09Zitat von: caldir65 am 11 November 2023, 16:36:45das Problem kommt jedenfalls aus den Änderungen - mit der letzten Version von PAH vom April funktioniert es
seit der von dir genannten Version hat sich zwar sehr viel im Modul getan, aber die Funktion set ... on ist unverändert.
Zitat von: caldir65 am 11 November 2023, 16:36:45Erwartet das Modul evtl. immer auch einen Kanal als Angabe?
Die Kanalangabe ist nur bei mehrkanaligen Geräten erforderlich, sofer defchannel nicht gesetzt ist.
Beim ShellyPlugS ist die Kanalangabe nicht erforderlich, schadet aber auch nicht.
Bitte wie folgt vorgehen:
Aktualisiere auf die letzte Modul-Version (vom 12.11.)
Probiere mal aus die Device-Definition zu erneuern (mittels DEF).
Lässt sich der Shelly über die FHEM Deviceansicht steuern?
Und über die FHEM-Command-Zeile?
Und FIUP?
Poste die Devicedaten mittels Copy for forum.fhem.de
Löse eine Schaltung aus und logge dies mit verbose=4. In der Log-Zeile "[Shelly_Set] calling for device ..." wird der übergebene Befehl und die Parameter ausgegeben.
Moin,
Modul ist via Update aktualisiert
Hier einmal die Definition:
define ShellyPlugS_Wohnzimmer_Sonos Shelly 192.168.1.170
attr ShellyPlugS_Wohnzimmer_Sonos DbLogExclude .*
attr ShellyPlugS_Wohnzimmer_Sonos ShellyName ShellyPlugS_Wohnzimmer_Sonos
attr ShellyPlugS_Wohnzimmer_Sonos alias ShellyPlugS Sonos Wohnzimmer
attr ShellyPlugS_Wohnzimmer_Sonos comment Zusammen mit der Logik "RebootSonosWZ_Doif" wird auch NDR2 gestartet"
attr ShellyPlugS_Wohnzimmer_Sonos event-on-change-reading state
attr ShellyPlugS_Wohnzimmer_Sonos icon sonos_play1
attr ShellyPlugS_Wohnzimmer_Sonos interval 43200
attr ShellyPlugS_Wohnzimmer_Sonos model shellyplug
attr ShellyPlugS_Wohnzimmer_Sonos room Wohnzimmer
attr ShellyPlugS_Wohnzimmer_Sonos shellyuser christoph
# DEF 192.168.1.170
# FUUID 62f11926-f33f-378b-3ef0-09bd20659b31289d
# FVERSION 36_Shelly.pm:v5.7.0-s28150/2023-11-11
# INTERVAL 43200
# NAME ShellyPlugS_Wohnzimmer_Sonos
# NR 971
# SHELLY SHPLG-S
# SHELLYID B86885
# STATE off
# TCPIP 192.168.1.170
# TYPE Shelly
# eventCount 11
# units 0
# READINGS:
# 2020-03-13 17:59:07 cloud disabled
# 2023-11-11 16:11:39 coiot enabled
# 2023-11-11 16:11:39 coiot_period 15 sec
# 2023-11-12 18:28:13 energy 855.7
# 2023-09-14 15:22:07 firmware v1.13.0(update needed to v1.14.0)
# 2023-11-12 20:22:45 inttemp 31.77
# 2023-11-11 15:56:24 network <html>connected to <a href="http://192.168.1.170">192.168.1.170</a></html>
# 2023-11-09 10:29:27 network_disconnects 2
# 2023-11-12 20:28:06 network_rssi -33
# 2023-11-12 17:05:21 network_ssid Caldir.MacAran.2023
# 2023-11-11 16:11:39 network_threshold -70
# 2023-11-12 17:05:20 overpower 0
# 2023-11-12 20:28:44 power 0
# 2023-11-12 20:28:44 relay off
# 2023-11-12 17:05:20 source http
# 2023-11-12 20:28:44 state off
# 2023-11-12 20:28:44 timer 0
# helper:
# a_Active_Power 0
# b_Active_Power 0
# c_Active_Power 0
# power 0
# powerCnt 1
#
setstate ShellyPlugS_Wohnzimmer_Sonos off
setstate ShellyPlugS_Wohnzimmer_Sonos 2020-03-13 17:59:07 cloud disabled
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-11 16:11:39 coiot enabled
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-11 16:11:39 coiot_period 15 sec
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 18:28:13 energy 855.7
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-09-14 15:22:07 firmware v1.13.0(update needed to v1.14.0)
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 20:22:45 inttemp 31.77
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-11 15:56:24 network <html>connected to <a href="http://192.168.1.170">192.168.1.170</a></html>
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-09 10:29:27 network_disconnects 2
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 20:28:06 network_rssi -33
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 17:05:21 network_ssid Caldir.MacAran.2023
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-11 16:11:39 network_threshold -70
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 17:05:20 overpower 0
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 20:28:44 power 0
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 20:28:44 relay off
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 17:05:20 source http
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 20:28:44 state off
setstate ShellyPlugS_Wohnzimmer_Sonos 2023-11-12 20:28:44 timer 0
Aus der Fhem-Oberfläche läßt sich das Device einwandfrei steuern, sowohl per Maus als auch per fhem-cmd-line. Nur FUIP mag nicht, auch nicht mit einem testweise neu definierten Device oder "devchannel 0"
36_Shelly.pm 28150 2023-11-11 23:38:09Z Starkstrombastler
Guten Morgen,
ich habe am Wochende mal wieder fhem aktualisiert.
Es sind immer mal wieder solche Warnungen im Log.
2023.11.13 04:55:04 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 5169.
2023.11.13 04:55:04 1: stacktrace:
2023.11.13 04:55:04 1: main::__ANON__ called by fhem.pl (5169)
2023.11.13 04:55:04 1: main::readingsBulkUpdate called by ./FHEM/36_Shelly.pm (4700)
2023.11.13 04:55:04 1: main::readingsBulkUpdateMonitored called by ./FHEM/36_Shelly.pm (2903)
2023.11.13 04:55:04 1: main::Shelly_proc1G called by ./FHEM/36_Shelly.pm (2501)
2023.11.13 04:55:04 1: main::Shelly_status called by ./FHEM/36_Shelly.pm (2436)
2023.11.13 04:55:04 1: main::__ANON__ called by FHEM/HttpUtils.pm (755)
2023.11.13 04:55:04 1: main::__ANON__ called by fhem.pl (781)
Modulversion ist:
FVERSION 36_Shelly.pm:v5.7.0-s28150/2023-11-11
Guten Morgen,
mit der Überarbeitung des Moduls wurde
attr <device> maxAgeeingeführt.
Welche Readings sind davon betroffen?
Ich werte z.b. die readings power und relay aus, um mir Mitteilungen über z.B. die fertige Waschemaschine zu generieren.
Die Wiederholungen konnte ich bisher zuverlässig über event-on-change verhindern.
Das Attribut haut aber dazwischen.
Kann man das selektiv auf readings eingrenzen? Ich habe nichts dazu gefunden.
Oder müsste man einfach setzen
attr <device> maxAge 864000und hätte dann 10 Tage Ruhe?
Norbert
Moin,
anscheinend ist auch mindestens ein anderes Modul bzw. die Interoperation betroffen - ich habe die FM
2023.11.13 07:27:36.868 3: Home: error: Error: wrong channel '{Log' for device ShellyPlugS_FlurOG_LampeTreppe, must be <integer>im Zusammenhang mit Homemode gefunden. Der fragliche Shelly funktioniert aber via cli oder Weboberfläche ohne Probleme. In FUIP ist er nicht eingebunden.
Gruß, Christoph
Hallo zusammen,
aktuell verwende ich für meine Rolladensteuerung Homematic-Aktoren. Da diese immer wieder mal ausfallen und ich auch nicht weiß, ob HomeMatic Classic noch lange unterstützt wird, möchte ich zukünftig Shelly-Aktoren verwenden, konkret den ShellyPlus2PM. Ich habe schon mal den Shelly 2.5 getestet, das hat soweit ganz gut geklappt, aber ich möchte eigentlich den ShellyPlus2PM nutzen.
Leider kann ich diesen Aktor aber nicht als model in der GUI setzen, da gibt es zwar diverse andere, aber den ShellyPlus2PM halt nicht. Den Shelly 2.5 gibt es zwar, aber ich möchte ja den Nachfolger nutzen.
Ein Blick in die 36_Shelly.pm offenbart aber doch einige Stellen, an denen dieses Modell explizit erwähnt wird.
Mache ich da was falsch? Oder kann ich ein anderes Modell auswählen?
Vielen Dank für eure Hilfe,
Rudi
Hallo
Starkstrombastle rhatte im anderen Beitrag nach der aktualität deines Moduls gefragt.
Aktuell sehe ich in der Liste der Modelle auch ==> "model shellyplus2pm". Beim Einbinden wird normalerweise das Modell automatishc erkannt.
Die Version ist aktuell: 36_Shelly.pm 28150 2023-11-11
Gruß Ralf
Sorry, hatte ich vergessen;-(
Ich habe heute FHEM aktualisiert, da ist alles ganz neu. Das Modul ist vom 11.11.2023.
Komisch - nach einem Neustart (shutdown restart) werden mir jetzt auch neue Modelle angezeigt, darunter auch das ShellyPlus2pm.
Vielen Dank fürs Nachfragen - keine Ahnung, warum es jetzt vorhanden ist, aber vorher (unmittelbar nach dem Update von FHEM) war es noch nicht da...
Rudi
Hallo,
noch mal eine Nachfrage zum Passwortschutz von gen2 Geräten. Wenn ich die Änderungshistorie richtig verfolgt habe, ist im Shelly Modul jetzt "admin" für gen2 als user voreingestellt? (https://svn.fhem.de/trac/changeset?reponame=&old=28142%40trunk%2Ffhem&new=28142%40trunk%2Ffhem#:~:text=if(!%24user)%7B-,1727,-my%20%24user%20%3D%20AttrVal)
Das hat bei meinem Plus PlugS (SNPL-00112EU) keine Veränderung gebracht. Mit Passwort kommt immer Timeout.
Wenn ich die Doku richtig verstehe, dann ist von HTTP Basic auth auf digest umgestellt worden (https://shelly-api-docs.shelly.cloud/gen2/General/Authentication/)
Ich schätze mal das würde noch weitere Anpassungen am Shelly Modul erfordern?
Gruß,
Thomas
Zitat von: Starkstrombastler am 10 November 2023, 16:44:43Es ist wahrscheinlich ausreichend, den im Shelly eingetragenen Namen als Reading anzuzeigen. Das werde ich in einer der nächsten Versionen vereinfachen.
Als Reading klingt gut. Wer es braucht, kann es dann auslesen, wer nicht, ignoriert es, aber es landet dann nicht automatisch immer in der fhem.cfg.
Auch für das Reading würde ich aber empfehlen, es nur dann zu aktualisieren, wenn es wirklich eine Antwort vom Shelly gegeben hat und, falls nicht (Shelly kurzzeitig nicht erreichbar...) es nur dann auf den "FHEM-Namen" zu setzen, wenn das Reading vorher noch NIE gelesen wurde bzw. nicht existiert. :)
Viele Grüße!
EDIT: Gerade gesehen, dass du es mit dem letzten Update umgesetzt hast. Sieht gut aus! Danke :)
Mahlzeit.
Hat von Euch jemand einen Plus1PM inkl Addon in Betrieb?
Ich habe einen neu hier, funzt soweit auch, allerdings sehe ich im FHEM die Temperaturen am Addon nicht.
Ich habe zwei Sensoren angeschlossen, im Shelly sehe ich sie auch mit Werten.
vb
Hallo VB90,
ich glaube, bisher hat noch keiner danach gefragt:
Zitat von: VB90 am 18 November 2023, 14:39:16Hat von Euch jemand einen Plus1PM inkl Addon in Betrieb?
Die gute Nachricht ist: ich habe hier einen PLUS-Addon auf dem Schreibtisch liegen - der wartet auch schon darauf integriert zu werden.
Also bitte noch etwas Geduld.
Na das gefällt mir doch, ich warte gern und wenn du Unterstützung bei testen brauchst, melde dich einfach.
Schonmal vorab, wenns erlaubt ist:
Per MQTT werden die Daten verschickt, ist aber nicht mein Anwendungsszenario.
Allgemein zum AddOn, ist weniger ein FHEM-Problem.
Die angezeigten Temperaturen sind um >10° zu hoch. klar könnte man da mit einem OffSet dagegen halten, ist aber in der Größenordnung nicht Sinn der Sache.
Zwei angeschlossene Sensoren liegen um ca 2° auseinander. Normalerweise ist die Abweichung untereinander deutlich geringer im Bereich von 0.x°
vb
edit:
manchmal stellt man sich selbst die Beine.
Ich hatte die ersten beiden Sensoren direkt an das AddOn geklemmt, also sehr nah dran.
Die Temperatur der Shelly-AddOn-Kombi ist überraschend hoch und führt um Umfeld zu Wärme.
Ein weiterer Sensor ca 15cm weg misst nun realistische Werte.
Hallo zusammen,
Ich verwende einen Shelly Dimmer 2 in meiner Küche.
Bisher habe ich den Helligkeitswert pct per notify abhängig von der Helligkeit draußen setzen lassen (1 Wert für Tagsüber und 1 Wert für Nachts).
Seit dem letzten Update des Shelly Moduls in FHEM gestern Abend wird nun die Lampe beim Setzen des pct Wertes angeschaltet.
Das war vor dem Update noch nicht so.
Gibt es hierfür eine Lösung bzw. Ein Attribut welches ich in FHEM zusätzlich setzen muss?
Beim Lesen der letzten Einträge habe ich bisher nichts hierzu finden können.
Viele Grüße
Fabes
Hallo Fabes,
willkommen im Forum!
Zitat von: Fabes am 18 November 2023, 17:42:17Gibt es hierfür eine Lösung bzw. Ein Attribut welches ich in FHEM zusätzlich setzen muss?
Die Änderung kam in einer der vorhergehenden Testversionen - da hatte sich keiner der Tester daran gestört.
Im Moment ist nichts hierzu vorgesehen, denkbar ist aber ein z.B. ein
set ... preset <%-Wert>, um den pct-Wert zu ändern ohne dabei einzuschalten oder ein Attribut, um die Funktion von
set ... pct zu steuern. Kennt jemand ein geeignetes Vorbild hierzu?
Moin,
gestern kam beim Update hier auch eine neue Shelly.pm-Version mit im fhem an, laut Shelly-Seite eines der betroffenen Devices
36_Shelly.pm:v5.8.0-s28177/2023-11-16
Wenn ich jetzt über das Tablet schalte, bekomme ich
2023.11.19 12:14:32.619 4: [Shelly_Set] calling for device ShellyPlugS_Buero_3dPrinter with command 'toggle' and 1 parameters: on
2023.11.19 12:14:32.620 1: [Shelly_Set] Error: wrong channel 'on' for device ShellyPlugS_Buero_3dPrinter, must be <integer>
2023.11.19 12:14:34.466 4: [Shelly_Set] calling for device ShellyPlugS_Buero_3dPrinter with command 'toggle' and 1 parameters: off
2023.11.19 12:14:34.466 1: [Shelly_Set] Error: wrong channel 'off' for device ShellyPlugS_Buero_3dPrinter, must be <integer>im Log angezeigt.
Gruß, Christoph
Hallo caldir65,
die Logzeile hab ich so eingebaut, um dem Problem mit FUIP auf die Schliche zu kommen. Die Meldung
Zitat von: caldir65 am 19 November 2023, 12:26:57calling for device ShellyPlugS_Buero_3dPrinter with command 'toggle' and 1 parameters: on
bedeutet, dass dein FUIP Befehle
set <device> toggle on bzw.
off sendet, was an sich ein Widerspruch ist: mit '
toggle' wird normalerweise zwischen zwei Zuständen umgeschaltet. Das müsste also in FUIP angepasst werden.
Zitat von: Fabes am 18 November 2023, 17:42:17Bisher habe ich den Helligkeitswert pct per notify abhängig von der Helligkeit draußen setzen lassen
Mit der nächsten Aktualisierung funktioniert das wieder wie früher:
- mit set <device> pct <value> wird der Helligkeitswert im Shelly gesetzt, ohne ein oder aus zu schalten.
Helligkeitswert 0 (Null) ist nicht zulässig. - mit set <device> dim <value> wird der Helligkeitswert im Shelly gesetzt und eingeschaltet.
Ist der Helligkeitswert gleich 0 wird ausgeschaltet und der gespeicherte Wert bleibt erhalten.
Ich habe schon vor längerer Zeit die Shelly 2.5 als Rollladenaktoren wieder durch gute alte HomeMatic-Devices ersetzt. Hintergrund ist die relativ hohe Innentemperatur der 2.5er von ca. 60 °C. Das war mir, im wahrsten Sinne des Wortes, zu heiß für den Einbau mehrerer Aktoren in einer Wand.
Ich will gar nicht unterstellen, dass dies bei den Nachfolgemodellen immer noch so ist. Diese Falle sollte man aber prüfen, bevor man hineintritt.
LG
pah
Ja, das ist (hier) immer noch so. Deswegen ist es bei mir bei zwei 2.5ern geblieben. Aktuelle Aktoren der Wahl sind hier jetzt, wenn Homematic ersetzt werden muss, daher solche mit Zigbee.
Zitat von: Starkstrombastler am 20 November 2023, 00:04:32Mit der nächsten Aktualisierung funktioniert das wieder wie früher:
- mit set <device> pct <value> wird der Helligkeitswert im Shelly gesetzt, ohne ein oder aus zu schalten.
Helligkeitswert 0 (Null) ist nicht zulässig. - mit set <device> dim <value> wird der Helligkeitswert im Shelly gesetzt und eingeschaltet.
Ist der Helligkeitswert gleich 0 wird ausgeschaltet und der gespeicherte Wert bleibt erhalten.
Super, vielen Dank für den Hinweis und die zusätzliche Erklärung.
Wird gleich noch getestet und mein bisher ungetesteter Workaround im notify kann dann entfallen.
VG
Fabes
Shellydimmer:Mit dem nächsten Update gibt es außerdem:
- mit set <device> dimup [<value>] wird der Helligkeitswert im Shelly um den Wert value erhöht.
Wird kein Wert angegeben, wird das Attribut dimstep ausgewertet. Ist das Device aus, wird eingeschaltet - mit set <device> dimdown [<value>] wird der Helligkeitswert im Shelly um den Wert value verringert.
Kleinster möglicher Wert ist "minimum brightness" (s. Shelly settings)
Addon:Zitat von: VB90 am 18 November 2023, 14:39:16Hat von Euch jemand einen Plus1PM inkl Addon in Betrieb?
Die Temperatursensoren am Addon werden jetzt im Shelly-Device dargestellt.
Zitat von: Starkstrombastler am 19 November 2023, 13:52:52die Logzeile hab ich so eingebaut, um dem Problem mit FUIP auf die Schliche zu kommen.
Das Problem konnte gelöst werden - im FUIP-SimpleSwitch habe ich einfach das "toggle" entfernt (Feld ist jetzt leer), und offensichtlich funktioniert es so jetzt.
Gruß, Christoph
Zitat von: Starkstrombastler am 20 November 2023, 22:23:31Addon:
Zitat von: VB90 am 18 November 2023, 14:39:16Hat von Euch jemand einen Plus1PM inkl Addon in Betrieb?
Die Temperatursensoren am Addon werden jetzt im Shelly-Device dargestellt.
Besten Dank!!
Zitat von: Prof. Dr. Peter Henning am 20 November 2023, 16:29:55Ich habe schon vor längerer Zeit die Shelly 2.5 als Rollladenaktoren wieder durch gute alte HomeMatic-Devices ersetzt. Hintergrund ist die relativ hohe Innentemperatur der 2.5er von ca. 60 °C. Das war mir, im wahrsten Sinne des Wortes, zu heiß für den Einbau mehrerer Aktoren in einer Wand.
Ich will gar nicht unterstellen, dass dies bei den Nachfolgemodellen immer noch so ist. Diese Falle sollte man aber prüfen, bevor man hineintritt.
LG
pah
Der Nachfolger von Shelly ist das Modell "Shelly Plus 2PM", oder?
Gibt es eventuell schon Erfahrungswerte über dessen übliche Betriebstemperaturen?
edit:
siehe hier, keine Besserung erwartbar
https://www.shelly-support.eu/forum/thread/17411-shelly-plus-2pm-teardown-stromaufnahme/?postID=179958#post179958
Moin,
Ich habe seit einiger Zeit jetzt das Problem, daß nach einem Neustart von fhem ein paar meiner 40 Shellys im Status "initialized", vereinzelt auch "Networks error" stehen. Damit alle Routinen, die darauf zugreifen, auch wieder funktionieren, muss ich bei diesen Geräten einmalig eine Statusabfrage machen, dann funktioniert alles wieder wunschgemäß.
Gruß
Christoph
Nachtrag: Ich habe heute noch einmal das Log durchforstet - hier einmal alle Meldungen mit Bezug auf Shelly für den Zeitraum des fhem-Starts :
2023.11.25 17:58:28.320 1: PERL WARNING: Subroutine ShellyReboot_ParseHttpResponse redefined at ./FHEM/99_MyUtils.pm line 498, <$fh> line 17.
2023.11.25 17:59:24.024 5: [Shelly_get_model] try to get model for device ShellyPlugS_Buero_3dPrinter as first gen
2023.11.25 17:59:24.024 5: [Shelly_get_model] try to get model for device ShellyPlugS_Buero_3dPrinter as second gen
2023.11.25 17:59:24.186 4: [Shelly_status(1G)] issue a non-blocking call to http://christoph:Qwer123tz!192.168.1.46@192.168.1.172/status
2023.11.25 17:59:24.365 4: [Shelly_shelly] ShellyPlugS_Buero_3dPrinter is a first Gen device
2023.11.25 17:59:24.366 4: [Shelly_shelly] issue a non-blocking call to http://christoph:Qwer123tz!192.168.1.46@192.168.1.172/settings
2023.11.25 17:59:24.366 4: [Shelly_shelly] ShellyPlugS_Buero_3dPrinter: long update in 172800 seconds, Timer is Shelly_shelly
2023.11.25 17:59:28.717 1: Assigning device ShellyPlugS_Waeschezimmer_TV SHELLYID 040B71
2023.11.25 17:59:28.929 1: [Shelly_status] Device shellyFlood_HWR has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2023.11.25 17:59:28.932 1: [Shelly_status] Device shellyFlood_Kueche has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2023.11.25 17:59:28.934 1: [Shelly_status] Device shellyFlood_HWR has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2023.11.25 17:59:28.935 1: [Shelly_status] Device shellyFlood_Kueche has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2023.11.25 17:59:39.076 1: Assigning device ShellyPlugS_Esszimmer_Vitrine SHELLYID 2682D9
2023.11.25 17:59:39.202 1: [Shelly_status] Device ShellyPlugS_Wohnzimmer_Nintendo has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.213 1: [Shelly_status] Device ShellyPlugS_Esszimmer_Buecher has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.234 3: [Shelly_status] Shelly1_GaesteWC_Fenster: Error in callback, update in 60 seconds
2023.11.25 17:59:39.234 1: [Shelly_status] Device Shelly1_GaesteWC_Fenster has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.238 1: [Shelly_status] Device ShellyPlugS_Wohnzimmer_Soundbar has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.243 1: [Shelly_status] Device ShellyPlugS_Gartenhaus_Weatherman has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.256 1: [Shelly_status] Device Shelly1plus_Sonos_Bad has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.261 3: [Shelly_status] ShellyPlugS_Buero_3dPrinter: Error in callback, update in 240 seconds
2023.11.25 17:59:39.261 1: [Shelly_status] Device ShellyPlugS_Buero_3dPrinter has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.266 1: [Shelly_status] Device ShellyPlugS_Wohnzimmer_TVLicht has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.274 3: [Shelly_status] ShellyPlugS_Buero_3dPrinter: Error in callback, update in 240 seconds
2023.11.25 17:59:39.274 1: [Shelly_status] Device ShellyPlugS_Buero_3dPrinter has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.283 1: [Shelly_status] Device ShellyPlugS_Wohnzimmer_Switch has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.295 1: [Shelly_status] Device ShellyPlugS_Joschua_Radio has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.307 1: [Shelly_status] Device ShellyPlugS_Wohnzimmer_Nintendo has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.308 1: [Shelly_status] Device ShellyPlugS_Kueche_Kuehlschrank has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.320 1: [Shelly_status] Device ShellyPlugS_Kueche_S5Energie has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.323 2: [Shelly_get_model] Unsuccessful: Got no 'type' (Vendor-ID) for device ShellyPlugS_Buero_3dPrinter, proposed model is 'generic'
2023.11.25 17:59:39.326 2: [Shelly_get_model] type not found, proposed model of device ShellyPlugS_Buero_3dPrinter is 'generic'
2023.11.25 17:59:39.326 2: [Shelly_get_model] the model of device ShellyPlugS_Buero_3dPrinter is already defined as 'shellyplug'
2023.11.25 17:59:39.328 4: [Shelly_get_model] deleted defchannel from device ShellyPlugS_Buero_3dPrinter: model=generic, mode=not defined
2023.11.25 17:59:39.332 1: [Shelly_status] Device ShellyPlugS_Esszimmer_Vitrine has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.341 1: [Shelly_status] Device ShellyPlugS_HWR_Waschmaschine has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.346 1: [Shelly_status] Device ShellyPlugS_FlurOG_LampeTreppe has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.366 1: [Shelly_status] Device ShellyPlugS_Kueche_Kuehlschrank has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.367 1: [Shelly_status] Device Shelly1_Flur_Fenster has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.396 1: [Shelly_status] Device ShellyPlugS_Wohnzimmer_TVLicht has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.397 1: [Shelly_status] Device ShellyPlugS_Kueche_SpueMa has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.403 1: [Shelly_status] Device Shelly1_Buero_Drucker has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.415 1: [Shelly_status] Device ShellyPlugS_Waeschezimmer_TV has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.418 1: [Shelly_status] Device ShellyPlugS_Esszimmer_Vitrine has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.434 1: [Shelly_status] Device ShellyPlugS_Joschua_Kacheln has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.442 1: [Shelly_status] Device ShellyPlugS_Buero_MasterSwitch has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.462 1: [Shelly_status] Device Shelly1plus_Sonos_Bad has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.465 1: [Shelly_status] Device ShellyPlugS_HWR_Switch has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.468 1: [Shelly_status] Device ShellyPlugS_Buero_DienstNB has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.472 1: [Shelly_status] Device ShellyPlugS_Wohnzimmer_Kodi has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.475 1: [Shelly_status] Device shelly25_Carport has Error 'Error: Timeout reading', state is set to 'Error: Network'
2023.11.25 17:59:39.521 1: PERL WARNING: Use of uninitialized value $FW_wname in concatenation (.) or string at ./FHEM/36_Shelly.pm line 888.
2023.11.25 17:59:39.558 2: [Shelly_get_model] device Shelly1_GaesteWC_Fenster is of type SHSW-1
2023.11.25 17:59:39.558 2: [Shelly_get_model] discovered model=shelly1 for device Shelly1_GaesteWC_Fenster
2023.11.25 17:59:39.559 2: [Shelly_get_model] the model of device Shelly1_GaesteWC_Fenster is already defined as 'shelly1'
2023.11.25 17:59:39.892 1: Assigning device ShellyPlugS_Buero_MasterSwitch SHELLYID B4C9E3
2023.11.25 17:59:39.924 4: [Shelly_get_model] ShellyPlugS_Buero_3dPrinter: received 1788 byte of data from device
2023.11.25 17:59:39.924 5: [Shelly_get_model] ShellyPlugS_Buero_3dPrinter: received data is:
2023.11.25 17:59:39.924 2: [Shelly_get_model] device ShellyPlugS_Buero_3dPrinter is of type SHPLG-S
2023.11.25 17:59:39.925 2: [Shelly_get_model] discovered model=shellyplug for device ShellyPlugS_Buero_3dPrinter
2023.11.25 17:59:39.925 2: [Shelly_get_model] the model of device ShellyPlugS_Buero_3dPrinter is already defined as 'shellyplug'
2023.11.25 17:59:39.927 4: [Shelly_get_model] deleted defchannel from device ShellyPlugS_Buero_3dPrinter: model=shellyplug, mode=not defined
2023.11.25 17:59:40.112 2: [Shelly_get_model] device ShellyPlugS_Kueche_LichtArbeitsflaeche is of type SHPLG-S
2023.11.25 17:59:40.112 2: [Shelly_get_model] discovered model=shellyplug for device ShellyPlugS_Kueche_LichtArbeitsflaeche
2023.11.25 17:59:40.112 2: [Shelly_get_model] the model of device ShellyPlugS_Kueche_LichtArbeitsflaeche is already defined as 'shellyplug'
2023.11.25 17:59:40.135 1: Assigning device ShellyPlugS_Kueche_LichtArbeitsflaeche SHELLYID 267DB4
2023.11.25 17:59:40.324 1: Assigning device ShellyPlugS_Wohnzimmer_Switch SHELLYID DE660F
2023.11.25 17:59:40.332 1: Assigning device ShellyPlugS_Wohnzimmer_SofaLampe SHELLYID DE6A07
2023.11.25 17:59:40.376 1: Assigning device ShellyPlugS_Waeschezimmer_Sonos SHELLYID DDA976
2023.11.25 17:59:40.401 1: Assigning device ShellyPlugS_Kueche_SpueMa SHELLYID 42EE17
2023.11.25 17:59:40.487 1: Assigning device ShellyPlugS_Buero_DienstNB SHELLYID 80151C
2023.11.25 17:59:40.663 1: Assigning device ShellyPlugS_HWR_Waschmaschine SHELLYID EA7749
2023.11.25 17:59:40.676 1: Assigning device ShellyPlugS_Gartenhaus_Weatherman SHELLYID 801011
2023.11.25 17:59:40.696 1: Assigning device ShellyPlugS_Wohnzimmer_Kodi SHELLYID B86B21
2023.11.25 17:59:40.712 1: Assigning device ShellyPlugS_Wohnzimmer_Soundbar SHELLYID A75682
2023.11.25 17:59:40.722 1: Assigning device ShellyPlugS_Buero_PC SHELLYID BCFF4D5A27E9
2023.11.25 17:59:40.738 1: Assigning device ShellyPlugS_Leselicht_Meike SHELLYID 80646F815902
2023.11.25 17:59:40.743 1: Assigning device ShellyPlugS_Joschua_Kacheln SHELLYID 80646F82976D
2023.11.25 17:59:40.747 1: Assigning device ShellyPlugS_Joschua_Radio SHELLYID 43814A
2023.11.25 17:59:40.752 1: Assigning device Shelly1_Diele_NeyLicht SHELLYID 76776B
2023.11.25 17:59:40.758 1: Assigning device ShellyPlugS_Wohnzimmer_TVLicht SHELLYID F8C43C
2023.11.25 17:59:40.763 1: Assigning device ShellyPlugS_Wohnzimmer_TV SHELLYID 040EFD
2023.11.25 17:59:40.772 1: Assigning device Shelly1_GaesteWC_Fenster SHELLYID BA59A2
2023.11.25 17:59:40.777 1: Assigning device Shelly1_Buero_Drucker SHELLYID 3494546A752C
2023.11.25 17:59:40.782 1: Assigning device ShellyPlugS_Wohnzimmer_WandTablet SHELLYID C398D2
2023.11.25 17:59:40.787 1: Assigning device ShellyPlugS_Wohnzimmer_Nintendo SHELLYID C8C9A38913D8
2023.11.25 17:59:40.791 1: Assigning device Shelly1_Wohnzimmer_Stehlampe SHELLYID B8D182
2023.11.25 17:59:40.796 1: Assigning device ShellyPlugS_HWR_Switch SHELLYID DE57D4
2023.11.25 17:59:40.800 1: Assigning device ShellyPlugS_Buero_3dPrinter SHELLYID BC771A
2023.11.25 17:59:40.804 1: Assigning device ShellyPlugS_Kueche_Dunsthaube SHELLYID 3CE90EE0A0B7
2023.11.25 17:59:40.813 1: Assigning device ShellyPlugS_Kueche_Kuehlschrank SHELLYID DDF2AD
2023.11.25 17:59:40.818 1: Assigning device ShellyPlugS_FlurOG_LampeTreppe SHELLYID A41666
2023.11.25 17:59:40.823 1: Assigning device ShellyPlugS_Wohnzimmer_Sonos SHELLYID B86885
2023.11.25 17:59:40.828 1: Assigning device ShellyPlugS_Gartenhaus_Gefrierschrank SHELLYID C38CAE
2023.11.25 17:59:40.840 1: Assigning device ShellyPlug_HWR_Trockner SHELLYID 16A35D
2023.11.25 17:59:40.848 1: Assigning device Shelly1_Flur_Fenster SHELLYID 76776D
2023.11.25 17:59:40.870 1: Assigning device Shelly1_Dachboden_Licht SHELLYID B92A44
2023.11.25 17:59:40.875 1: Assigning device ShellyPlugS_Garten_Dena SHELLYID 436926
2023.11.25 17:59:40.880 1: Assigning device ShellyPlugS_Esszimmer_Buecher SHELLYID 041D16
2023.11.25 17:59:40.884 1: Assigning device ShellyPlugS_Kueche_Sonos SHELLYID B865A0
2023.11.25 17:59:40.889 1: Assigning device ShellyPlugS_Kueche_S5Energie SHELLYID C4F532
2023.11.25 18:03:39.277 4: [Shelly_status(1G)] issue a non-blocking call to http://christoph:Qwer123tz!192.168.1.46@192.168.1.172/status
2023.11.25 18:03:39.313 5: [Shelly_status] device ShellyPlugS_Buero_3dPrinter of model shellyplug has returned data
2023.11.25 18:03:39.314 5: [Shelly_rssi] returns -33 to device ShellyPlugS_Buero_3dPrinter
2023.11.25 18:03:39.316 4: [Shelly_proc1G] ShellyPlugS_Buero_3dPrinter: Looking for metering values
2023.11.25 18:03:39.317 5: [Shelly_proc1G] ShellyPlugS_Buero_3dPrinter : power=0 TTL=0, energy=0.3 TTL=18
2023.11.25 18:03:39.325 4: [Shelly_status] ShellyPlugS_Buero_3dPrinter: proc.G returned with value=43200 for comp none
2023.11.25 18:03:39.325 4: [Shelly_status] ShellyPlugS_Buero_3dPrinter: next update in 43200 seconds
2023.11.25 19:00:04.325 4: Home: executed CMDs: {Log 1, "Routine Abend:"};; { { fhem ("set Heizung_Joschua_Climate desired-temp 17.0;;;; set Heizung_Arbeitszimmer_Clima controlMode auto;;;; set Heizung_Arbeitszimmer_Clima desired-temp 17.0")};; {if (("ShellyPlugS_Wohnzimmer_TVLicht" eq "on") && ("ShellyPlugS_Wohnzimmer_SofaLampe" eq "on")) { fhem ("set ShellyPlugS_Wohnzimmer_SofaLampe off;;;; set Tablet_Wohnzimmer speak 'Dies ist ein Test'" ) } } }
2023.11.26 00:00:00.246 4: Home: executed CMDs: {Log 1, "Routinen Mitternacht:"};; {if (("ShellyPlugS_Wohnzimmer_TVLicht" eq "off") && ("ShellyPlugS_Wohnzimmer_SofaLampe" eq "off")) {fhem ("set ShellyPlugS_Wohnzimmer_TV off;;;; set ShellyPlugS_Wohnzimmer_Soundbar off;;;; set ShellyPlugS_Wohnzimmer_Kodi off") } }
2023.11.26 05:30:02.466 4: Home: executed CMDs: {if (!$we) {fhem "set Shelly1_Flur_Fenster:FILTER=state!=on on"}}
2023.11.26 06:03:39.329 4: [Shelly_status(1G)] issue a non-blocking call to http://christoph:Qwer123tz!192.168.1.46@192.168.1.172/status
2023.11.26 06:03:39.379 5: [Shelly_status] device ShellyPlugS_Buero_3dPrinter of model shellyplug has returned data
2023.11.26 06:03:39.381 5: [Shelly_rssi] returns -32 to device ShellyPlugS_Buero_3dPrinter
2023.11.26 06:03:39.383 4: [Shelly_proc1G] ShellyPlugS_Buero_3dPrinter: Looking for metering values
2023.11.26 06:03:39.383 5: [Shelly_proc1G] ShellyPlugS_Buero_3dPrinter : power=0 TTL=0, energy=0.3 TTL=18
2023.11.26 06:03:39.391 4: [Shelly_status] ShellyPlugS_Buero_3dPrinter: proc.G returned with value=43200 for comp none
2023.11.26 06:03:39.392 4: [Shelly_status] ShellyPlugS_Buero_3dPrinter: next update in 43200 seconds
2023.11.26 11:29:54.202 5: [Shelly_Get] ShellyPlugS_Buero_3dPrinter: unknown argument ?, choose one of status:noArg shelly_status:noArg registers:noArg config version:noArg model:noArg
Es wurde ausschließlich fhem nach einem Modul-Update neu gestartet, der Server als solches lief ganz normal weiter ...
Hallo alle miteinander,
seit dem letzten Shelly Modulupdate habe ich bei meinen Pro4pm's festgestellt das alle Schalter in Fhemweb ON/OFF bedienen.
Vorher on/off (klein geschrieben).
Der Unterschied besteht darin dass alle Kanäle eines Pro4 mit jedem Schalter gleichzeitig ausgeführt werden.
Kann ich das selbst irgendwie ändern oder ist das ein Fehler im Modul?
Jetzt hoffe ich nur das ich es einigermaßen verständlich rüber gebracht habe ;D
Danke euch.
Viele Grüße
Michiii
Zitat von: caldir65 am 25 November 2023, 22:37:21Ich habe seit einiger Zeit jetzt das Problem, daß nach einem Neustart von fhem ein paar meiner 40 Shellys im Status "initialized", vereinzelt auch "Networks error" stehen.
40 Shellies ist schon ein ganz beachtlicher Gerätepark...ich kann mir vorstellen, dass beim Neustart zu viel gleichzeitig vom System abverlangt wird.
Muss ich mir anschauen.
Hallo michiii@gmx.de,
willkommen im Forum.
Zitat von: michiii@gmx.de am 26 November 2023, 16:04:53seit dem letzten Shelly Modulupdate habe ich bei meinen Pro4pm's festgestellt das alle Schalter in Fhemweb ON/OFF bedienen.
Vorher on/off (klein geschrieben).
Das gemeinsame Schalten aller Kanäle von Mehrfachkanal-Aktoren ist kein Fehler, sondern eine neue Eigenschaft. Die Befehle on und off sind weiterhin vorhanden. Sie funktionieren auf der Weboberfläche aber nur, wenn ein Kanal als Default (attr defchannel) definiert ist.
Wenn dich das stört, kannst du mittels
attr <device> webCmd on:off die Webansicht so wie gewohnt einstellen.
Mit
attr stateFormat <device> relay_<x> kannst du außerdem das "OK" durch ein Icon für den ausgewählten Kanal ersetzen.
Hi Starkstrombastler.
Na wenn es immer so einfach ginge. Habe echt lange gesucht und nichts dazu gefunden.
stateFormat habe ich bereits konfiguriert.
Allgemein bin ich schon länger dabei und lese viel im Forum. Bisher habe ich keine Hilfe gebraucht da man wirklich sehr viel nachlesen kann. Aber naja irgend wann ist es immer das erste mal ;D
Vielen Dank für deine Hilfe.
Moin,
ich bin auf ein neues Phänomen gestoßen: ich wollte einen ShellyPlugS per fhem rebooten mittels Kommando
set ShellyPlugS rebooterhalte ich in der Oberfläche eine FM
register 'reboot' not found or empty [channel o] im Parameterfeld zu set, der Shelly scheint aber trotzdem zu rebooten. Ist also wohl mehr kosmetischer Natur.
Gruß, Christoph
Zitat von: caldir65 am 29 November 2023, 12:05:27ich wollte einen ShellyPlugS per fhem rebooten mittels Kommando ... erhalte ich in der Oberfläche eine FM
Danke für den Hinweis!
Hallo,
ich habe ganz neu Shelly plus Plus S eingebunden.
Diese werden als shellyplusplug eingebunden.
Ich habe aber bei set weder on noch off.
Wenn ich get config auswähle erhalte ich folgende Meldung "Please set/get configuration of 2nd-Gen devices via Shelly-App or homepage of the Shelly"
Meine Shelly plus PM funktionieren einwandfrei.
Was muss ich ändern?
@caldir65,
der Fehler
Zitat von: caldir65 am 29 November 2023, 12:05:27register 'reboot' not found or empty [channel o]
ist tatsächlich nur "kosmetisch" - ist im nächsten Update behoben.
Der ShellyPlusPlugS lässt sich aber problemlos mittels den Dropdown-Befehlen "on", "off" etc. schalten (siehe vorstehenden Post von teufelchen)?
@teufelchen:
Zitat von: teufelchen am 02 Dezember 2023, 13:42:39Ich habe aber bei set weder on noch off.
Wie lautet die Antwort, wenn du in der Fhem Kommandozeile
set <device> ? eingibst?
Lässt sich der Shelly mit dem Befehl (Kommandozeile)
set <device> on bzw.
off schalten?
Und was ist mit den Befehlen
toggle, on-for-timer, off-for-timer?
Zitat von: teufelchen am 02 Dezember 2023, 13:42:39Wenn ich get config auswähle erhalte ich folgende Meldung "Please set/get configuration of 2nd-Gen devices via Shelly-App or homepage of the Shelly"
Das hat nichts mit dem Schalten zu tun. Mit get config können bei Gen1-Geräten Befehle an den Shelly übertragen werden, die im Modul nicht explizit programmiert sind. Ist für Gen2-Geräte (noch) nicht implementiert - daher der Verweis auf die App bzw. Homepage.
Hallo zusammen, liebes Forum,
wie kann ich denneinen Shelly Plus 2PM einbinden, der 2 Lampen schaltet?
Update von 36_Shelly hat mir nichts gebracht - das Shelly 2PM Template bringt hier nichts.
Danke & Grüße
Zitat von: econ_sl83 am 04 Dezember 2023, 18:38:44wie kann ich denneinen Shelly Plus 2PM einbinden, der 2 Lampen schaltet?
define <devicename> Shelly <ip-adress>
Zitat von: Starkstrombastler am 02 Dezember 2023, 19:25:32@caldir65,
der Fehler
Zitat von: caldir65 am 29 November 2023, 12:05:27register 'reboot' not found or empty [channel o]
ist tatsächlich nur "kosmetisch" - ist im nächsten Update behoben.
Der ShellyPlusPlugS lässt sich aber problemlos mittels den Dropdown-Befehlen "on", "off" etc. schalten (siehe vorstehenden Post von teufelchen)?
Hallo starkstrombastler,
ja, ausser der Anzeige habe ich keine Probleme im laufenden Betrieb. Einzig nach einem Neustart werden einige Shelly's nicht mehr als initialisiert, und ich muß einmalig den Status abfragen - aber das hatte ich ja bereits früher berichtet ... auch werden bei mir bisher PlugS (alte Variante) korrekt angelegt mitt "Lampe" (Status) und den on- und off-Schaltern. Es sind ShellyPlugS (keine Plus)
Gruß, Christoph
Hallo caldir65,
Danke für die Infos. Das Problem von
teufelchen scheint also an etwas anderem zu liegen - wir haben hier auch nichts mehr davon gehört.
Bei diesem Thema
Zitat von: caldir65 am 04 Dezember 2023, 21:57:02Einzig nach einem Neustart werden einige Shelly's nicht mehr als initialisiert, und ich muß einmalig den Status abfragen
bin ich dran: Systemlast zum Neustart entlasten bzw. entzerren - das gestaltet sich aber etwas aufwändiger.
Zitat von: Starkstrombastler am 04 Dezember 2023, 21:52:15Zitat von: econ_sl83 am 04 Dezember 2023, 18:38:44wie kann ich denneinen Shelly Plus 2PM einbinden, der 2 Lampen schaltet?
define <devicename> Shelly <ip-adress>
ahhh - Danke! So einfach hätte ich das tatsächlich nicht erwartet. Super!
Zitat von: Starkstrombastler am 05 Dezember 2023, 09:11:27Bei diesem Thema
Zitat von: caldir65 am 04 Dezember 2023, 21:57:02Einzig nach einem Neustart werden einige Shelly's nicht mehr als initialisiert, und ich muß einmalig den Status abfragen
bin ich dran: Systemlast zum Neustart entlasten bzw. entzerren - das gestaltet sich aber etwas aufwändiger.
Ich wollte jetzt nicht drängen ;-) Ich starte auch nicht täglich neu
Hallo zusammen,
ich habe auch seit kurzem das Shelly Modul eingebunden, erst mal vielen Dank dafür. Habe mir nun einen Shelly Dimmer2 gekauft und eine Frage zu Befehlen, da ich mit dem Shelly einen HM Dimmer ersetzt habe. Ich habe in vielen Automatisierungen den Befehl "set xy pct 80 120" drin (von dem HM Dimmer), was ja dazu führt, dass der Dimmer auf 80% hochdimmt und gleichzeitig einschaltet und zwar für 120 Sekunden. Wenn ich das so bei dem Shelly mache, geht der zwar auch auf 80%, schaltet den Shelly aber nicht ein. Wie muss ich den Befehl anpassen? Oder muss ich im Shelly define selbst etwas ändern? Das sieht aktuell so aus:
CFGFN
CHANGED
DEF 192.168.188.71
DURATION 0
FUUID 656f7d8c-f33f-1a65-9d5c-c4b778c0588b6565
INTERVAL 5
NAME Lampe_Garage_hinten
NR 634293
SHELLYID shellydimmer2-C8C9A325AEA6
STATE aus
TCPIP 192.168.188.71
TYPE Shelly
READINGS:
2023-12-05 20:44:12 cloud disabled
2023-12-07 22:33:00 energy 20.1
2023-12-05 20:44:12 firmware v1.14.0
2023-12-05 20:44:12 network <html>connected to <a href="http://192.168.188.71">192.168.188.71</a></html>
2023-12-07 22:31:49 pct 88
2023-12-07 22:32:29 power 0
2023-12-07 22:32:29 state off
Attributes:
devStateIcon aus:light_light_dim_00 10:light_light_dim_10@yellow 20:light_light_dim_20@yellow 30:light_light_dim_30@yellow 40:light_light_dim_40@yellow 50:light_light_dim_50@orange 60:light_light_dim_60@orange 70:light_light_dim_70@orange 80:light_light_dim_80@orange 90:light_light_dim_90@orange an:light_light_dim_100@red
eventMap on:an off:aus
interval 5
model shellydimmer
room Aussen
webCmd an:pct:aus
widgetOverride pct:slider,1,1,100
Besten Dank und viele Grüße
Was muß ich beim HT (nicht Plus) eintragen, um die Temperatur zu fhem zu schicken?
Die Beschreibung geht ja nur auf die AddOn Module ein.
Ich habe es mit http://192.168.1.15:8083/fhem?XHR=1&cmd=set%20GartenDummy_Temp%20%20temperature*%20$temperature_0_range versucht, da kommt aber auch nach einem Tag nichts an.
Zitat von: Michi240281 am 07 Dezember 2023, 22:40:53"set xy pct 80 120"
Das wirst du wohl alles einzeln machen müssen: einschalten, auf 80% dimmen, 120 Sekunden warten und ausschalten.
Zitat von: Christian72D am 08 Dezember 2023, 08:54:56Zitat von: Michi240281 am 07 Dezember 2023, 22:40:53"set xy pct 80 120"
Das wirst du wohl alles einzeln machen müssen: einschalten, auf 80% dimmen, 120 Sekunden warten und ausschalten.
Das sollte doch gehen:
set xy pct 80; set xy on-for-timer 120
Sofern der Shelly on-for-timer kennt.
Alternativ:
set xy pct 80; set xy on; sleep 120; set xy off
Falls die 2 Befehle (pct und on bzw. on-for-timer) nicht direkt hintereinander können/dürfen, dann dazwischen auch noch ein kleines sleep...
Und je nachdem wo/wie man das verwendet die Strichpunkte doppeln (oder eben nicht)...
EDIT: gut ist dann ja einzeln ;) Aber kann so in/von einer Automatisierung (schätze notify/DOIF) verwendet werden wie zuvor der eine Aufruf?
Gruß, Joachim
Zitat von: MadMax-FHEM am 08 Dezember 2023, 09:29:39Das sollte doch gehen:
set xy pct 80; set xy on-for-timer 120
Muss ausprobiert werden, ob dadurch keine Timing-Probleme entstehen.
Wenn der Ausgang
IMMER nach 120 sek ausgeschaltet werden soll, geht auch folgendes:
1. auf der Shelly-Weboberfläche Settings -> Timer -> Auto Off enable und Wert auf 120 einstellen
(lässt sich mit dem nächsten Update des Shelly-Moduls auch mit
set xy config auto_off 120 erreichen)
2. in Fhem:
set xy dim 80Mit
set dim wird eingeschaltet und auf den angegebenen Wert gedimmt. Mit
set pct wird nur der Wert geändert, ohne einzuschalten. Dafür hatten wir hier letztens einen Anwendungsfall diskutiert, wo das genau so gebraucht wurde.
Wie würden denn die Anforderungen an ein
set dim-for-timer value time [channel] aussehen und wie ist das bei Homematic & Co gelöst?
- dimmen auf value und nach time ausschalten?
- dimmen auf value und nach time auf Ursprungswert dimmen?
- langsames Dimmen auf value ("rampe")?
- Einschalten und nach Zeit time auf value dimmen?
Zitat von: Starkstrombastler am 08 Dezember 2023, 15:58:41wie ist das bei Homematic & Co gelöst
Bei CUL_HM (alte! Implementierung):
Zitatpct <level> [<ontime>] [<ramptime>] - set actor to a desired absolut level.
Optional ontime and ramptime could be given for dimmer.
HUEDevice kennt z.B. nur ein optionales ramptime, keine Ausschaltzeit, bei ZWave scheint es ähnlich zu sein.
Leider mal wieder komplett uneinheitlich, und bei CUL_HM wäre es m.E. im Sinne der Einheitlichkeit eigentlich besser, die Parameter zu vertauschen (oder gleich namentlich übergeben zu können!). So muss man einmal mehr bereits beim Kommando wissen, welcher TYPE es ist...
PS: Super, dass du die Frage stellst!!!
Zitat von: Starkstrombastler am 08 Dezember 2023, 15:58:41Zitat von: MadMax-FHEM am 08 Dezember 2023, 09:29:39Das sollte doch gehen:
set xy pct 80; set xy on-for-timer 120
Muss ausprobiert werden, ob dadurch keine Timing-Probleme entstehen.
Wenn der Ausgang IMMER nach 120 sek ausgeschaltet werden soll, geht auch folgendes:
1. auf der Shelly-Weboberfläche Settings -> Timer -> Auto Off enable und Wert auf 120 einstellen
(lässt sich mit dem nächsten Update des Shelly-Moduls auch mit set xy config auto_off 120 erreichen)
2. in Fhem: set xy dim 80
Mit set dim wird eingeschaltet und auf den angegebenen Wert gedimmt. Mit set pct wird nur der Wert geändert, ohne einzuschalten. Dafür hatten wir hier letztens einen Anwendungsfall diskutiert, wo das genau so gebraucht wurde.
Wie würden denn die Anforderungen an ein set dim-for-timer value time [channel] aussehen und wie ist das bei Homematic & Co gelöst?
- dimmen auf value und nach time ausschalten?
- dimmen auf value und nach time auf Ursprungswert dimmen?
- langsames Dimmen auf value ("rampe")?
- Einschalten und nach Zeit time auf value dimmen?
Das mit dem set dim würde mir tatsächlich reichen, allerdings funktioniert der Befehl nicht, der Dimmer macht einfach gar nichts. Ne Idee?
Zitat von: teufelchen am 02 Dezember 2023, 13:42:39Hallo,
ich habe ganz neu Shelly plus Plus S eingebunden.
Diese werden als shellyplusplug eingebunden.
Ich habe aber bei set weder on noch off.
Wenn ich get config auswähle erhalte ich folgende Meldung "Please set/get configuration of 2nd-Gen devices via Shelly-App or homepage of the Shelly"
Meine Shelly plus PM funktionieren einwandfrei.
Was muss ich ändern?
Problem ist teilweise gelöst.
Schalter sind vorhanden wenn nach einstecken der Stecker FHEM neu gebootet wird.
Bei mir waren die Stecker diese Woche mehrere Tagen nicht mit Strom verbunden und FHEM wurde zwischenzeitlich neu gebootet, lassen sich die Stecker nicht mehr schalten, auch ein get Status hilft nicht.
Nach einen Neustart von FHEM funktionieren die Stecker dann wieder problemlos.
Zitat von: Michi240281 am 08 Dezember 2023, 22:06:38Das mit dem set dim würde mir tatsächlich reichen, allerdings funktioniert der Befehl nicht, der Dimmer macht einfach gar nichts.
Funktionieren andere Befehle ? Wenn nicht: Verkabelung geprüft und Stromversorgung OK? Fhem ist aktuell? Welche Version (
get xy version)? Firmware des Dimmers auf letztem Stand? Den Shelly neu gestartet? Bei Problemen Interaktion mit dem Shelly immer über sein Web-UI!
Was passiert bei Eingabe von
http://<ipadresse>/light/0?brightness=44&turn=on über den Browser (hier dimmen auf 44%)?
Zitat von: teufelchen am 08 Dezember 2023, 23:00:46Bei mir waren die Stecker diese Woche mehrere Tagen nicht mit Strom verbunden und FHEM wurde zwischenzeitlich neu gebootet, lassen sich die Stecker nicht mehr schalten, auch ein get Status hilft nicht.
Vermutlich wurde das Logfile mit
Error: Network geflutet - fhem versucht ja immer wieder aufs Neue zu pollen.
Wenn dann die Re-Integration scheitert könnte eine erneute Definition via defmod oder DEF hilfreich sein.
Mit dem nächsten Update des Shelly-Moduls wird der Startvorgang komplett überarbeitet sein und diese Probleme sind (hoffentlich) beseitigt.
Zitat von: Michi240281 am 07 Dezember 2023, 22:40:53Wie muss ich den Befehl anpassen?
Ich habe das Einschalten und Dimmen mit einem cmdalias gelöst:
ALIAS set
DEF set ShellyDimmer.* pctx .* AS { fhem("set $EVTPART0 on; set $EVTPART0 pct $EVTPART2") }Der Befehl "set ... pctx 50" schaltet dann ein und dimmt auf 50%.
ZitatBei Problemen Interaktion mit dem Shelly immer über sein Web-UI!
Richtig. Erst wenn das funktioniert, kann man den Fehler in FHEM suchen.
LG
pah
Zitat von: Starkstrombastler am 09 Dezember 2023, 09:08:42Zitat von: Michi240281 am 08 Dezember 2023, 22:06:38Das mit dem set dim würde mir tatsächlich reichen, allerdings funktioniert der Befehl nicht, der Dimmer macht einfach gar nichts.
Funktionieren andere Befehle ? Wenn nicht: Verkabelung geprüft und Stromversorgung OK? Fhem ist aktuell? Welche Version (get xy version)? Firmware des Dimmers auf letztem Stand? Den Shelly neu gestartet? Bei Problemen Interaktion mit dem Shelly immer über sein Web-UI!
Was passiert bei Eingabe von http://<ipadresse>/light/0?brightness=44&turn=on über den Browser (hier dimmen auf 44%)?
Ja, on off, on-for-timer und pct funktionieren, nur dim tut nix.
Der Befehl gibt im Expolorer folgendes aus und der Dimmer geht auf 44% und schaltet sich ein:
{"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":44,"transition":0}Lampe_Garage_hinten.version => 4.01
Shelly Firmware ist aktuell. Fhem ist schon länger nicht aktualisiert worden, und ich traue mich ehrlich nicht das zu machen, denn dann werden ganz sicher zig Sachen nicht mehr so funktionieren wie vorher und ich habe aktuell keine Zeit, tagelange Fehlersuche zu betreiben.
UPDATE: Habe die neuste Shelly.pm runtergeladen und eingebunden, nun funktioniert der dim Befehl! :-) Ein "dim-for-timer" wäre genial!
Zitat[Shelly_Set] Error: forbidden command 'off' for device A.Sw.s4a
bei meinem schönen alten Shelly Pro 4 - Öh.
Mindestens temporär stelle ich mal auf die letzte Version um, die noch von mir war.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 14 Dezember 2023, 09:47:19Zitat[Shelly_Set] Error: forbidden command 'off' for device A.Sw.s4a
bei meinem schönen alten Shelly Pro 4 - Öh.
mit meinem Shelly4PRO (Gen.1) kann ich das leider nicht nachvollziehen.
Bitte mal ein List des Devices posten.
VG
Starkstrombastler
Zitat von: Starkstrombastler am 18 Dezember 2022, 09:55:31Zitat von: Prof. Dr. Peter Henning am 02 Dezember 2022, 16:09:53Die ganzen neueren Modelle sind im Modul immerhin rudimentär implementiert, da ist aber noch Einiges zu tun.
Ich werde in den nächsten Tagen an dieser Stelle eine neue Version veröffentlichen, welche den Shelly Plus2PM weitergehend berücksichtigt.
Das ist jetzt genau 1 Jahr und einige Hundert Stunden Learning-on-the-Job her. Und aus den Reaktionen hier auf die letzte Aktualisierung (nämlich: keine) schlussfolgere ich, dass die Erweiterungen im Modul inzwischen stabil laufen.
Vielen Dank an Alle, die bei den Testversionen mitgeholfen haben (die Testversionen werde ich jetzt aus meinen Forumsbeiträgen entfernen).
Die Entwicklung geht natürlich weiter: neben einigen kleineren Funktionserweiterungen, wie z.B. dim-for-timer, steht die vollständige Umstellung der Gen-2-Geräte auf die Gen-2-API auf dem Plan.
Zitat von: Starkstrombastler am 19 Dezember 2023, 10:25:46...
Das ist jetzt genau 1 Jahr und einige Hundert Stunden Learning-on-the-Job her. Und aus den Reaktionen hier auf die letzte Aktualisierung (nämlich: keine) schlussfolgere ich, dass die Erweiterungen im Modul inzwischen stabil laufen...
...Die Entwicklung geht natürlich weiter...
@Starkstrombastler
Tolle Sache und alle Achtung, dass du dich der Aufgabe angenommen hast. Da ist im letzten Jahr ne ganze Menge passiert.
Für mich hat das Modul auf jeden Fall seine Berechtigung und freue mich wenn es weiter geht, auch wenn mit MQTT eine generische zur Verfügung steht - über die jedoch immer wieder Anwender stolpern.
Gruß und bald schöne Feiertage.
Hallo,
habe mir einen Shelly Plus 1 mit Addon zugelegt und Temperatursensor und Magnetschalter angeschlossen und in FHEM Device angelegt.
Neueste Firmware ist drauf : 1.1.0
Für den Magnetschalter (Input(100)) habe ich Actions definiert.
Wenn ich den Schalter nun öffne und wieder schliesse kommen die Events aber immer 4 mal zeitverzögert in FHEM an.
Auf der Webseite des Devices sehe ich dieses toggeln nicht
z.B. http://192.168.1.xxx:xxxx/fhem?XHR=1&cmd=set%20Shelly_Plus1_Holzgarage%20button_on%20100
2023-12-21 10:40:20 Shelly Shelly_Plus1_Holzgarage button_100: off
2023-12-21 10:40:21 Shelly Shelly_Plus1_Holzgarage button_100: on
2023-12-21 10:40:37 Shelly Shelly_Plus1_Holzgarage button_100: off
2023-12-21 10:40:37 Shelly Shelly_Plus1_Holzgarage button_100: on
2023-12-21 10:40:39 Shelly Shelly_Plus1_Holzgarage inttemp: 55.4
2023-12-21 10:40:52 Shelly Shelly_Plus1_Holzgarage button_100: off
2023-12-21 10:40:53 Shelly Shelly_Plus1_Holzgarage button_100: on
2023-12-21 10:40:55 Shelly Shelly_Plus1_Holzgarage inttemp: 55.5
2023-12-21 10:41:08 Shelly Shelly_Plus1_Holzgarage button_100: off
2023-12-21 10:41:09 Shelly Shelly_Plus1_Holzgarage button_100: on
2023-12-21 10:41:11 Shelly Shelly_Plus1_Holzgarage inttemp: 55.6
Mache ich was falsch oder ist das ein bekanntes Problem ?
Gruss
Joe
Zitat von: cotecmania am 21 Dezember 2023, 10:49:55Wenn ich den Schalter nun öffne und wieder schliesse kommen die Events aber immer 4 mal zeitverzögert in FHEM an.
Diese Wiederholungen mit t=16sec hatten wir hier schon einmal.
Probier mal ohne XHR, also:
http://192.168.1.xxx:xxxx/fhem?cmd=set%20Shelly_Plus1_Holzgarage%20button_on%20100
Perfekt ! Das wars !
Hast Du mir 'nen Link zum Problem bzw. was macht das XHR=1 und warum kann ich es weglassen ?
In den Dokus war das ja immer mit drin.
Gruss und Danke
Joe
Ich habe mehrere Shelly1 Schalter mit anderen Komponenten in einer structure zusammengefasst. Diese schalte ich dann über set on bzw. set off.
Jetzt wollte ich der structure auch einen ShellyPlugS hinzufügen. Der schaltet aber über die structure nicht. Der ShellyPlugS bietet in der der ,,Set" Auswahl auch kein on bzw. off.
Ich hoffe ich habe mich verständlich ausgedrückt?
Den Spaß hatte ich heute auch beim Spielen mit einem Shelly 3gen 1PM mini.
Wie bist Du vorgegangen?
Ich war so vorgegangen:
1) define gen3 Shelly <ip>
2) attr gen3 model shellypro1pm
Dann war on / off etc. nicht im Set-Pulldown-Menü.
Save config & restart von FHEM: on / off da.
Wäre nett, wenn Du mal den Restart probieren könntest: Dann hättest Du meinen Fehler reproduziert.
Ursache wäre dann, dass nach einem Setzen des Models die verfügbaren Settings nicht aktualisiert werden.
Zitat von: Fredi69 am 21 Dezember 2023, 21:28:51Der ShellyPlugS bietet in der der ,,Set" Auswahl auch kein on bzw. off.
Welches Model wurde denn beim Define vom Modul automatisch ermittelt?
Lässt sich das Device über die Befehlszeile on und off schalten?
Sind die Befehle toggle on/off-for-timer im Pulldown vorhanden?
Bitte den Vorgang mit verbose=4 loggen.
Wie ist denn das Ergebnis, wenn in der Fhem-Befehlszeile
set <device> ? eingegeben wird? Mit diesem Befehl fragt FHEMWEB beim Device nach um das Drop-Down entsprechend aufzubauen. Maßgeblich ist das, was nach "unknown ... choose one of" kommt.
Hilfreich ist auch ein Device-List via
Copy for forum
Zitat von: Starkstrombastler am 21 Dezember 2023, 22:30:23Welches Model wurde denn beim Define vom Modul automatisch ermittelt?
Vorab: Update auf aktuelle Version, dann folgende Zeile reingepatcht:
root@sauerberry:/opt/fhem/FHEM# diff 36_Shelly.pm /tmp/
300a301
> "S3SW-001P8EU" => "shellyplus1pm", # Shelly 1PM Mini Gen3
Restart.
define gen3 Shelly 192.168.0.87
dann erkennt er korrekt "shellyplus1pm".
ZitatLässt sich das Device über die Befehlszeile on und off schalten?
Ja, und funktioniert auch.
ZitatSind die Befehle toggle on/off-for-timer im Pulldown vorhanden?
Nein. Aber nach einem "shutdown restart" ist alles da.
ZitatBitte den Vorgang mit verbose=4 loggen.
Weißt Du, wie ich bereits beim Define für ein "verbose=4" sorgen kann?
Danach ist mir klar...
ZitatWie ist denn das Ergebnis, wenn in der Fhem-Befehlszeile
set <device> ? eingegeben wird? Mit diesem Befehl fragt FHEMWEB beim Device nach um das Drop-Down entsprechend aufzubauen. Maßgeblich ist das, was nach "unknown ... choose one of" kommt.
Vor Reboot:
shellyplus1pm : unknown argument ? choose one of config interval password reboot update nameNach Reboot komplett (mit on, off, u.s.w).
ZitatHilfreich ist auch ein Device-List via Copy for forum
Internals:
CFGFN
DEF 192.168.0.87
FUUID 6584b1e4-f33f-8d06-e736-4c5aa78441dece57
INTERVAL 60
NAME gen3
NR 520
SHELLY S3SW-001P8EU
SHELLYID shelly1pmminig3-84fce63b7ffc
STATE on
TCPIP 192.168.0.87
TYPE Shelly
eventCount 7
units 0
READINGS:
2023-12-21 22:45:38 cloud disabled
2023-12-21 22:45:28 current 0
2023-12-21 22:45:28 energy 0
2023-12-21 22:45:38 firmware v1.1.0
2023-12-21 22:45:28 frequency 50
2023-12-21 22:45:38 input off
2023-12-21 22:45:38 input_mode switch straight follow
2023-12-21 22:46:28 inttemp 61
2023-12-21 22:45:38 network <html>connected to <a href="http://192.168.0.87">192.168.0.87</a> (Wifi)</html>
2023-12-21 22:45:38 network_rssi -38
2023-12-21 22:45:38 network_ssid SBSTR10
2023-12-21 22:45:38 network_threshold -80
2023-12-21 22:45:28 power 0
2023-12-21 22:45:28 protection none
2023-12-21 22:45:28 relay on
2023-12-21 22:45:28 source http
2023-12-21 22:45:28 state on
2023-12-21 22:46:28 voltage 234.1
2023-12-21 22:45:20 webhook_cnt 0
2023-12-21 22:45:20 webhook_ver 0
helper:
Sets config interval password reboot:noArg update:noArg name
Attributes:
model shellyplus1pm
Zitat von: gvzdus am 21 Dezember 2023, 22:48:41Vor Reboot:
Code Auswählen Erweitern
shellyplus1pm : unknown argument ? choose one of config interval password reboot update name
Nach Reboot komplett (mit on, off, u.s.w).
Mit dieser Analyse ist die Lage klar:
Die Anfrage
set ... ? kommt in einigen (oder allen?) Installationen ziemlich oft - wir hatten das früher schon einmal hier im Forum diskutiert. Ich habe daher das zurückzuliefernde Ergenbnis in einem Helper zwischengespeichert, um hier etwas Systemlast zu reduzieren. Es kommt wohl bei einigen Usern vor, dass die Anfrage vor Abschluss der Initialisierung kommt und dann wird ein unvollständiges Setting ermittelt und gespeichert. Das ist mit dem nächsten Update gefixt.
Schön, dass es jetzt funktioniert.
Die Frage
Zitat von: cotecmania am 21 Dezember 2023, 15:47:42was macht das XHR=1 und warum kann ich es weglassen ?
stelle ich mir auch, denn das war schon vor meinen Aktivitäten im Modul bzw. der Doku mit drin.
Dass es ohne XHR geht habe ich auch nur durch Probieren herausgefunden. Vielleicht gibt es aber Umgebungen wo diese Einstellung benötigt wird.
Zitat von: Starkstrombastler am 21 Dezember 2023, 22:30:23Welches Model wurde denn beim Define vom Modul automatisch ermittelt?
shellyplusplug
Zitat von: Starkstrombastler am 21 Dezember 2023, 22:30:23Lässt sich das Device über die Befehlszeile on und off schalten?
ja
Zitat von: Starkstrombastler am 21 Dezember 2023, 22:30:23Sind die Befehle toggle on/off-for-timer im Pulldown vorhanden?
nein
Zitat von: Starkstrombastler am 21 Dezember 2023, 22:30:23Bitte den Vorgang mit verbose=4 loggen.
Wie ist denn das Ergebnis, wenn in der Fhem-Befehlszeile
set <device> ? eingegeben wird? Mit diesem Befehl fragt FHEMWEB beim Device nach um das Drop-Down entsprechend aufzubauen. Maßgeblich ist das, was nach "unknown ... choose one of" kommt.
Hilfreich ist auch ein Device-List via Copy for forum
shellyplusplug : unknown argument ? choose one of config interval password reboot update name
Zitat von: Fredi69 am 23 Dezember 2023, 13:55:10shellyplusplug : unknown argument ? choose one of config interval password reboot update name
die Angaben decken sich mit denen von gvzdus. Wenn du FHEM heute aktualisierst sollte das Problem behoben sein.
Habe einige Fragen zu meinem neuen ShellyPlusPlugS zusammen mit dem aktuellsten (vom 23.12.23) Modul Shelly.
Erstmal vorab: Der ShellyPlug läßt sich prima benutzen aus fhem heraus - Ein/Ausschalten oder power & energy plotten.
define ShellyPlug Shelly 192.168.178.44
attr ShellyPlug event-on-change-reading .*
attr ShellyPlug group EG
attr ShellyPlug model shellyplusplug
attr ShellyPlug webCmd on:off
# DEF 192.168.178.44
# FUUID 6587d7d1-f33f-fc3a-8aef-562dc7211c8c3dad
# INTERVAL 60
# NAME ShellyPlug
# NR 96
# SHELLYID shellyplusplugs-e465b8b4a8f8
# STATE off
# TCPIP 192.168.178.44
# TYPE Shelly
# eventCount 46
# units 0
# READINGS:
# 2023-12-24 08:04:12 cloud disabled
# 2023-12-24 19:36:12 current 0
# 2023-12-25 08:56:31 energy 7.124
# 2023-12-24 08:04:12 firmware v1.1.0
# 2023-12-25 09:02:41 inttemp 35
# 2023-12-25 08:25:57 network <html>connected to <a href="http://192.168.178.44">192.168.178.44</a> (Wifi)</html>
# 2023-12-25 08:22:55 network_disconnects 6
# 2023-12-25 09:02:40 network_rssi -52
# 2023-12-24 08:04:12 network_ssid Daheim24
# 2023-12-24 08:04:12 network_threshold -80
# 2023-12-24 08:07:21 overpower 0
# 2023-12-25 08:56:31 power 0
# 2023-12-24 08:04:04 protection none
# 2023-12-25 08:56:31 relay off
# 2023-12-25 08:26:20 source http
# 2023-12-25 08:56:31 state off
# 2023-12-24 08:07:21 timer -
# 2023-12-25 08:56:31 voltage 0
# 2023-12-24 08:03:55 webhook_cnt 0
# 2023-12-24 08:03:55 webhook_ver 0
# helper:
# Sets config interval password reboot:noArg update:noArg name on off toggle on-for-timer off-for-timer
#
setstate ShellyPlug off
setstate ShellyPlug 2023-12-24 08:04:12 cloud disabled
setstate ShellyPlug 2023-12-24 19:36:12 current 0
setstate ShellyPlug 2023-12-25 08:56:31 energy 7.124
setstate ShellyPlug 2023-12-24 08:04:12 firmware v1.1.0
setstate ShellyPlug 2023-12-25 09:02:41 inttemp 35
setstate ShellyPlug 2023-12-25 08:25:57 network <html>connected to <a href="http://192.168.178.44">192.168.178.44</a> (Wifi)</html>
setstate ShellyPlug 2023-12-25 08:22:55 network_disconnects 6
setstate ShellyPlug 2023-12-25 09:02:40 network_rssi -52
setstate ShellyPlug 2023-12-24 08:04:12 network_ssid Daheim24
setstate ShellyPlug 2023-12-24 08:04:12 network_threshold -80
setstate ShellyPlug 2023-12-24 08:07:21 overpower 0
setstate ShellyPlug 2023-12-25 08:56:31 power 0
setstate ShellyPlug 2023-12-24 08:04:04 protection none
setstate ShellyPlug 2023-12-25 08:56:31 relay off
setstate ShellyPlug 2023-12-25 08:26:20 source http
setstate ShellyPlug 2023-12-25 08:56:31 state off
setstate ShellyPlug 2023-12-24 08:07:21 timer -
setstate ShellyPlug 2023-12-25 08:56:31 voltage 0
setstate ShellyPlug 2023-12-24 08:03:55 webhook_cnt 0
setstate ShellyPlug 2023-12-24 08:03:55 webhook_ver 0
Nun zu meinen Fragen in aufsteigendem Schwierigkeitsgrad:-)
1. get ShellyPlug status oder shelly_status funktionieren beide nicht. version abfragen funktioniert.
2. energy akkumuliert die insgesamt verbraucht Energie (m.W. im Wmin). Aber wie kann man den Wert wieder auf 0 zurücksetzen?
3. Ich würde meinen ShellyPlug gern mit einem Paßwort sichern. Dazu kann man in der Shelly-WebGUI unter Settings->Device Settings->Authentication ein Paßwort vergeben, aber keinen Username. Wenn ich das tue, ist der Zugriff via URL wie erwartet mit diesem Paßwort geschützt. Im fhem-Modul kann ich durch
set ShellyPlug passwordauch ein Passwort setzen. Danach funktioniert der Zugriff aus fhem nicht mehr. Vielleicht, weil fhem einen Usernamen braucht?
attr ShellyPlug shellyuserAber wie lautet der shellyuser?
4. Der ShellyPlug hat auch einen Hardware-Schalter, mit dem man am Stecker das Relais aus/einschalten kann. Funktioniert prima. Aber dieses Schalten kommt nicht in fhem an. Hätte z.B. einen fhem-Event erwartet, sehe aber keinen. Oder noch besser, daß das on/off vom Hardware-Schalter sich direkt im fhem webcmd niederschlägt.
In der Doku vom Modul Shelly steht etwas in der Richtung oben in den Notes. Vermutlich sind da die Actions vom ShellyPlusPlugS gemeint. Aber wieso fragt der ShellyPlug den Status in fhem ab? Ich bräuchte eher die andere Richtung.
Alles keine Showstopper, aber nice-to-have.
Grüßle & - nicht zu vergessen - schöne Weihnachten,
Michael
Moin, gerade einmal mit einem PlusPlugS durchgespielt. In *dieser* Reihenfolge:
attr <device> shellyuser admin
set <device> password <passwort>
Caveats:
Erst explizit shellyuser auf "admin" setzen, dann erst Passwort setzen
Energie zurücksetzen: Müsste per Device-Reboot klappen.
Moin, ich habe mich jetzt auch mal an das Modul rangetraut. Wenn ich einen ersten Stand habe, melde ich mich.
Hintergrund: Die "Auto-Detection" (Shelly_get_model) läuft weiterhin bei mir nicht so prall. Damit fange ich an. Zielsetzungen:
- Wenn define mit laufendem FHEM erfolgt, Discovery sofort starten, ansonsten auf "global:INITIALIZED"-Event warten
- Statt der spezifischen Gen1/Gen2-URLs immer mit der URL /shelly anfangen: Die ist beiden Generationen gemeinsam und funktioniert auch bei PW-geschützten Geräten
- Weg von Timern, die asynchron und ggf. parallel Informationen fetchen, hin zu "Schritt für Schritt" so schnell wie möglich
Mittelfristiges Ziel: Websockets zu implementieren (das macht dann Webhooks überflüssig), um dann auch die Bluetooth-Gateway-Funktion zu unterstützen, damit die Shelly-BLU-Devices eingebunden werden können.
Zitat von: olwaldi am 25 Dezember 2023, 09:19:21get ShellyPlug status oder shelly_status funktionieren beide nicht
Muss ich mir anschauen.
Zitat von: olwaldi am 25 Dezember 2023, 09:19:21energy akkumuliert die insgesamt verbraucht Energie (m.W. im Wmin)
Mit
attr ... showunits ... kannst du die Readings formatieren.
Zitat von: olwaldi am 25 Dezember 2023, 09:19:21Aber wie kann man den Wert wieder auf 0 zurücksetzen?
Das geht derzeit nur so wie hier (https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Switch#switchresetcounters-example) beschrieben.
Zitat von: olwaldi am 25 Dezember 2023, 09:19:21Der ShellyPlug hat auch einen Hardware-Schalter, mit dem man am Stecker das Relais aus/einschalten kann.
Es handelt sich hier um einen Taster, der immer nur kurz betätigt wird. Um den Taster im Device zu sehen, muss auf dem Shelly eine Action angelegt werden. Das geht manuell oder automatisiert mittels dem Attribut 'webhook'. Die URL muss z.B. so aussehen:
http://192.168.178.100:8083/fhem?cmd=set%20MyShelly%20button_on
Zitat von: gvzdus am 25 Dezember 2023, 10:05:27Moin, gerade einmal mit einem PlusPlugS durchgespielt. In *dieser* Reihenfolge:
attr <device> shellyuser admin
set <device> password <passwort>
Caveats:
Erst explizit shellyuser auf "admin" setzen, dann erst Passwort setzen
Ist das damit:
2158 if( $cmd eq "password" ){
2159 my $user = AttrVal($name, "shellyuser", 'admin');
2160 if(!$user && $shelly_models{$model}[4]==0 ){https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/36_Shelly.pm?rev=28277#L2158
nicht hinfällig? (shellyuser gilt nur 1st Gen)?
Mein PlusPlugS mit Passwort ist aber für FHEM nicht mehr erreichbar.. HTTP simple auth ist wohl nicht mehr möglich:
ZitatCommunication through HTTP and Websocket channels is secured by a digest authentication mechanism [...]
https://shelly-api-docs.shelly.cloud/gen2/General/Authentication/
Gruß,
Thomas
Genau die Code-Stelle ist mir auch aufgefallen!
Wenn Du aber shelly-user irgendwie auf "" stehen hast, würde das Default nicht greifen.
"Mein" FHEM kann Digest-Auth, das dürfte ein Feature der HttpUtils sein - vielleicht brauchst Du ein Gesamtupdate?
Hier der Mitschnitt zum Shelly PlusPlugS mit PW-Schutz:
15:10:03.853265 IP openwb-2.fritz.box.39590 > shellyplusplugs-e465b8b8004c.fritz.box.http: Flags [P.], seq 1:152, ack 1, win 64240, length 151: HTTP: GET /rpc/Switch.GetStatus?id=0 HTTP/1.0
0x0000: 4500 00bf bbce 4000 4006 fcbb c0a8 0005 E.....@.@.......
0x0010: c0a8 0059 9aa6 0050 f0b1 e278 cc44 7b0d ...Y...P...x.D{.
0x0020: 5018 faf0 8260 0000 4745 5420 2f72 7063 P....`..GET./rpc
0x0030: 2f53 7769 7463 682e 4765 7453 7461 7475 /Switch.GetStatu
0x0040: 733f 6964 3d30 2048 5454 502f 312e 300d s?id=0.HTTP/1.0.
0x0050: 0a48 6f73 743a 2031 3932 2e31 3638 2e30 .Host:.192.168.0
0x0060: 2e38 390d 0a55 7365 722d 4167 656e 743a .89..User-Agent:
0x0070: 2066 6865 6d0d 0a41 6363 6570 742d 456e .fhem..Accept-En
0x0080: 636f 6469 6e67 3a20 677a 6970 2c64 6566 coding:.gzip,def
0x0090: 6c61 7465 0d0a 4175 7468 6f72 697a 6174 late..Authorizat
0x00a0: 696f 6e3a 2042 6173 6963 2059 5752 7461 ion:.Basic.YWRta
0x00b0: 5734 3663 3256 6a63 6d56 300d 0a0d 0a W46c2VjcmV0....
15:10:03.865963 IP shellyplusplugs-e465b8b8004c.fritz.box.http > openwb-2.fritz.box.39590: Flags [P.], seq 1:208, ack 152, win 5609, length 207: HTTP: HTTP/1.0 401 Unauthorized
0x0000: 4500 00f7 0b53 0000 ff06 2dff c0a8 0059 E....S....-....Y
0x0010: c0a8 0005 0050 9aa6 cc44 7b0d f0b1 e30f .....P...D{.....
0x0020: 5018 15e9 d63b 0000 4854 5450 2f31 2e30 P....;..HTTP/1.0
0x0030: 2034 3031 2055 6e61 7574 686f 7269 7a65 .401.Unauthorize
0x0040: 640d 0a57 5757 2d41 7574 6865 6e74 6963 d..WWW-Authentic
0x0050: 6174 653a 2044 6967 6573 7420 716f 703d ate:.Digest.qop=
0x0060: 2261 7574 6822 2c20 7265 616c 6d3d 2273 "auth",.realm="s
0x0070: 6865 6c6c 7970 6c75 7370 6c75 6773 2d65 hellyplusplugs-e
0x0080: 3436 3562 3862 3830 3034 6322 2c20 6e6f 465b8b8004c",.no
0x0090: 6e63 653d 2231 3730 3335 3133 3430 3322 nce="1703513403"
0x00a0: 2c20 616c 676f 7269 7468 6d3d 5348 412d ,.algorithm=SHA-
0x00b0: 3235 360d 0a43 6f6e 7465 6e74 2d4c 656e 256..Content-Len
0x00c0: 6774 683a 2030 0d0a 5365 7276 6572 3a20 gth:.0..Server:.
0x00d0: 5368 656c 6c79 4854 5450 2f31 2e30 2e30 ShellyHTTP/1.0.0
0x00e0: 0d0a 436f 6e6e 6563 7469 6f6e 3a20 636c ..Connection:.cl
0x00f0: 6f73 650d 0a0d 0a ose....
..
15:10:03.873400 IP openwb-2.fritz.box.39592 > shellyplusplugs-e465b8b8004c.fritz.box.http: Flags [P.], seq 1:411, ack 1, win 64240, length 410: HTTP: GET /rpc/Switch.GetStatus?id=0 HTTP/1.0
0x0000: 4500 01c2 3439 4000 4006 834e c0a8 0005 E...49@.@..N....
0x0010: c0a8 0059 9aa8 0050 ba2a 01a3 f34f 5d9c ...Y...P.*...O].
0x0020: 5018 faf0 8363 0000 4745 5420 2f72 7063 P....c..GET./rpc
0x0030: 2f53 7769 7463 682e 4765 7453 7461 7475 /Switch.GetStatu
0x0040: 733f 6964 3d30 2048 5454 502f 312e 300d s?id=0.HTTP/1.0.
0x0050: 0a48 6f73 743a 2031 3932 2e31 3638 2e30 .Host:.192.168.0
0x0060: 2e38 390d 0a55 7365 722d 4167 656e 743a .89..User-Agent:
0x0070: 2066 6865 6d0d 0a41 6363 6570 742d 456e .fhem..Accept-En
0x0080: 636f 6469 6e67 3a20 677a 6970 2c64 6566 coding:.gzip,def
0x0090: 6c61 7465 0d0a 4175 7468 6f72 697a 6174 late..Authorizat
0x00a0: 696f 6e3a 2044 6967 6573 7420 6e6f 6e63 ion:.Digest.nonc
0x00b0: 653d 2231 3730 3335 3133 3430 3322 2c20 e="1703513403",.
0x00c0: 7265 7370 6f6e 7365 3d22 3039 6661 3533 response="09fa53
0x00d0: 3438 6133 3035 3065 6438 6530 6365 6662 48a3050ed8e0cefb
0x00e0: 6335 3561 3464 6635 6461 3739 3838 6131 c55a4df5da7988a1
0x00f0: 3730 3334 3832 6137 6166 3662 6638 3832 703482a7af6bf882
0x0100: 3966 3465 6335 3337 6239 222c 2063 6e6f 9f4ec537b9",.cno
0x0110: 6e63 653d 2263 6333 3865 6236 6538 3930 nce="cc38eb6e890
0x0120: 6634 6133 6133 6331 3938 6436 3032 6663 f4a3a3c198d602fc
0x0130: 6638 3037 6622 2c20 7265 616c 6d3d 2273 f807f",.realm="s
0x0140: 6865 6c6c 7970 6c75 7370 6c75 6773 2d65 hellyplusplugs-e
0x0150: 3436 3562 3862 3830 3034 6322 2c20 616c 465b8b8004c",.al
0x0160: 676f 7269 7468 6d3d 2253 4841 2d32 3536 gorithm="SHA-256
0x0170: 222c 2075 7365 726e 616d 653d 2261 646d ",.username="adm
0x0180: 696e 222c 2071 6f70 3d22 6175 7468 222c in",.qop="auth",
0x0190: 206e 633d 3030 3030 3030 3031 2c20 7572 .nc=00000001,.ur
0x01a0: 693d 222f 7270 632f 5377 6974 6368 2e47 i="/rpc/Switch.G
0x01b0: 6574 5374 6174 7573 3f69 643d 3022 0d0a etStatus?id=0"..
0x01c0: 0d0a ..
15:10:03.903782 IP shellyplusplugs-e465b8b8004c.fritz.box.http > openwb-2.fritz.box.39592: Flags [P.], seq 1:325, ack 411, win 5350, length 324: HTTP: HTTP/1.0 200 OK
0x0000: 4500 016c 0b57 0000 ff06 2d86 c0a8 0059 E..l.W....-....Y
0x0010: c0a8 0005 0050 9aa8 f34f 5d9c ba2a 033d .....P...O]..*.=
0x0020: 5018 14e6 5a61 0000 4854 5450 2f31 2e30 P...Za..HTTP/1.0
0x0030: 2032 3030 204f 4b0d 0a43 6f6e 7465 6e74 .200.OK..Content
0x0040: 2d54 7970 653a 2061 7070 6c69 6361 7469 -Type:.applicati
0x0050: 6f6e 2f6a 736f 6e0d 0a43 6f6e 7465 6e74 on/json..Content
0x0060: 2d4c 656e 6774 683a 2032 3037 0d0a 5365 -Length:.207..Se
0x0070: 7276 6572 3a20 5368 656c 6c79 4854 5450 rver:.ShellyHTTP
0x0080: 2f31 2e30 2e30 0d0a 436f 6e6e 6563 7469 /1.0.0..Connecti
0x0090: 6f6e 3a20 636c 6f73 650d 0a0d 0a7b 2269 on:.close....{"i
0x00a0: 6422 3a30 2c20 2273 6f75 7263 6522 3a22 d":0,."source":"
0x00b0: 5753 5f69 6e22 2c20 226f 7574 7075 7422 WS_in",."output"
0x00c0: 3a66 616c 7365 2c20 2261 706f 7765 7222 :false,."apower"
0x00d0: 3a30 2e30 2c20 2276 6f6c 7461 6765 223a :0.0,."voltage":
0x00e0: 302e 302c 2022 6375 7272 656e 7422 3a30 0.0,."current":0
0x00f0: 2e30 3030 2c20 2261 656e 6572 6779 223a .000,."aenergy":
0x0100: 7b22 746f 7461 6c22 3a30 2e30 3030 2c22 {"total":0.000,"
0x0110: 6279 5f6d 696e 7574 6522 3a5b 302e 3030 by_minute":[0.00
0x0120: 302c 302e 3030 302c 302e 3030 305d 2c22 0,0.000,0.000],"
....
Zitat von: loetmeister am 25 Dezember 2023, 14:59:38Mein PlusPlugS mit Passwort ist aber für FHEM nicht mehr erreichbar.. HTTP simple auth ist wohl nicht mehr möglich:
ZitatCommunication through HTTP and Websocket channels is secured by a digest authentication mechanism [...]
https://shelly-api-docs.shelly.cloud/gen2/General/Authentication/
Bei meinem (neuen) ShellyPlusPlugS hat's mit dem Authentifizieren geklappt wie oben beschrieben, d.h. in der Shelly-WebGUI ein Passwort vergeben, in fhem
attr ShellyPlug shellyuser admin
set ShellyPlug password Mein_PaßwortGrüßle, Michael
Hi,
habs noch mal explizit mit admin als shelly user probiert..... scheint nun zu klappen.
Nur password setzten erzeugte 50 bis 60 mal pro Sekunde die folgenden log Einträge:
2023.12.25 16:07:32 4: [Shelly_status] issue a non-blocking call to http://192.168.6.12/rpc/Switch.GetStatus?id=0, callback to proc2G for comp=relay
2023.12.25 16:07:32 4: [Shelly_status] issue a non-blocking call to http://192.168.6.12/rpc/Switch.GetStatus?id=0, callback to proc2G for comp=relay
2023.12.25 16:07:32 4: [Shelly_status] issue a non-blocking call to http://192.168.6.12/rpc/Switch.GetStatus?id=0, callback to proc2G for comp=relay
2023.12.25 16:07:32 4: [Shelly_status] issue a non-blocking call to http://192.168.6.12/rpc/Switch.GetStatus?id=0, callback to proc2G for comp=relay
Zitat von: Starkstrombastler am 25 Dezember 2023, 12:50:49Es handelt sich hier um einen Taster, der immer nur kurz betätigt wird. Um den Taster im Device zu sehen, muss auf dem Shelly eine Action angelegt werden. Das geht manuell oder automatisiert mittels dem Attribut 'webhook'. Die URL muss z.B. so aussehen:
http://192.168.178.100:8083/fhem?cmd=set%20MyShelly%20button_on
Funktioniert scheinbar nur halb bis gar nicht: Habe zuerst eine Action namens button_on im Shell-WebGUI angelegt und dort "Execute when" auf "Switch toggled on" (gibt kein "toggle" an sich) gesetzt. Funktioniert und erzeugt ein Event in fhem, wenn ich den Taster drücke. Wie erwartet nur beim EINschalten. Also eine zweite Aktion ähnlicher Art mit "Switch toggled off" angelegt. Danach kommen keine Events mehr in fhem an.
Es gibt das Reading button im Device ShellyPlug. Und dessen Wert kann ich aus der Linux-Shell über
echo "set ShellyPlug button_on" | nc -w1 imurr9.fritz.box 7072
echo "set ShellyPlug button_off" | nc -w1 imurr9.fritz.box 7072
steuern. Aber dadurch ändert sich NICHT der on/off-Zustand des Device ShellyPlug. Funktioniert aber aus dem ShellyPlusPlugS heraus aber nur "manchmal" bis selten.
Habe auch mal webhook mit "WEB" probiert. Mir ist da aber nicht klar, wo ich in fhem dann die URL für den Shelly hinterlegen könnte. Diese Meldungen gibt's dann im Log:
2023.12.25 15:54:24 3: [Shelly_Attr:webhook] ShellyPlug command is set, attribute webhook old: NoVal new: WEB
2023.12.25 15:54:24 3: [Shelly_Attr:webhook] the webhook attribute is now WEB, create webhooks
2023.12.25 15:54:24 3: [Shelly_Attr:webhook] we will call Shelly_webhook for device ShellyPlug, command is Create
2023.12.25 15:54:27 1: [Shelly_actionWebhook] calling url-builder with args: ShellyPlug relay ch:0 noe:0
2023.12.25 15:54:27 1: [Shelly_actionWebhook] ShellyPlug: &urls=["http://192.168.178.49:8083/fhem?cmd=set%2520ShellyPlug%2520out_on%25200%26fwcsrf=csrf_509181295696804"]
2023.12.25 15:54:27 1: [Shelly_webhook] ShellyPlug Create component=relay count=0 event=0
2023.12.25 15:54:27 1: [Shelly_webhook] issue a non-blocking call to
http://admin:ShUg#o42lo@192.168.178.44/rpc/Webhook.Create?cid=0&name=%22_SWITCH.ON_%22&event=%22switch.on%22&enable=true&urls=["http://192.168.178.49:8083/fhem?cmd=set%2520ShellyPlug%2520out_on%25200%26fwcsrf=csrf_509181295696804"]
2023.12.25 15:54:27 1: [Shelly_actionWebhook] calling url-builder with args: ShellyPlug relay ch:0 noe:1
2023.12.25 15:54:27 1: [Shelly_actionWebhook] ShellyPlug: &urls=["http://192.168.178.49:8083/fhem?cmd=set%2520ShellyPlug%2520out_off%25200%26fwcsrf=csrf_509181295696804"]
2023.12.25 15:54:27 1: [Shelly_webhook] ShellyPlug Create component=relay count=0 event=1
2023.12.25 15:54:27 1: [Shelly_webhook] issue a non-blocking call to
http://admin:ShUg#o42lo@192.168.178.44/rpc/Webhook.Create?cid=0&name=%22_SWITCH.OFF_%22&event=%22switch.off%22&enable=true&urls=["http://192.168.178.49:8083/fhem?cmd=set%2520ShellyPlug%2520out_off%25200%26fwcsrf=csrf_509181295696804"]
2023.12.25 15:54:27 3: [Shelly_webhook] ShellyPlug: Error: Reading 'input.*mode' not found
2023.12.25 16:03:05 3: [Shelly_Attr:webhook] ShellyPlug command is set, attribute webhook old: WEB new: none
2023.12.25 16:03:05 3: [Shelly_Attr:webhook] delete all hooks forwarding to this host and name starts with _
2023.12.25 16:03:05 3: [Shelly_Attr:webhook] we will call Shelly_webhook for device ShellyPlug, command is Delete
2023.12.25 16:04:20 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at ./FHEM/36_Shelly.pm line 1706.
2023.12.25 16:21:34 3: [Shelly_Attr:webhook] ShellyPlug command is set, attribute webhook old: none new: WEB
2023.12.25 16:21:34 3: [Shelly_Attr:webhook] the webhook attribute is now WEB, create webhooks
2023.12.25 16:21:34 3: [Shelly_Attr:webhook] we will call Shelly_webhook for device ShellyPlug, command is Create
2023.12.25 16:21:37 1: [Shelly_actionWebhook] calling url-builder with args: ShellyPlug relay ch:0 noe:0
2023.12.25 16:21:37 1: [Shelly_actionWebhook] ShellyPlug: &urls=["http://192.168.178.49:8083/fhem?cmd=set%2520ShellyPlug%2520out_on%25200%26fwcsrf=csrf_509181295696804"]
2023.12.25 16:21:37 1: [Shelly_webhook] ShellyPlug Create component=relay count=0 event=0
2023.12.25 16:21:37 1: [Shelly_webhook] issue a non-blocking call to
http://admin:ShUg#o42lo@192.168.178.44/rpc/Webhook.Create?cid=0&name=%22_SWITCH.ON_%22&event=%22switch.on%22&enable=true&urls=["http://192.168.178.49:8083/fhem?cmd=set%2520ShellyPlug%2520out_on%25200%26fwcsrf=csrf_509181295696804"]
2023.12.25 16:21:37 1: [Shelly_actionWebhook] calling url-builder with args: ShellyPlug relay ch:0 noe:1
2023.12.25 16:21:37 1: [Shelly_actionWebhook] ShellyPlug: &urls=["http://192.168.178.49:8083/fhem?cmd=set%2520ShellyPlug%2520out_off%25200%26fwcsrf=csrf_509181295696804"]
2023.12.25 16:21:37 1: [Shelly_webhook] ShellyPlug Create component=relay count=0 event=1
2023.12.25 16:21:37 1: [Shelly_webhook] issue a non-blocking call to
http://admin:ShUg#o42lo@192.168.178.44/rpc/Webhook.Create?cid=0&name=%22_SWITCH.OFF_%22&event=%22switch.off%22&enable=true&urls=["http://192.168.178.49:8083/fhem?cmd=set%2520ShellyPlug%2520out_off%25200%26fwcsrf=csrf_509181295696804"]
2023.12.25 16:21:37 3: [Shelly_webhook] ShellyPlug: Error: Reading 'input.*mode' not found
2023.12.25 16:22:08 3: [Shelly_Attr:webhook] ShellyPlug: delete all hooks forwarding to this host and name starts with _
2023.12.25 16:22:08 3: [Shelly_Attr:webhook] we will call Shelly_webhook for device ShellyPlug, command is Delete
Grüßle, Michael
Zitat von: loetmeister am 25 Dezember 2023, 16:31:00Hi,
habs noch mal explizit mit admin als shelly user probiert..... scheint nun zu klappen.
...
Jetzt kapiere ich auch den Knieschuss: Beim Setzen des Passwortes war eigentlich der Schutz implementiert: "Wenn kein 'shelly-user' gesetzt, dann moppern'. Der wird an der Codestelle, die Du zitiertest, aber durch das Default "admin" ausgehebelt. Da, wo die Credentials zur Verwendung abgerufen werden, nämlich in Shelly_pwd, dort ist das Default ein Leerstring. :-)
Zitat von: Starkstrombastler am 25 Dezember 2023, 12:50:49Das geht derzeit nur so wie hier (https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Switch#switchresetcounters-example) beschrieben.
Danke für den Hinweis. Nach etwas Suchen bzgl. Authentifizieren klappt bei mir das Rücksetzen des energy-Counters durch
curl --anyauth -u admin:Mein_Paßwort_hier -X POST -d '{"id":1,"method":"Switch.ResetCounters","params":{"id":0,"type":["aenergy"]}}' http://IP_des_Plugs/rpcGrüßle, Michael
Zitat von: olwaldi am 25 Dezember 2023, 16:38:11Zitat von: Starkstrombastler am 25 Dezember 2023, 12:50:49Es handelt sich hier um einen Taster, der immer nur kurz betätigt wird. Um den Taster im Device zu sehen, muss auf dem Shelly eine Action angelegt werden. Das geht manuell oder automatisiert mittels dem Attribut 'webhook'. Die URL muss z.B. so aussehen:
http://192.168.178.100:8083/fhem?cmd=set%20MyShelly%20button_on
Bin etwas weiter - die Actions brauchen via HTTP "doppelte" Authentifizierung. Habe aber keine Idee, wie ich das in einer Action des ShellyPlusPlugS hinterlegen könnte. Aus der Shell heraus funktioniert z.B.
curl -v "http://fhem-user:fhem-Paßwort@fhem-Server:8083/fhem?cmd=set%20ShellyPlug%20button_on&fwcsrf=csrf_token"
Das Paßwort muß URL-codiert sein (habe Sonderzeichen drin). Leider funktioniert das so nicht in einer ShellyPlug-Action, da sich ja das csrf_token ändern kann. Selbst beim Testen in dieser Syntax kommt nix in fhem an.
Grüßle, Michael
Bzgl. csrf-Token: extra FhemWeb für Shelly-Hook und dort ein fixes csrf-Token setzen...
Evtl. auch dafür "einfachere" Passwörter aber zusätzlich Befehle einschränken und nur die IP(s) des/der Shelly zulassen...
Sollte ähnlich sicher sein...
Gruß, Joachim
P.S.: User/Passwort ohne https?
Zitat von: MadMax-FHEM am 26 Dezember 2023, 09:50:25P.S.: User/Passwort ohne https?
(Leider) yep. Alle Web-Server auf meinem Raspi sind "nur" http. Halte das aber für sicher genug, da mein Raspi nur im privaten Intranet erreichbar ist. Lasse mich aber gern eines Besseren belehren. Überhaupt bin ich eher unglücklich bzgl. Sicherheit meiner fhem-Installation - überall muß ich Klartext-Paßwörter hinterlegen, damit Aktivitäten automatisiert laufen (z. B. emails aus fhem heraus). Ist aber hier komplett OT.
Dann werde ich mal ein zusätzliches FHEMWEB anlegen und dann via webhook nutzen...
Grüßle, Michael
Irgendwie mag mein ShellyPlusPlugS das Drücken des Knopfs nicht richtig an fhem weiterzuleiten. Im Log sehe ich hie und da
2023.12.27 08:35:16 1: [Shelly_Set] parsed, outstanding call for device ShellyPlug with command 'buttton_off', no parametersIch habe dazu das FHEMWEB Device FHEMapi mit festem csrftoken angelegt und kann das auch via Shell nutzen, um das Reading button zwischen on bzw. off hin- und herzuschalten. Aber die Action button_off funktioniert vom ShellyPlug aus nicht.
define WEBapi FHEMWEB 8088 global
attr WEBapi csrfToken csrf_4711allowedfrom habe ich bewußt nicht gesetzt, da alle meine lokalen IPs Zugang haben sollen (was ja für mich der richtige default ist).
Das funktionierende curl-Kommando sieht so aus:
curl -v "http://imurr9.fritz.box:8088/fhem?cmd=set%20ShellyPlug%20button_off&fwcsrf=csrf_4711"
BTW - wichtig sind die Anführungszeichen, damit das & wie gewünscht tut.
Könnte das dann vielleicht ein Bug in der Shelly-Software sein? Ist ja auch eigentlich merkwürdig, daß der Button in der Shelly-WebGUI zwischen "Switch toggeled on" und "Switch toggled off" unterscheidet.
Grüßle, Michael
PS: Das neue WEBapi werde ich dann auch nutzen, um das in fhem "offene" telnet loszuwerden.
Immer wieder lustig zu sehen, dass man die Schuld in Bugs der "Shelly-Software" sucht...
Ich schlage stattdessen vor, in
Zitatbuttton_off
mal die 't'-Zeichen zu zählen.
LG
pah
Das ist ja peinlich^3. Danke für's Korrekturlesen. In letzter Zeit passiert mir das häufiger, das Mehrfach-Zeichen "dazwischengekommen". In guter Tradition würde ich das ja der Tastatur vorwerfen, aber vielleicht bin ich auch einfach nur älter geworden.
Ich halte mich selber für einen guten Korrekturleser, aber das ttt habe ich einfach nicht gesehen.
Vielen Dank, Michael
Zitat von: loetmeister am 25 Dezember 2023, 16:31:00habs noch mal explizit mit admin als shelly user probiert..... scheint nun zu klappen.
Bei den Gen2-Devices lautet der Shellyuser per default 'admin'. Mit dem nächsten Update wird dies berücksichtigt - das Anlegen eines Attributes 'shellyuser' ist dann für Gen2-Devices obsolet, falls vorhanden wird es ignoriert.
Mit dem nächsten Update wird es auch einen Reset-Befehl zum Zurücksetzen von Zählwerten geben:
set <name> reset disconnects zum Zurücksetzen des Readings network_disconnects
set <name> reset energy zum Zurücksetzen der energy-Readings (nur bei Gen2-Devices)
Bug Fix: Bei den Gen2-Devices im Roller-Mode sind die Metering-Readings (energy, power, current, ..) singulär, d.h. es gibt im Gegensatz zum Relay-Mode jeweils nur ein Reading. Die Namen dieser Readings enthalten künftig keinen Index.
Hallo Starkstrombastler,
'habe gestern einen Shelly Plus Plug S in Betrieb genommen.
Allerdings hat das nicht auf Anhieb funktioniert, da ich das Attribut model mit ,,shellyplug" nicht korrekt gesetzt hatte.
Ich habe mir dann den Quelltext des Modul angesehen und das Modell ,,shellyplusplug" gefunden, mit dem es dann funktionierte.
Kannst Du beim nächsten Update das Model ,,shellyplusplug" im HTML-Teil für die Commandref ergänzen, damit es schneller auffindbar ist oder willst Du das Modell evtl. noch nicht offiziell bekanntmachen, da noch daran gearbeitet wird?
Ansonsten danke für Deine Arbeit am Modul.
Grüße
Xaneu
Zitat von: Starkstrombastler am 30 Dezember 2023, 19:17:40Mit dem nächsten Update wird es auch einen Reset-Befehl zum Zurücksetzen von Zählwerten geben:
set <name> reset disconnects zum Zurücksetzen des Readings network_disconnects
set <name> reset energy zum Zurücksetzen der energy-Readings (nur bei Gen2-Devices)
Funktioniert prima, die energy zurückzusetzen bei meinem ShellyPlusPlugS. Aber irgendwie scheine ich mich verklickt zu haben. Seither steht config auf "counter set to 0", hat aber keinen Effekt (da Gen2). Könnte es sein, daß das eigentlich eine Message-Box hätte sein sollen?
Danke & guten Rutsch, Michael
Zitat von: olwaldi am 31 Dezember 2023, 13:31:15Seither steht config auf "counter set to 0", hat aber keinen Effekt (da Gen2). Könnte es sein, daß das eigentlich eine Message-Box hätte sein sollen?
Ja, das stimmt. Das Reading 'config' wird ja benutzt, um Ergebnisse einer Anfrage via set ... config ... darzustellen, ist also im gewissen Sinne eine Message-Box.
Irgenwie haben sich die energy-Readings beim Reset nicht aktualisiert (erst nach Browser Refresh). Wenn das gefixt ist, brauchen wir diese "Message" nicht mehr.
Zitat von: Xaneu am 31 Dezember 2023, 08:15:13'habe gestern einen Shelly Plus Plug S in Betrieb genommen.
Allerdings hat das nicht auf Anhieb funktioniert, da ich das Attribut model mit ,,shellyplug" nicht korrekt gesetzt hatte.
Ich habe mir dann den Quelltext des Modul angesehen und das Modell ,,shellyplusplug" gefunden, mit dem es dann funktionierte.
Ganz zu Beginn der Commandref steht:
Das Attribut model wird automatisch gesetzt. Zitat von: Xaneu am 31 Dezember 2023, 08:15:13Kannst Du beim nächsten Update das Model im HTML-Teil für die Commandref ergänzen, damit es schneller auffindbar ist oder willst Du das Modell evtl. noch nicht offiziell bekanntmachen, da noch daran gearbeitet wird?
Irgendwie scheint dein System nicht up-to-date zu sein. Das Modul ist seit etlichen Wochen (wieder) regulär verfügbar.
Die Liste der
model in der Commandref zu
attr ... model werde ich herausnehmen, da an dieser Stelle ohnehin nur per Dropdown auswählbar. Und wenn das automatische Ermitteln nicht funktioniert hat, werden alle verfügbaren
model im Dropdown angeboten.
Zitat von: Starkstrombastler am 31 Dezember 2023, 15:44:28Ganz zu Beginn der Commandref steht:
Das Attribut model wird automatisch gesetzt.
Da könnte ich beisteueren, daß das bei meinem ShellyPlusPlugS automatisch geklappt hat.
Frohes neues Jahr 2024, Michael
Hallo Starkstrombastler,
hallo olwaldi,
alles klar und danke für Eure Antworten.
Servus, Guten Abend und noch ein gesundes 24 gewünscht.
Ich hätt da mal a Fräch...
Gerade habe ich ein Shelly 1 Mini in Betrieb genommen und muss feststellen, dass ich fortwährend "STATE Error: JSON" erhalte. Nun frage ich mich, liegt das etwa am nicht per "model" wählbaren "shelly1mini plus"?
Via Browser ist es kein Thema, IP in die Adresszeile und ich bin beim shelly.
Wo mir auch die Frage2 kommt, jetzt da shelly die Autentifizierung nur noch mit Passwort machen und ohne Benutzername, gibt es in fhem 36_shelly.pm dennoch einen zu wählenden Benutzernamen?
JA, FHEM ist aktuell.
JA, Shelly FW ist aktuell,
JA, ich habe den shelly neu gebootet.
Hilft alles nix. Hoffentlich weiß einer Rat. Danke
INTERNALS
DEF 192.168.xxx.137
FUUID 6595ad60-f33f-88bc-cxxx-e74dab827bcfad79
INTERVAL 60
NAME Shelly017
NR 158
STATE Error: JSON
TCPIP 192.168.xxx.137
TYPE Shelly
units 0
READINGS
cloud disabled 2024-01-03 19:54:54
firmware v1.1.0 2024-01-03 19:54:54
input off 2024-01-03 19:54:54
input_mode switch straight follow 2024-01-03 19:54:54
inttemp 46 2024-01-03 19:54:46
name 01_VBad_Deckenlicht_Shelly017 2024-01-03 20:10:54
network invalid JSON data 2024-01-03 20:20:05
network_disconnects 7 2024-01-03 20:20:05
network_rssi -61 2024-01-03 19:54:54
network_ssid Xuxxyxxnk 2024-01-03 19:54:54
network_threshold -80 2024-01-03 19:54:54
source switch 2024-01-03 19:54:46
state Error: JSON 2024-01-03 20:20:05
webhook_cnt 0 2024-01-03 19:54:33
webhook_ver 0 2024-01-03 19:54:33
Zitat von: Pulsgeber am 03 Januar 2024, 21:06:00Gerade habe ich ein Shelly 1 Mini in Betrieb genommen und muss feststellen, dass ich fortwährend "STATE Error: JSON" erhalte. Nun frage ich mich, liegt das etwa am nicht per "model" wählbaren "shelly1mini plus"?
Dein Posting enthält leider keine Attribute. Wie lautet denn das beim Define vom Modul automatisch angelegte Attribut
model ?
Hierzu das Define wiederholen oder
get Shelly017 model aufrufen.
Außerdem vermisse ich das Internal
SHELLYID.
Wie lautet denn die Antwort vom Shelly, wenn du im Browser
<ip_vom_Shelly>/rpc/Shelly.GetDeviceInfo aufrufst?
Zitat von: Pulsgeber am 03 Januar 2024, 21:06:00Wo mir auch die Frage2 kommt, jetzt da shelly die Autentifizierung nur noch mit Passwort machen und ohne Benutzername, gibt es in fhem 36_shelly.pm dennoch einen zu wählenden Benutzernamen?
Ist so nicht ganz richtig. Authenfizierung erfolgt immer noch mit Benutzername und Passwort. Aber: der Benutzername ist bei Shelly Gen2 immer
admin und deshalb wird hier das Attribut
shellyuser nicht angeboten.
Ich habe den Eindruck, dass seit den letzten Updates shellydimmer nicht mehr funktionieren.
Das betrifft das ein / ausschalten und die Änderung der Helligkeit.
Schalte ich den zum Beispiel aus, kommt zum Beispiel folgendes ins log (bei verbose 5)
Zitat2024.01.07 19:02:28 5: [Shelly_Set] FhemWeb is requesting set-commands for device Bel.eg.wz.wand
2024.01.07 19:02:27 5: [Shelly_Get] Bel.eg.wz.wand: unknown argument ?, choose one of status:noArg shelly_status:noArg registers:noArg config version:noArg model:noArg
2024.01.07 19:02:27 5: [Shelly_Set] FhemWeb is requesting set-commands for device Bel.eg.wz.wand
2024.01.07 19:02:27 5: [Shelly_Set] FhemWeb is requesting set-commands for device Bel.eg.wz.wand
2024.01.07 19:02:27 5: [Shelly_Set] FhemWeb is requesting set-commands for device Bel.eg.wz.wand
2024.01.07 19:02:26 5: [Shelly_Set] FhemWeb is requesting set-commands for device Bel.eg.wz.wand
2024.01.07 19:02:26 4: [Shelly_Set] switching channel 0 for device Bel.eg.wz.wand with command off, FF=2
2024.01.07 19:02:26 4: [Shelly_Set] Bel.eg.wz.wand precheck: channel is undefined
2024.01.07 19:02:26 4: [Shelly_Set] calling for device Bel.eg.wz.wand with command 'off', no parameters
Hat jemand eine Idee?
Viele Grüße
Guido Fett
Zitat von: fettgu am 07 Januar 2024, 19:06:06Ich habe den Eindruck, dass seit den letzten Updates shellydimmer nicht mehr funktionieren.
Dein Eindruck ist zutreffend, wenngleich das nicht aus dem geposteten Log hervorgeht. Die mehrfachen Logeinträge "FhemWeb is requesting.." kommen, weil im Browser etliche Fenster mit diesem Device offen sind.
Wie auch immer, das Fehlverhalten sollte mit dem morgigen Update behoben sein.
ZitatWie auch immer, das Fehlverhalten sollte mit dem morgigen Update behoben sein.
Prima. Danke - ich komme allerdings erst Ende der Woche dazu, dass zu testen.
Viele Grüße
Guido Fett
Guten Morgen,
ich steuere meine Rollläden über shelly2.5 und habe jetzt alles von "set pct" auf "set pos" umgestellt.
Da ich die Rollläden auch über Alexa steuere, erhalte ich im Log noch Meldungen wie diese
[Shelly_Set] E5_dt_RS_Fenster: use of 'set ... pct' is deprecated, use 'set ... pos' instead
Im Device ist genericDeviceType auf "blind" eingestellt und für diesen Typ ist folgendes im Alex Mapping hinterlegt:
blind blind CurrentPosition/TargetPosition
Wenn das Device einen set-Befehl position hat, wird gemappt
CurrentPosition => reading=position, TargetPosition => reading=position, cmd=position
Wenn TYPE=DUOFERN, werden die Datenwerte für CurrentPosition und TargetPosition invertiert.
Wenn TYPE=SOMFY, werden die Datenwerte für CurrentPosition und TargetPosition invertiert, und das Kommando zum Setzen wird auf cmd=pos geändert.
Ansonsten wird gemappt
CurrentPosition => reading=pct, TargetPosition => reading=pct, cmd=pct
Wenn ein Attribut levelInverse gesetzt ist, werden die Datenwerte für CurrentPosition und TargetPosition invertiert.
siehe https://wiki.fhem.de/wiki/Alexa_und_Mappings#genericDeviceType (https://wiki.fhem.de/wiki/Alexa_und_Mappings#genericDeviceType)
Im Shelly Modul gibt es aber nur "set pos" und kein "set position", so dass dann pct benutzt wird. Bevor ich mich jetzt aber in "homebridgemappings" einarbeite, wollte ich fragen, ob das schon jemand gelöst hat und mir das Mapping zur Verfügung stellen kann? Um im Standard zu bleiben wäre natürlich auch ein "set position" sehr schön.
Viele Grüße
Torsten
Hallo,
ich habe Probleme mit meinen Shellys (2.5).
Bei jedem Schaltversuch steht invalid json data.
Internals:
CFGFN ./shelly.cfg
DEF 192.168.1.67
FUUID 65226048-f33f-f494-15d4-e74c1c771d057092
INTERVAL 5
NAME HeizpumpeEG
NR 1152
STATE Status: on Leistung: 40.89 W Watt
TCPIP 192.168.1.67
TYPE Shelly
eventCount 198
units 1
OLDREADINGS:
READINGS:
2023-10-07 15:18:38 cloud disabled
2023-11-16 17:59:54 coiot enabled
2023-11-16 17:59:54 coiot_period 15 sec
2024-01-09 14:24:02 config mode=relay [channel s]
2024-01-09 14:35:03 energy_0 0.002700 kWh
2024-01-09 14:24:06 energy_1 0.0 kWh
2024-01-09 14:35:03 energy_TTL 0.002700 kWh
2024-01-09 14:30:54 firmware v1.14.1-rc1(update needed to v1.14.0)
2023-12-26 05:09:38 input_0 off
2023-12-26 05:09:38 input_1 off
2024-01-09 14:35:44 inttemp 68.98 °C
2023-12-26 05:09:38 inttempStatus Normal
2024-01-09 14:29:50 network <html>connected to <a href="http://192.168.1.67">192.168.1.67</a></html>
2024-01-09 14:29:46 network_disconnects 55
2024-01-09 14:35:44 network_rssi -67 dBm (fair)
2023-12-26 05:09:38 network_ssid Luftpumpe
2023-11-16 18:38:20 network_threshold -70 dBm
2024-01-09 14:24:06 overpower_0 0 W
2024-01-09 14:24:06 overpower_1 0 W
2024-01-09 14:35:44 power_0 40.89 W
2024-01-09 14:24:06 power_1 0 W
2024-01-09 13:50:58 relay_0 on
2023-12-19 12:35:33 relay_1 off
2024-01-09 13:50:58 source_0 input
2023-12-19 12:35:33 source_1 input
2024-01-09 14:34:03 state OK
2024-01-09 08:26:38 timer_0 0 sec
2023-12-29 22:54:44 timer_1 0 sec
2023-12-22 09:13:32 webhook_cnt 0
2023-12-22 09:13:32 webhook_ver 0
helper:
Sets config interval password reboot:noArg update:noArg name reset:disconnects on off toggle on-for-timer off-for-timer ON:noArg OFF:noArg xtrachannels:noArg
Attributes:
ShellyName HeizpumpeEG
defchannel 0
group Heizung
interval 5
mode relay
model shelly2.5
room 000.Status,109.EG_Wohnraum,999.System,990.Heizung
showunits normal2
stateFormat Status: relay_0 Leistung: power_0 Watt
verbose 0
webCmd on:off
2024.01.09 14:51:06 5: [Shelly_status] device HeizpumpeUG of model shelly2.5 has returned data
{"wifi_sta":{"connected":true,"ssid":"Luftpumpe","ip":"192.168.1.116","rssi":-67},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"14:51","unixtime":1704808266,"serial":1,"has_update":true,"mac":"E09806954388","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"input"},{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"input"}],"meters":[{"power":7.93,"overpower":0.00,"is_valid":true,"timestamp":1704811866,"counters":[8.027, 8.005, 8.008],"total":103},{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1704811866,"counters":[0.000, 0.000, 0.000],"total":0}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"temperature":67.10,"overtemperature":false,"tmp":{"tC":67.10,"tF":152.77, "is_valid":true},"temperature_status":"Normal","update":{"status":"pending","has_update":true,"new_version":"20230913-112234/v1.14.0-gcb84623","old_version":"20231107-163214/v1.14.1-rc1-g0617c15","beta_version":"20231107-163214/v1.14.1-rc1-g0617c15"},"ram_total":50728,"ram_free":37272,"fs_size":233681,"fs_free":146584,"voltage":233.52,"uptime":808}
2024.01.09 14:51:06 5: [Shelly_rssi] returns -67 dBm (fair) to device HeizpumpeUG
2024.01.09 14:51:06 4: [Shelly_proc1G] HeizpumpeUG: Looking for metering values
2024.01.09 14:51:06 5: [Shelly_proc1G] HeizpumpeUG _0: power=7.93 TTL=7.93, energy=0.001700 kWh TTL=103
2024.01.09 14:51:06 5: [Shelly_proc1G] HeizpumpeUG _1: power=0 TTL=7.93, energy=0.0 kWh TTL=103
2024.01.09 14:51:06 5: [Shelly_proc1G] HeizpumpeUG has input 0 with state "off"
2024.01.09 14:51:06 5: [Shelly_proc1G] HeizpumpeUG has input 1 with state "off"
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:06 4: [Shelly_status] HeizpumpeUG: proc1G returned with value=5
2024.01.09 14:51:06 4: [Shelly_status] HeizpumpeUG: next update in 5 seconds
2024.01.09 14:51:06 4: [Shelly_Set] calling for device HeizpumpeUG with command 'off', no parameters
2024.01.09 14:51:06 4: [Shelly_Set] HeizpumpeUG precheck: channel is 0
2024.01.09 14:51:06 4: [Shelly_Set] switching channel 0 for device HeizpumpeUG with command ?turn=off, FF=0
2024.01.09 14:51:06 4: [Shelly_onoff] issue a non-blocking call to http://192.168.1.116/relay/0?turn=?turn=off; callback to Shelly_onoff with command /relay/0?turn=?turn=off
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:06 5: [Shelly_onoff:callback] device HeizpumpeUG has returned data
Bad turn!
2024.01.09 14:51:06 1: [Shelly_onoff] Device HeizpumpeUG has Error 'invalid JSON data', state is set to 'Error: JSON'
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:06 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:11 4: [Shelly_status(1G)] issue a non-blocking call to http://192.168.1.116/status
2024.01.09 14:51:11 5: [Shelly_status] device HeizpumpeUG of model shelly2.5 has returned data
{"wifi_sta":{"connected":true,"ssid":"Luftpumpe","ip":"192.168.1.116","rssi":-68},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"14:51","unixtime":1704808271,"serial":1,"has_update":true,"mac":"E09806954388","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"input"},{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"input"}],"meters":[{"power":7.90,"overpower":0.00,"is_valid":true,"timestamp":1704811871,"counters":[8.027, 8.005, 8.008],"total":103},{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1704811871,"counters":[0.000, 0.000, 0.000],"total":0}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"temperature":67.10,"overtemperature":false,"tmp":{"tC":67.10,"tF":152.77, "is_valid":true},"temperature_status":"Normal","update":{"status":"pending","has_update":true,"new_version":"20230913-112234/v1.14.0-gcb84623","old_version":"20231107-163214/v1.14.1-rc1-g0617c15","beta_version":"20231107-163214/v1.14.1-rc1-g0617c15"},"ram_total":50728,"ram_free":36940,"fs_size":233681,"fs_free":146584,"voltage":233.52,"uptime":813}
2024.01.09 14:51:11 5: [Shelly_rssi] returns -68 dBm (fair) to device HeizpumpeUG
2024.01.09 14:51:11 4: [Shelly_proc1G] HeizpumpeUG: Looking for metering values
2024.01.09 14:51:11 5: [Shelly_proc1G] HeizpumpeUG _0: power=7.9 TTL=7.9, energy=0.001700 kWh TTL=103
2024.01.09 14:51:11 5: [Shelly_proc1G] HeizpumpeUG _1: power=0 TTL=7.9, energy=0.0 kWh TTL=103
2024.01.09 14:51:11 5: [Shelly_proc1G] HeizpumpeUG has input 0 with state "off"
2024.01.09 14:51:11 5: [Shelly_proc1G] HeizpumpeUG has input 1 with state "off"
2024.01.09 14:51:11 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:11 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:11 5: [Shelly_Set] FhemWeb is requesting set-commands for device HeizpumpeUG
2024.01.09 14:51:11 4: [Shelly_status] HeizpumpeUG: proc1G returned with value=5
2024.01.09 14:51:11 4: [Shelly_status] HeizpumpeUG: next update in 5 seconds
Zitat von: AbeamStart am 09 Januar 2024, 14:36:09Hallo,
ich habe Probleme mit meinen Shellys (2.5).
Bei jedem Schaltversuch steht invalid json data.
Hallo,
ist bei mir auch so.
Grüße Jörg
Aktuelles Shelly Modul
Version die bei meinen 25ern als Relays Probleme macht:
# FHEM module to communicate with Shelly switch/roller actor devices
# Prof. Dr. Peter A. Henning, 2022 (v. 4.02f, 3.9.2022)
# $Id: 36_Shelly.pm 28360 2024-01-08 20:52:08Z Starkstrombastler $
Alte Version bei der es läuft:
# FHEM module to communicate with Shelly switch/roller actor devices
# Prof. Dr. Peter A. Henning, 2022 (v. 4.02f, 3.9.2022)
# $Id: 36_Shelly.pm 28277 2023-12-14 21:47:09Z Starkstrombastler $
Zitat von: AbeamStart am 09 Januar 2024, 14:36:09Bei jedem Schaltversuch steht invalid json data.
da ist mit dem heutigen Upddate leider ein kleiner (aber entscheidender) Fehler reingerutscht.
Wer es selbst schnell fixen möchte, kommentiert in 36_Shelly.pm die Zeilen 1995 und 1996 aus. Das sieht dann so aus:
1993 if( $ff==0 ){
1994 if( $shelly_models{$model}[4]<2 ){
1995 # $cmd = "?turn=$cmd" ##"/relay/$channel?turn=$cmd";
1996 # if( $cmd !~ "brightness" );Die Datei dann mit
reload 36_Shelly.pmneu einbinden. Restart sollte nicht erforderlich sein.
Fehler ist im morgigen Update gefixt.
LG
Starkstrombastler
Zitat von: Starkstrombastler am 09 Januar 2024, 20:30:52Zitat von: AbeamStart am 09 Januar 2024, 14:36:09Bei jedem Schaltversuch steht invalid json data.
da ist mit dem heutigen Upddate leider ein kleiner (aber entscheidender) Fehler reingerutscht.
Wer es selbst schnell fixen möchte, kommentiert in 36_Shelly.pm die Zeilen 1995 und 1996 aus. Das sieht dann so aus:
1993 if( $ff==0 ){
1994 if( $shelly_models{$model}[4]<2 ){
1995 # $cmd = "?turn=$cmd" ##"/relay/$channel?turn=$cmd";
1996 # if( $cmd !~ "brightness" );Die Datei dann mit
reload 36_Shelly.pmneu einbinden. Restart sollte nicht erforderlich sein.
Fehler ist im morgigen Update gefixt.
LG
Starkstrombastler
Erfolgreich getestet mit Shelly25 als Relays. Danke für den schnellen Fix.
nach dem heutigen Update sieht zwar die Fehlermeldung anders aus:
[Shelly_Set] E5_dt_RS_Fenster: use of 'set ... pct' is deprecated, use 'set ... pos[ition]' instead
aber ein set position sehe ich noch nicht im Device.
Zitat von: ToKa am 09 Januar 2024, 09:44:47Guten Morgen,
ich steuere meine Rollläden über shelly2.5 und habe jetzt alles von "set pct" auf "set pos" umgestellt.
Da ich die Rollläden auch über Alexa steuere, erhalte ich im Log noch Meldungen wie diese
[Shelly_Set] E5_dt_RS_Fenster: use of 'set ... pct' is deprecated, use 'set ... pos' instead
Im Device ist genericDeviceType auf "blind" eingestellt und für diesen Typ ist folgendes im Alex Mapping hinterlegt:
blind blind CurrentPosition/TargetPosition
Wenn das Device einen set-Befehl position hat, wird gemappt
CurrentPosition => reading=position, TargetPosition => reading=position, cmd=position
Wenn TYPE=DUOFERN, werden die Datenwerte für CurrentPosition und TargetPosition invertiert.
Wenn TYPE=SOMFY, werden die Datenwerte für CurrentPosition und TargetPosition invertiert, und das Kommando zum Setzen wird auf cmd=pos geändert.
Ansonsten wird gemappt
CurrentPosition => reading=pct, TargetPosition => reading=pct, cmd=pct
Wenn ein Attribut levelInverse gesetzt ist, werden die Datenwerte für CurrentPosition und TargetPosition invertiert.
siehe https://wiki.fhem.de/wiki/Alexa_und_Mappings#genericDeviceType (https://wiki.fhem.de/wiki/Alexa_und_Mappings#genericDeviceType)
Im Shelly Modul gibt es aber nur "set pos" und kein "set position", so dass dann pct benutzt wird. Bevor ich mich jetzt aber in "homebridgemappings" einarbeite, wollte ich fragen, ob das schon jemand gelöst hat und mir das Mapping zur Verfügung stellen kann? Um im Standard zu bleiben wäre natürlich auch ein "set position" sehr schön.
Viele Grüße
Torsten
Zitat von: ToKa am 09 Januar 2024, 09:44:47Im Shelly Modul gibt es aber nur "set pos" und kein "set position", so dass dann pct benutzt wird.
Das ist im Moment auch noch so unverändert vorhanden. Das aktuelle Update korrigierte nur den Bug mit den on/off-Befehlen.
Für die Verwendung mit Alexa wäre es tatsächlich besser, die Steuerung auf
set ... position zu ändern und im Reading position nur die Prozentwerte auszugeben (ohne
closed und
open für die Endlagen).
Daher folgende Vorgehensweise:
1.) vorübergehend werden vom Modul set-Befehle gleichwertig behandelt:
set ... pct|pos|position ...2.) in der Fhem-Oberfläche wird der set-Befehl auf
set ... position geändert; eine evtl. vorhandene Verwendung in webCmd muss vom User angepasst werden
3.) Die Meldung "deprecated" im Log wird auf 'use set ... position instead' geändert
4.) Im Reading position werden die Werte closed und open durch 0 bzw. 100 ersetzt; Abhängigkeiten wie z.B. notify's sind vom User anzupassen.
5.)
set ... pct als zulässiger Befehl wird entfernt
6.) Das Reading pct wird nicht mehr beschrieben bzw. entfernt
Umgesetzt wird das ganz allmählich.
Schritt 1 ist schon aktiv
Schritte 2 und 3 erfolgen mit dem nächsten Update
die weiteren Schritte folgen danach jeweils ca. 2 Wochen zeitversetzt
Und warum das Ganze?
Weil derzeit sowohl Helligkeiten von dimmbaren Geräten als auch die Sollposition von Rollos über
set ... pct gesteuert werden. Durch die Änderung wird das eindeutiger, auch in der kontextsensitiven Commandref.
Da die Shelly-Welt ständig komplexer wird, muss das Modul mit jedem neuen Device angepasst werden, Sonderfälle müssen nach Möglichkeit reduziert werden!
LG
Starkstrombastler
Ich habe mit der Aktuellen Version noch ein Problem von "vertauschten" 0 und 100 Prozent. Ich nutze webcmd
ttributes:
ShellyName Rollladen KiZi Fenster
alias Rollladen Fenster
cmdIcon auf:control_arrow_up zu:control_arrow_down stop:stop_button
devStateIcon 9.*:fts_shutter_10 8.*:fts_shutter_20 1.*:fts_shutter_90 2.*:fts_shutter_80 3.*:fts_shutter_70 4.*:fts_shutter_60 auf:fts_shutter_10:zu zu:fts_shutter_100:auf 5.*:fts_shutter_50 6.*:fts_shutter_30 7.*:fts_shutter_20
eventMap closed:zu open:auf
genericDeviceType blind
group Rollladen
homebridgeMapping On=state,cmdOn=on,cmdOff=off,valueOn=on,valueOff=off
maxtime 24
mode roller
model shelly2.5
room Homekit,Kinderzimmer
stateFormat position
timeout 8
userattr Gesamte_Rollladen Gesamte_Rollladen_map structexclude
verbose 0
webCmd pct:auf:zu:stop
um einen Slider auf der Oberfläche anzuzeigen. Das sieht auf der alten Version von irgendwann Dezember noch wie gewünscht aus.
(Siehe Foto1 ).
Mit der neuen Version passt es nicht mehr... (Siehe Foto2)
viele Grüße
Jens
Zitat von: Jens_B am 10 Januar 2024, 17:08:41webCmd pct:auf:zu:stop
muss sein:
webCmd pos:auf:zu:stopZitat von: Jens_B am 10 Januar 2024, 17:08:41Ich habe mit der Aktuellen Version noch ein Problem von "vertauschten" 0 und 100 Prozent.
Wo ist denn das Attribut
pct100 geblieben? Wenn der komplett nach unten gefahrene Rollo = 100% sein soll, muss das Attribut zu
closed gesetzt sein.
Darf ich mal nachfragen, warum eigentlich das Reading für die Rollladenstellung von pct auf pos geändert wurde?
Ich betreibe Rollladenaktoren von HomeMatic, von Velux und von Somfy - und einheitlich heißt dieses Reading dort pct.
Abgesehen vom eher formalen Argument der Einheitlichkeit erschwert die neue Benennung deutlich, Rollladenaktoren von Shelly mit anderen Systemen z.B. in einer structure zusammenzufassen.
Als "Erfinder" des Shelly-Moduls spreche ich mich deshalb nachdrücklich dafür aus, zum alten Namen pct zurückzukehren.
LG
pah
ZitatAls "Erfinder" des Shelly-Moduls spreche ich mich deshalb nachdrücklich dafür aus, zum alten Namen pct zurückzukehren.
Das möchte ich unterstützen. Außerdem ist es ein Klacks, ein zusätzliches Reading pos anzulegen:
attr ... userReadings pos:pct.* { ReadingsVal("$NAME","pct","0") }
Zitat von: Starkstrombastler am 10 Januar 2024, 19:50:41Zitat von: Jens_B am 10 Januar 2024, 17:08:41webCmd pct:auf:zu:stop
muss sein:
webCmd pos:auf:zu:stop
Zitat von: Jens_B am 10 Januar 2024, 17:08:41Ich habe mit der Aktuellen Version noch ein Problem von "vertauschten" 0 und 100 Prozent.
Wo ist denn das Attribut pct100 geblieben? Wenn der komplett nach unten gefahrene Rollo = 100% sein soll, muss das Attribut zu closed gesetzt sein.
Der Runtergefahrene Rolladen ist 0% offen ist 100%.
So ist es bei allen meiner Homematic Rollladen ebenfalls.
Bisher konnte ich halt auch alle Rollladen zu eine Structure zusammenfassen, mit der neuen Version fahren aber die Shellys nicht mehr über die Structure.
Dieses Attribut pct100 habe ich noch nie gesetzt.
Mit der alten Version vom Dezember funktioniert es ja einwandfrei. Ich habe die alte Version wieder eingespielt, damit es erstmal wieder funktioniert.
Zitat von: JWRu am 11 Januar 2024, 09:32:38ZitatAls "Erfinder" des Shelly-Moduls spreche ich mich deshalb nachdrücklich dafür aus, zum alten Namen pct zurückzukehren.
Das möchte ich unterstützen. Außerdem ist es ein Klacks, ein zusätzliches Reading pos anzulegen:
attr ... userReadings pos:pct.* { ReadingsVal("$NAME","pct","0") }
Ja klar ist es ein klacks, aber unschön als Anwender das ich das jetzt bei allen rollladen anpassen muss, wo es vorher einwandfrei funktioniert hat.
Zitat von: Starkstrombastler
Und warum das Ganze?
Weil derzeit sowohl Helligkeiten von dimmbaren Geräten als auch die Sollposition von Rollos überfont=Courier New]set ... pct[/font] gesteuert werden. Durch die Änderung wird das eindeutiger, auch in der kontextsensitiven Commandref.
Da die Shelly-Welt ständig komplexer wird, muss das Modul mit jedem neuen Device angepasst werden, Sonderfälle müssen nach Möglichkeit reduziert werden!
LG
Starkstrombastler
Ich halte das für keine gute Idee. Pct durch pos bei Rollladen zu ersetzen.
Wo ist das Problem das man. PCT sowohl für Helligkeit an einem dimmbaren Gerät als auch an den Rollladenschaltern nutzt?
Man nutzt Prozent doch auch im täglichen Leben für unterschiedliche Zwecke, und nicht nur für Helligkeit.
Frage zu shellyplus2pm:
Ich hab ein entsprechendes Teil eingebunden und habe beim ersten Kanal immerwieder die Problematik, dass dort manchmal als State "false" statt on / off angezeigt wird. Da ich auch versuche das ein wenig zu verstehen:
DEVICETOPIC/events/rpc:.* { return if $EVENT =~ m{switch:[1-3]}; $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT,'',$JSONMAP) }
Die entsprechende Stelle scheint diese hier zu sein - wofür steht hier der Teil $EVENT =~ m{switch:[1-3]}; ?
Wenn ich nun in meinen Readings nach online schaue, "scheint" es so als würde dort immer der richtige Zustand stehen (unabhängig vom zweiten Kanal)
List vom betroffenen Gerät (CH1)
define dev_OG_BUE_PC1 MQTT2_DEVICE shellyplus2pm_xxxxxxxx
attr dev_OG_BUE_PC1 DbLogExclude .*
attr dev_OG_BUE_PC1 alias PC Andreas
attr dev_OG_BUE_PC1 autocreate 1
attr dev_OG_BUE_PC1 comment Channel 1 for MQTT2_shellyplus2pm_xxxxxxxx, see also MQTT2_shellyplus2pm_xxxxxxxx_CH2
attr dev_OG_BUE_PC1 devStateIcon off:it_pc@green:on false:it_pc@green:on on:it_pc@red:off
attr dev_OG_BUE_PC1 devicetopic shellyplus2pm-xxxxxxxx
attr dev_OG_BUE_PC1 event-on-change-reading params_switch_0_aenergy_by_minute_3:1500,params_kwh_.,params_kwh_.,zaehler_.:1500,state
attr dev_OG_BUE_PC1 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr dev_OG_BUE_PC1 group Geräte
attr dev_OG_BUE_PC1 icon it_pc
attr dev_OG_BUE_PC1 jsonMap params_switch_0_state:state params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 params_wifi_sta_ip:ip temperature_tC:temperature temperature_tF:0
attr dev_OG_BUE_PC1 model shellyPlus_2pm_split
attr dev_OG_BUE_PC1 readingList $DEVICETOPIC/online:.* online\
$DEVICETOPIC/events/rpc:.* { return if $EVENT =~ m{switch:[1-3]};; $EVENT =~ s/"output":true/"state":"on"/g;; $EVENT =~ s/"output":false/"state":"off"/g;; json2nameValue($EVENT,'',$JSONMAP) }\
$DEVICETOPIC/status/switch.0:.* { json2nameValue($EVENT, '', $JSONMAP) }\
$DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, '', $JSONMAP) }\
fhem2shelly/rpc:.* {}\
shellyplus2pm_xxxxxxxx:shellyplus2pm-xxxxxxxx/status/sys:.* { json2nameValue($EVENT) }\
shellyplus2pm_xxxxxxxx:shellyplus2pm-xxxxxxxx/status/ble:.* ble\
shellyplus2pm_xxxxxxxx:shellyplus2pm-xxxxxxxx/status/cloud:.* { json2nameValue($EVENT) }\
shellyplus2pm_xxxxxxxx:shellyplus2pm-xxxxxxxx/status/input_0:.* { json2nameValue($EVENT) }\
shellyplus2pm_xxxxxxxx:shellyplus2pm-xxxxxxxx/status/input_1:.* { json2nameValue($EVENT) }\
shellyplus2pm_xxxxxxxx:shellyplus2pm-xxxxxxxx/status/wifi:.* { json2nameValue($EVENT) }\
shellyplus2pm_xxxxxxxx:shellyplus2pm-xxxxxxxx/status/ws:.* { json2nameValue($EVENT) }
attr dev_OG_BUE_PC1 room Büro / Gäste
attr dev_OG_BUE_PC1 setList toggle:noArg $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}\
off:noArg $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}\
on:noArg $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true}}\
on-for-timer $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.Set","params": {"id":1,"on":true,"toggle_after":$EVTPART1}}\
off-for-timer $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.Set","params": {"id":1,"on":false,"toggle_after":$EVTPART1}}\
x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Update","params": {"stage":"stable"}}\
x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Reboot"}
attr dev_OG_BUE_PC1 userReadings zaehler_0 monotonic { ReadingsVal($NAME,"aenergy_total",0)},\
params_wifi_rssi { ReadingsVal($NAME,"rssi",0)}
attr dev_OG_BUE_PC1 verbose 2
attr dev_OG_BUE_PC1 webCmd :
# CFGFN
# CID shellyplus2pm_xxxxxxxx
# DEF shellyplus2pm_xxxxxxxx
# FUUID 659ea40a-f33f-6adc-84f5-af14bb996af1af02
# IODev brok_MQTT2
# LASTInputDev brok_MQTT2
# MSGCNT 67295
# NAME dev_OG_BUE_PC1
# NR 136222
# STATE false
# TYPE MQTT2_DEVICE
# brok_MQTT2_CONN brok_MQTT2_192.168.50.154_54538
# brok_MQTT2_MSGCNT 67295
# brok_MQTT2_TIME 2024-01-11 13:45:28
# eventCount 10
# JSONMAP:
# params_switch_0_aenergy_total aenergy_total
# params_switch_0_apower apower
# params_switch_0_state state
# params_switch_0_temperature_tC temperature
# params_switch_0_temperature_tF 0
# params_wifi_sta_ip ip
# temperature_tC temperature
# temperature_tF 0
# READINGS:
# 2024-01-10 15:05:07 IODev brok_MQTT2
# 2024-01-11 13:45:27 aenergy_by_minute_1 762.511
# 2024-01-11 13:45:27 aenergy_by_minute_2 1688.128
# 2024-01-11 13:45:27 aenergy_by_minute_3 1691.733
# 2024-01-11 13:45:27 aenergy_minute_ts 1704977126
# 2024-01-11 13:45:27 aenergy_total 168714.496
# 2024-01-11 13:45:27 apower 96.7
# 2023-02-02 12:55:36 associatedWith dev_OG_BUE_PC2
# 2023-02-02 12:53:46 attrTemplateVersion 20230111
# 2023-12-20 03:10:31 available_updates_beta_version 1.0.7-beta1
# 2023-12-21 11:50:26 available_updates_stable_version 1.1.0
# 2023-02-23 10:34:04 battery plug
# 2024-01-11 13:36:35 ble {}
# 2024-01-11 13:36:35 cfg_rev 43
# 2024-01-11 13:36:35 connected true
# 2024-01-11 13:45:27 current 0.462
# 2024-01-11 13:45:28 dst shellyplus2pm-xxxxxxxx/events
# 2024-01-11 13:45:27 freq 50.0
# 2024-01-11 13:36:35 fs_free 131072
# 2024-01-11 13:36:35 fs_size 458752
# 2024-01-11 13:45:27 id 0
# 2024-01-11 13:36:35 kvs_rev 3
# 2024-01-11 13:36:35 mac xxxxxxxx
# 2024-01-11 13:45:28 method NotifyStatus
# 2023-11-20 09:46:58 on set
# 2024-01-11 13:36:35 online true
# 2024-01-11 13:45:27 output true
# 2023-12-21 11:50:26 params_events_1_cfg_rev 41
# 2024-01-11 13:31:57 params_events_1_component sys
# 2024-01-11 13:31:57 params_events_1_event scheduled_restart
# 2023-12-21 11:50:26 params_events_1_msg success
# 2023-12-21 11:50:24 params_events_1_progress_percent 98
# 2023-12-21 11:50:26 params_events_1_restart_required false
# 2024-01-11 13:31:57 params_events_1_time_ms 996
# 2024-01-11 13:31:57 params_events_1_ts 1704976317.91
# 2024-01-06 18:47:59 params_input_1_id 1
# 2024-01-06 18:47:59 params_input_1_state false
# 2023-02-03 23:22:10 params_kwh_0 0.000
# 2024-01-11 13:36:35 params_mqtt_connected true
# 2024-01-11 13:45:02 params_switch_0_aenergy_by_minute_1 1688.128
# 2024-01-11 13:45:02 params_switch_0_aenergy_by_minute_2 1691.733
# 2024-01-11 13:45:02 params_switch_0_aenergy_by_minute_3 1715.939
# 2024-01-11 13:45:02 params_switch_0_aenergy_minute_ts 1704977099
# 2024-01-11 13:45:28 params_switch_0_current 0.462
# 2024-01-11 13:45:28 params_switch_0_id 0
# 2024-01-11 02:54:28 params_switch_0_pf 0
# 2024-01-11 13:45:02 params_switch_0_ret_aenergy_by_minute_1 0.000
# 2024-01-11 13:45:02 params_switch_0_ret_aenergy_by_minute_2 0.000
# 2024-01-11 13:45:02 params_switch_0_ret_aenergy_by_minute_3 0.000
# 2024-01-11 13:45:02 params_switch_0_ret_aenergy_minute_ts 1704977099
# 2024-01-11 13:45:02 params_switch_0_ret_aenergy_total 0.000
# 2024-01-11 11:04:46 params_switch_0_source MQTT
# 2024-01-09 12:44:07 params_switch_0_voltage 237.1
# 2024-01-11 13:33:02 params_switch_1_aenergy_by_minute_1 2804.772
# 2024-01-11 13:33:02 params_switch_1_aenergy_by_minute_2 1474.886
# 2024-01-11 13:33:02 params_switch_1_aenergy_by_minute_3 1479.566
# 2024-01-11 13:33:02 params_switch_1_aenergy_minute_ts 1704976379
# 2024-01-11 13:33:02 params_switch_1_aenergy_total 26664.443
# 2024-01-11 13:33:29 params_switch_1_apower 67.5
# 2024-01-11 13:33:30 params_switch_1_current 0.337
# 2024-01-11 13:33:30 params_switch_1_id 1
# 2024-01-11 13:33:02 params_switch_1_ret_aenergy_by_minute_1 0.000
# 2024-01-11 13:33:02 params_switch_1_ret_aenergy_by_minute_2 0.000
# 2024-01-11 13:33:02 params_switch_1_ret_aenergy_by_minute_3 0.000
# 2024-01-11 13:33:02 params_switch_1_ret_aenergy_minute_ts 1704976379
# 2024-01-11 13:33:02 params_switch_1_ret_aenergy_total 0.005
# 2023-10-18 12:35:48 params_sys_available_updates_beta_version 1.0.7-beta1
# 2023-12-21 11:49:41 params_sys_available_updates_stable_version 1.1.0
# 2023-12-21 11:50:26 params_sys_cfg_rev 41
# 2024-01-11 13:45:28 params_ts 1704977127.74
# 2024-01-11 13:45:28 params_wifi_rssi -64
# 2024-01-11 13:45:27 pf 0.87
# 2024-01-11 13:36:35 ram_free 131904
# 2024-01-11 13:36:35 ram_size 244280
# 2024-01-11 13:36:35 reset_reason 3
# 2024-01-11 13:36:35 restart_required false
# 2024-01-11 13:45:27 ret_aenergy_by_minute_1 0.000
# 2024-01-11 13:45:27 ret_aenergy_by_minute_2 0.000
# 2024-01-11 13:45:27 ret_aenergy_by_minute_3 0.000
# 2024-01-11 13:45:27 ret_aenergy_minute_ts 1704977126
# 2024-01-11 13:45:27 ret_aenergy_total 0.000
# 2024-01-11 13:36:35 rssi -64
# 2024-01-11 13:36:35 schedule_rev 0
# 2024-01-11 13:45:27 source init
# 2024-01-11 13:45:28 src shellyplus2pm-xxxxxxxx
# 2024-01-11 13:36:35 ssid FlummyDev50
# 2024-01-11 13:36:35 sta_ip 192.168.50.154
# 2024-01-11 13:36:35 state false
# 2024-01-11 13:36:35 status got ip
# 2024-01-11 13:45:27 temperature 60.1
# 2024-01-10 15:05:01 temperature_tC 53.6
# 2024-01-10 15:05:01 temperature_tF 128.5
# 2024-01-11 13:36:35 time 13:36
# 2024-01-11 13:36:35 unixtime 1704976594
# 2024-01-11 13:36:35 uptime 275
# 2024-01-11 13:45:27 voltage 236.9
# 2024-01-11 13:36:35 webhook_rev 0
# 2023-02-02 12:53:45 x_reboot set
# 2024-01-11 13:45:28 zaehler_0 309160.290000001
#
setstate dev_OG_BUE_PC1 false
setstate dev_OG_BUE_PC1 2024-01-10 15:05:07 IODev brok_MQTT2
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 aenergy_by_minute_1 762.511
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 aenergy_by_minute_2 1688.128
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 aenergy_by_minute_3 1691.733
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 aenergy_minute_ts 1704977126
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 aenergy_total 168714.496
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 apower 96.7
setstate dev_OG_BUE_PC1 2023-02-02 12:55:36 associatedWith dev_OG_BUE_PC2
setstate dev_OG_BUE_PC1 2023-02-02 12:53:46 attrTemplateVersion 20230111
setstate dev_OG_BUE_PC1 2023-12-20 03:10:31 available_updates_beta_version 1.0.7-beta1
setstate dev_OG_BUE_PC1 2023-12-21 11:50:26 available_updates_stable_version 1.1.0
setstate dev_OG_BUE_PC1 2023-02-23 10:34:04 battery plug
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 ble {}
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 cfg_rev 43
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 connected true
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 current 0.462
setstate dev_OG_BUE_PC1 2024-01-11 13:45:28 dst shellyplus2pm-xxxxxxxx/events
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 freq 50.0
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 fs_free 131072
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 fs_size 458752
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 id 0
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 kvs_rev 3
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 mac xxxxxxxx
setstate dev_OG_BUE_PC1 2024-01-11 13:45:28 method NotifyStatus
setstate dev_OG_BUE_PC1 2023-11-20 09:46:58 on set
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 online true
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 output true
setstate dev_OG_BUE_PC1 2023-12-21 11:50:26 params_events_1_cfg_rev 41
setstate dev_OG_BUE_PC1 2024-01-11 13:31:57 params_events_1_component sys
setstate dev_OG_BUE_PC1 2024-01-11 13:31:57 params_events_1_event scheduled_restart
setstate dev_OG_BUE_PC1 2023-12-21 11:50:26 params_events_1_msg success
setstate dev_OG_BUE_PC1 2023-12-21 11:50:24 params_events_1_progress_percent 98
setstate dev_OG_BUE_PC1 2023-12-21 11:50:26 params_events_1_restart_required false
setstate dev_OG_BUE_PC1 2024-01-11 13:31:57 params_events_1_time_ms 996
setstate dev_OG_BUE_PC1 2024-01-11 13:31:57 params_events_1_ts 1704976317.91
setstate dev_OG_BUE_PC1 2024-01-06 18:47:59 params_input_1_id 1
setstate dev_OG_BUE_PC1 2024-01-06 18:47:59 params_input_1_state false
setstate dev_OG_BUE_PC1 2023-02-03 23:22:10 params_kwh_0 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 params_mqtt_connected true
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_aenergy_by_minute_1 1688.128
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_aenergy_by_minute_2 1691.733
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_aenergy_by_minute_3 1715.939
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_aenergy_minute_ts 1704977099
setstate dev_OG_BUE_PC1 2024-01-11 13:45:28 params_switch_0_current 0.462
setstate dev_OG_BUE_PC1 2024-01-11 13:45:28 params_switch_0_id 0
setstate dev_OG_BUE_PC1 2024-01-11 02:54:28 params_switch_0_pf 0
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_ret_aenergy_by_minute_1 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_ret_aenergy_by_minute_2 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_ret_aenergy_by_minute_3 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_ret_aenergy_minute_ts 1704977099
setstate dev_OG_BUE_PC1 2024-01-11 13:45:02 params_switch_0_ret_aenergy_total 0.000
setstate dev_OG_BUE_PC1 2024-01-11 11:04:46 params_switch_0_source MQTT
setstate dev_OG_BUE_PC1 2024-01-09 12:44:07 params_switch_0_voltage 237.1
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_aenergy_by_minute_1 2804.772
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_aenergy_by_minute_2 1474.886
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_aenergy_by_minute_3 1479.566
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_aenergy_minute_ts 1704976379
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_aenergy_total 26664.443
setstate dev_OG_BUE_PC1 2024-01-11 13:33:29 params_switch_1_apower 67.5
setstate dev_OG_BUE_PC1 2024-01-11 13:33:30 params_switch_1_current 0.337
setstate dev_OG_BUE_PC1 2024-01-11 13:33:30 params_switch_1_id 1
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_ret_aenergy_by_minute_1 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_ret_aenergy_by_minute_2 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_ret_aenergy_by_minute_3 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_ret_aenergy_minute_ts 1704976379
setstate dev_OG_BUE_PC1 2024-01-11 13:33:02 params_switch_1_ret_aenergy_total 0.005
setstate dev_OG_BUE_PC1 2023-10-18 12:35:48 params_sys_available_updates_beta_version 1.0.7-beta1
setstate dev_OG_BUE_PC1 2023-12-21 11:49:41 params_sys_available_updates_stable_version 1.1.0
setstate dev_OG_BUE_PC1 2023-12-21 11:50:26 params_sys_cfg_rev 41
setstate dev_OG_BUE_PC1 2024-01-11 13:45:28 params_ts 1704977127.74
setstate dev_OG_BUE_PC1 2024-01-11 13:45:28 params_wifi_rssi -64
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 pf 0.87
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 ram_free 131904
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 ram_size 244280
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 reset_reason 3
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 restart_required false
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 ret_aenergy_by_minute_1 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 ret_aenergy_by_minute_2 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 ret_aenergy_by_minute_3 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 ret_aenergy_minute_ts 1704977126
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 ret_aenergy_total 0.000
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 rssi -64
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 schedule_rev 0
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 source init
setstate dev_OG_BUE_PC1 2024-01-11 13:45:28 src shellyplus2pm-xxxxxxxx
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 ssid FlummyDev50
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 sta_ip 192.168.50.154
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 state false
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 status got ip
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 temperature 60.1
setstate dev_OG_BUE_PC1 2024-01-10 15:05:01 temperature_tC 53.6
setstate dev_OG_BUE_PC1 2024-01-10 15:05:01 temperature_tF 128.5
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 time 13:36
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 unixtime 1704976594
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 uptime 275
setstate dev_OG_BUE_PC1 2024-01-11 13:45:27 voltage 236.9
setstate dev_OG_BUE_PC1 2024-01-11 13:36:35 webhook_rev 0
setstate dev_OG_BUE_PC1 2023-02-02 12:53:45 x_reboot set
setstate dev_OG_BUE_PC1 2024-01-11 13:45:28 zaehler_0 309160.290000001
CH2
define dev_OG_BUE_PC2 MQTT2_DEVICE
attr dev_OG_BUE_PC2 DbLogExclude .*
attr dev_OG_BUE_PC2 IODev brok_MQTT2
attr dev_OG_BUE_PC2 alias PC Yvonne
attr dev_OG_BUE_PC2 autocreate 1
attr dev_OG_BUE_PC2 comment Channel 2 for MQTT2_shellyplus2pm_xxxxxxxx
attr dev_OG_BUE_PC2 devStateIcon off:it_pc@green:on false:it_pc@green:on on:it_pc@red:off
attr dev_OG_BUE_PC2 devicetopic shellyplus2pm-xxxxxxxx
attr dev_OG_BUE_PC2 event-on-change-reading aenergy_by_minute_.:50,state,apower:10,aenergy_total:50
attr dev_OG_BUE_PC2 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr dev_OG_BUE_PC2 group Geräte
attr dev_OG_BUE_PC2 icon it_pc
attr dev_OG_BUE_PC2 jsonMap params_switch_1_state:state params_switch_1_aenergy_total:aenergy_total params_switch_1_apower:apower params_switch_1_temperature_tC:temperature params_switch_1_temperature_tF:0 temperature_tC:temperature temperature_tF:0
attr dev_OG_BUE_PC2 model shellyPlus_2pm_split
attr dev_OG_BUE_PC2 readingList $DEVICETOPIC/events/rpc:.* { return if $EVENT !~ m{switch:1};; $EVENT =~ s/"output":true/"state":"on"/g;; $EVENT =~ s/"output":false/"state":"off"/g;; json2nameValue($EVENT,'',$JSONMAP) }\
$DEVICETOPIC/status/switch.1:.* { json2nameValue($EVENT, '', $JSONMAP) }\
shellyplus2pm_xxxxxxxx:shellyplus2pm-xxxxxxxx/status/sys:.* { json2nameValue($EVENT) }
attr dev_OG_BUE_PC2 room Büro / Gäste
attr dev_OG_BUE_PC2 setList toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":1}}\
off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":1,"on":false}}\
on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":1,"on":true}}\
on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":1,"on":true,"toggle_after":$EVTPART1}}\
off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":1,"on":false,"toggle_after":$EVTPART1}}
attr dev_OG_BUE_PC2 userReadings online { ReadingsVal("dev_OG_BUE_PC1","online",0)}
attr dev_OG_BUE_PC2 verbose 2
attr dev_OG_BUE_PC2 webCmd :
# CFGFN
# DEF
# FUUID 659ea40f-f33f-6adc-0782-f081446f26a91dd5
# IODev brok_MQTT2
# LASTInputDev brok_MQTT2
# MSGCNT 38685
# NAME dev_OG_BUE_PC2
# NR 136223
# STATE on
# TYPE MQTT2_DEVICE
# brok_MQTT2_CONN brok_MQTT2_192.168.50.154_54538
# brok_MQTT2_MSGCNT 38685
# brok_MQTT2_TIME 2024-01-11 13:46:44
# eventCount 1096
# JSONMAP:
# params_switch_1_aenergy_total aenergy_total
# params_switch_1_apower apower
# params_switch_1_state state
# params_switch_1_temperature_tC temperature
# params_switch_1_temperature_tF 0
# temperature_tC temperature
# temperature_tF 0
# READINGS:
# 2024-01-10 15:05:10 IODev brok_MQTT2
# 2024-01-11 13:46:02 aenergy_by_minute_1 1266.379
# 2024-01-11 13:46:02 aenergy_by_minute_2 1352.803
# 2024-01-11 13:46:02 aenergy_by_minute_3 1541.680
# 2024-01-11 13:46:02 aenergy_minute_ts 1704977159
# 2024-01-11 13:46:02 aenergy_total 26682.048
# 2024-01-11 13:46:02 apower 79.5
# 2023-02-02 12:55:31 associatedWith dev_OG_BUE_PC1
# 2023-02-02 12:53:46 attrTemplateVersion 20230111
# 2023-12-20 03:10:31 available_updates_beta_version 1.0.7-beta1
# 2023-12-21 11:50:26 available_updates_stable_version 1.1.0
# 2023-02-23 10:34:04 battery plug
# 2024-01-11 13:36:35 cfg_rev 43
# 2024-01-11 13:46:02 current 0.387
# 2024-01-11 13:46:02 dst shellyplus2pm-xxxxxxxx/events
# 2024-01-11 13:46:02 freq 50.0
# 2024-01-11 13:36:35 fs_free 131072
# 2024-01-11 13:36:35 fs_size 458752
# 2024-01-11 13:46:02 id 1
# 2024-01-11 13:36:35 kvs_rev 3
# 2024-01-11 13:36:35 mac xxxxxxxx
# 2024-01-11 13:46:02 method NotifyStatus
# 2024-01-11 13:46:02 online true
# 2024-01-11 13:46:02 output true
# 2024-01-11 13:36:35 params_cloud_connected false
# 2024-01-11 13:36:35 params_input_0_id 0
# 2024-01-11 13:36:35 params_input_0_state false
# 2024-01-11 13:36:35 params_input_1_id 1
# 2024-01-11 13:36:35 params_input_1_state false
# 2024-01-11 13:36:35 params_mqtt_connected true
# 2024-01-11 13:36:35 params_switch_0_aenergy_by_minute_1 969.128
# 2024-01-11 13:36:35 params_switch_0_aenergy_by_minute_2 1715.038
# 2024-01-11 13:36:35 params_switch_0_aenergy_by_minute_3 1743.197
# 2024-01-11 13:36:35 params_switch_0_aenergy_minute_ts 1704976593
# 2024-01-11 13:36:35 params_switch_0_aenergy_total 168699.238
# 2024-01-11 13:36:35 params_switch_0_apower 92.1
# 2024-01-11 13:36:35 params_switch_0_current 0.456
# 2024-01-11 13:36:35 params_switch_0_freq 50.0
# 2024-01-11 13:36:35 params_switch_0_id 0
# 2024-01-11 13:36:35 params_switch_0_pf 0.86
# 2024-01-11 13:36:35 params_switch_0_ret_aenergy_by_minute_1 0.000
# 2024-01-11 13:36:35 params_switch_0_ret_aenergy_by_minute_2 0.000
# 2024-01-11 13:36:35 params_switch_0_ret_aenergy_by_minute_3 0.000
# 2024-01-11 13:36:35 params_switch_0_ret_aenergy_minute_ts 1704976593
# 2024-01-11 13:36:35 params_switch_0_ret_aenergy_total 0.000
# 2024-01-11 13:36:35 params_switch_0_source init
# 2024-01-11 13:36:35 params_switch_0_state on
# 2024-01-11 13:36:35 params_switch_0_temperature_tC 59.6
# 2024-01-11 13:36:35 params_switch_0_temperature_tF 139.3
# 2024-01-11 13:36:35 params_switch_0_voltage 238.0
# 2024-01-11 13:46:02 params_switch_1_aenergy_by_minute_1 1266.379
# 2024-01-11 13:46:02 params_switch_1_aenergy_by_minute_2 1352.803
# 2024-01-11 13:46:02 params_switch_1_aenergy_by_minute_3 1541.680
# 2024-01-11 13:46:02 params_switch_1_aenergy_minute_ts 1704977159
# 2024-01-11 13:46:02 params_switch_1_current 0.387
# 2024-01-11 13:36:35 params_switch_1_freq 50.0
# 2024-01-11 13:46:02 params_switch_1_id 1
# 2024-01-11 13:36:35 params_switch_1_pf 0.86
# 2024-01-11 13:46:02 params_switch_1_ret_aenergy_by_minute_1 0.000
# 2024-01-11 13:46:02 params_switch_1_ret_aenergy_by_minute_2 0.000
# 2024-01-11 13:46:02 params_switch_1_ret_aenergy_by_minute_3 0.000
# 2024-01-11 13:46:02 params_switch_1_ret_aenergy_minute_ts 1704977159
# 2024-01-11 13:46:02 params_switch_1_ret_aenergy_total 0.005
# 2024-01-11 13:36:35 params_switch_1_source init
# 2024-01-11 13:36:35 params_switch_1_voltage 238.1
# 2023-12-20 03:10:31 params_sys_available_updates_beta_version 1.0.7-beta1
# 2024-01-11 13:36:35 params_sys_cfg_rev 43
# 2024-01-11 13:36:35 params_sys_fs_free 131072
# 2024-01-11 13:36:35 params_sys_fs_size 458752
# 2024-01-11 13:36:35 params_sys_kvs_rev 3
# 2024-01-11 13:36:35 params_sys_mac xxxxxxxx
# 2024-01-11 13:36:35 params_sys_ram_free 133572
# 2024-01-11 13:36:35 params_sys_ram_size 244364
# 2024-01-11 13:36:35 params_sys_reset_reason 3
# 2024-01-11 13:36:35 params_sys_restart_required false
# 2024-01-11 13:36:35 params_sys_schedule_rev 0
# 2024-01-11 13:36:35 params_sys_time 13:36
# 2024-01-11 13:36:35 params_sys_unixtime 1704976594
# 2024-01-11 13:36:35 params_sys_uptime 275
# 2024-01-11 13:36:35 params_sys_webhook_rev 0
# 2024-01-11 13:46:02 params_ts 1704977160.75
# 2024-01-11 13:36:35 params_wifi_rssi -64
# 2024-01-11 13:36:35 params_wifi_ssid FlummyDev50
# 2024-01-11 13:36:35 params_wifi_sta_ip 192.168.50.154
# 2024-01-11 13:36:35 params_wifi_status got ip
# 2024-01-11 13:36:35 params_ws_connected false
# 2024-01-11 13:46:02 pf 0.85
# 2024-01-11 13:36:35 ram_free 131904
# 2024-01-11 13:36:35 ram_size 244280
# 2024-01-11 13:36:35 reset_reason 3
# 2024-01-11 13:36:35 restart_required false
# 2024-01-11 13:46:02 ret_aenergy_by_minute_1 0.000
# 2024-01-11 13:46:02 ret_aenergy_by_minute_2 0.000
# 2024-01-11 13:46:02 ret_aenergy_by_minute_3 0.000
# 2024-01-11 13:46:02 ret_aenergy_minute_ts 1704977159
# 2024-01-11 13:46:02 ret_aenergy_total 0.005
# 2024-01-11 13:36:35 schedule_rev 0
# 2024-01-11 13:46:02 source init
# 2024-01-11 13:46:02 src shellyplus2pm-xxxxxxxx
# 2024-01-11 13:36:35 state on
# 2024-01-11 13:46:02 temperature 59.8
# 2024-01-11 13:36:35 time 13:36
# 2024-01-11 13:36:35 unixtime 1704976594
# 2024-01-11 13:36:35 uptime 275
# 2024-01-11 13:46:02 voltage 237.2
# 2024-01-11 13:36:35 webhook_rev 0
#
setstate dev_OG_BUE_PC2 on
setstate dev_OG_BUE_PC2 2024-01-10 15:05:10 IODev brok_MQTT2
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 aenergy_by_minute_1 1266.379
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 aenergy_by_minute_2 1352.803
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 aenergy_by_minute_3 1541.680
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 aenergy_minute_ts 1704977159
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 aenergy_total 26682.048
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 apower 79.5
setstate dev_OG_BUE_PC2 2023-02-02 12:55:31 associatedWith dev_OG_BUE_PC1
setstate dev_OG_BUE_PC2 2023-02-02 12:53:46 attrTemplateVersion 20230111
setstate dev_OG_BUE_PC2 2023-12-20 03:10:31 available_updates_beta_version 1.0.7-beta1
setstate dev_OG_BUE_PC2 2023-12-21 11:50:26 available_updates_stable_version 1.1.0
setstate dev_OG_BUE_PC2 2023-02-23 10:34:04 battery plug
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 cfg_rev 43
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 current 0.387
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 dst shellyplus2pm-xxxxxxxx/events
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 freq 50.0
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 fs_free 131072
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 fs_size 458752
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 id 1
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 kvs_rev 3
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 mac xxxxxxxx
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 method NotifyStatus
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 online true
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 output true
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_cloud_connected false
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_input_0_id 0
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_input_0_state false
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_input_1_id 1
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_input_1_state false
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_mqtt_connected true
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_aenergy_by_minute_1 969.128
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_aenergy_by_minute_2 1715.038
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_aenergy_by_minute_3 1743.197
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_aenergy_minute_ts 1704976593
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_aenergy_total 168699.238
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_apower 92.1
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_current 0.456
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_freq 50.0
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_id 0
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_pf 0.86
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_ret_aenergy_by_minute_1 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_ret_aenergy_by_minute_2 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_ret_aenergy_by_minute_3 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_ret_aenergy_minute_ts 1704976593
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_ret_aenergy_total 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_source init
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_state on
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_temperature_tC 59.6
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_temperature_tF 139.3
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_0_voltage 238.0
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_aenergy_by_minute_1 1266.379
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_aenergy_by_minute_2 1352.803
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_aenergy_by_minute_3 1541.680
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_aenergy_minute_ts 1704977159
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_current 0.387
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_1_freq 50.0
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_id 1
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_1_pf 0.86
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_ret_aenergy_by_minute_1 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_ret_aenergy_by_minute_2 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_ret_aenergy_by_minute_3 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_ret_aenergy_minute_ts 1704977159
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_switch_1_ret_aenergy_total 0.005
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_1_source init
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_switch_1_voltage 238.1
setstate dev_OG_BUE_PC2 2023-12-20 03:10:31 params_sys_available_updates_beta_version 1.0.7-beta1
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_cfg_rev 43
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_fs_free 131072
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_fs_size 458752
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_kvs_rev 3
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_mac xxxxxxxx
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_ram_free 133572
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_ram_size 244364
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_reset_reason 3
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_restart_required false
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_schedule_rev 0
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_time 13:36
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_unixtime 1704976594
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_uptime 275
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_sys_webhook_rev 0
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 params_ts 1704977160.75
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_wifi_rssi -64
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_wifi_ssid FlummyDev50
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_wifi_sta_ip 192.168.50.154
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_wifi_status got ip
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 params_ws_connected false
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 pf 0.85
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 ram_free 131904
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 ram_size 244280
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 reset_reason 3
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 restart_required false
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 ret_aenergy_by_minute_1 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 ret_aenergy_by_minute_2 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 ret_aenergy_by_minute_3 0.000
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 ret_aenergy_minute_ts 1704977159
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 ret_aenergy_total 0.005
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 schedule_rev 0
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 source init
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 src shellyplus2pm-xxxxxxxx
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 state on
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 temperature 59.8
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 time 13:36
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 unixtime 1704976594
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 uptime 275
setstate dev_OG_BUE_PC2 2024-01-11 13:46:02 voltage 237.2
setstate dev_OG_BUE_PC2 2024-01-11 13:36:35 webhook_rev 0
Würde mich freuen, wenn mich jemand in die richtige Richtung schubsen könnte.
VG
Andreas
p.s. leider scheint die Suche IM Beitrag nicht zu funktionieren. Suche ich "shellyplus2pm" finde ich es nicht. Auf einigen Seiten habe ich es dennoch mal gelesen.
ZitatIch halte das für keine gute Idee. Pct durch pos bei Rollladen zu ersetzen.
Wo ist das Problem das man. PCT sowohl für Helligkeit an einem dimmbaren Gerät als auch an den Rollladenschaltern nutzt?
Man nutzt Prozent doch auch im täglichen Leben für unterschiedliche Zwecke, und nicht nur für Helligkeit.
Auch Alexa erwartet für die Steuerung von Rolläden ein Reading "pct".
Zitat von: flummy1978 am 11 Januar 2024, 13:48:31Frage zu shellyplus2pm:
Wir behandeln in diesem Thread die Einbindung der Shellies mit dem Shelly-Modul (36_Shelly.pm). Dein Device ist aber als MQTT-Device definiert - da musst du bitte an anderer Stelle suchen.
Zitat von: Jens_B am 11 Januar 2024, 12:59:59Ich halte das für keine gute Idee. Pct durch pos bei Rollladen zu ersetzen.
...das hätte ich mir gleich denken können. Änderungen im Bestand sind halt immer schwierig, weil am Ende viel mehr Probleme auftauchen als wie man vorher bedacht hat. Weil FHEM so mächtig ist.
Also zurück. Mit dem nächsten Update wird
set ... pct wieder im Dropdown-Menu erscheinen und die Hinweise im Log verschwinden auch wieder.
Wer bereits etwas geändert hat, z.B. beim Attribut webCmd, muss das wieder zurückändern. :-[
Wer das mit der aktuellen Version (5.18) auszuprobieren möchte, ersetzt in 36_Shelly.pm in Zeile 236 'pos' durch 'pct'. Die Zeile sieht dann so aus:
"Rol" => " closed open stop:noArg pct:slider,0,1,100 delta zero:noArg predefAttr:noArg", Und wen die Log-Einträge stören, kommentiert diese in den Zeilen 1546 und 2144 aus.
Vor dem Neustart bitte
reload 36_Shelly.pm aufrufen.
@Jens_B:
Zitat von: Jens_B am 11 Januar 2024, 10:56:11Dieses Attribut pct100 habe ich noch nie gesetzt.
Das Attribut hat den Default-Wert 'open' und muss deswegen bei dir nicht extra gesetzt werden.
Ich mal wieder, mit dem Sensor-AddOn am Shellyplus1pm (Firmware 1.1.0)
ich weiss nicht, ob es vor einigen Wochen auch schon der Fall war.
Stand heute werden die angeschlossenen Sensoren (5x DS18B20) lediglich alle 4 Minuten aktualisiert.
Für meinen Anwendungszweck wäre es schön, wenn der Intervall etwas kürzer, vielleicht gar einstellbar wäre.
Gibt es für diese 4 Minuten Interval einen Grund, vielleicht von den Shelly verursacht?
Gibt es ein work around da etwas zu ändern?
Meine Versuche mit attr interval und maxAge waren bisher nicht von Erfolg gesegnet.
Danke.
vb
Zitat von: Starkstrombastler am 11 Januar 2024, 15:05:40Zitat von: Jens_B am 11 Januar 2024, 12:59:59Ich halte das für keine gute Idee. Pct durch pos bei Rollladen zu ersetzen.
...das hätte ich mir gleich denken können. Änderungen im Bestand sind halt immer schwierig, weil am Ende viel mehr Probleme auftauchen als wie man vorher bedacht hat. Weil FHEM so mächtig ist.
Also zurück. Mit dem nächsten Update wird set ... pct wieder im Dropdown-Menu erscheinen und die Hinweise im Log verschwinden auch wieder.
Wer bereits etwas geändert hat, z.B. beim Attribut webCmd, muss das wieder zurückändern. :-[
Wer das mit der aktuellen Version (5.18) auszuprobieren möchte, ersetzt in 36_Shelly.pm in Zeile 236 'pos' durch 'pct'. Die Zeile sieht dann so aus:
"Rol" => " closed open stop:noArg pct:slider,0,1,100 delta zero:noArg predefAttr:noArg", Und wen die Log-Einträge stören, kommentiert diese in den Zeilen 1546 und 2144 aus.
Vor dem Neustart bitte reload 36_Shelly.pm aufrufen.
@Jens_B:
Zitat von: Jens_B am 11 Januar 2024, 10:56:11Dieses Attribut pct100 habe ich noch nie gesetzt.
Das Attribut hat den Default-Wert 'open' und muss deswegen bei dir nicht extra gesetzt werden.
Und hat das jemand mal mit dem ASC Modul gegen gecheckt?
Zitat von: gent am 11 Januar 2024, 21:43:44Und hat das jemand mal mit dem ASC Modul gegen gecheckt?
Was genau soll denn jetzt gecheckt werden? Mit der Rücknahme der angekündigten Änderung ist doch wieder alles so wie vorher. Und in den letzten 12 Monaten hat sich hier kein User über irgendwelche Inkompatibilitäten bzgl. ASC gemeldet.
Zitat von: VB90 am 11 Januar 2024, 21:33:55Ich mal wieder, mit dem Sensor-AddOn am Shellyplus1pm (Firmware 1.1.0)
ich weiss nicht, ob es vor einigen Wochen auch schon der Fall war.
Stand heute werden die angeschlossenen Sensoren (5x DS18B20) lediglich alle 4 Minuten aktualisiert.
Für meinen Anwendungszweck wäre es schön, wenn der Intervall etwas kürzer, vielleicht gar einstellbar wäre.
Gibt es für diese 4 Minuten Interval einen Grund, vielleicht von den Shelly verursacht?
Ursache für dieses Verhalten ist der Versuch die Systemlast etwas zu reduzieren. Daher werden "originäre" Daten eines Devices (on, off, ...) im definierten Interval geholt. Alle anderen Daten (die sich nur eher selten ändern) und auch das Addon werden in einem Vielfachen des Intervals geholt. Mit Reduktion des Intervals sollten dann auch die Sensorwerte entsprechend schneller geholt werden.
Wesentlich besser ist es aber, im Shelly Actions anzulegen, welche immer "when the temperature changes" ausgeführt werden. Damit werden die Werte im Fhem-Device in Echtzeit aktualisiert. Dazu muss im Shelly die URL in etwa so aussehen:
http://192.168.178.100:8083/fhem?cmd=set%20myShelly%20tempC%20$temperature%201Du kannst die Funktion testen, indem du in der Fhem-Kommandozeile z.B. folgendes eingibst:
set myShelly tempC 25.5 1Damit wird im Reading temperature_1 der Wert 25.5 eingetragen.
ZitatUnd hat das jemand mal mit dem ASC Modul gegen gecheckt?
ASC funktioniert mit "position" oder "pct":
ZitatASC - 0/1/2
0 = "kein Anlegen der Attribute beim ersten Scan bzw. keine Beachtung eines Fahrbefehles",
1 = "Inverse oder Rollo - Bsp.: Rollo oben 0, Rollo unten 100 und der Befehl zum prozentualen Fahren ist position",
2 = "Homematic Style - Bsp.: Rollo oben 100, Rollo unten 0 und der Befehl zum prozentualen Fahren ist pct
ZitatMit dem nächsten Update wird set ... pct wieder im Dropdown-Menu erscheinen
Prima, danke. Und es ist ja nicht nur der "Bestand". Nach mehr als 10 Jahren und 2 Büchern darüber fühle ich mich dem Gesamtbild verpflichtet, und das umfasst auch "Simplicity first"
LG
pah
Zitat von: Starkstrombastler am 11 Januar 2024, 14:39:21Zitat von: flummy1978 am 11 Januar 2024, 13:48:31Frage zu shellyplus2pm:
Wir behandeln in diesem Thread die Einbindung der Shellies mit dem Shelly-Modul (36_Shelly.pm). Dein Device ist aber als MQTT-Device definiert - da musst du bitte an anderer Stelle suchen.
Da hast Du Recht ... Hab falsch geschaut ich danke Dir
Zitat von: Starkstrombastler am 11 Januar 2024, 15:05:40Also zurück. Mit dem nächsten Update wird set ... pct wieder im Dropdown-Menu erscheinen und die Hinweise im Log verschwinden auch wieder.
Was passiert mit dem Reading position?
Zitat von: ToKa am 12 Januar 2024, 18:01:44Was passiert mit dem Reading position?
Nix.
Die
diskutierte Änderung ist vom Tisch. Es verhält sich nach wie vor wie das Reading
pct, mit dem Unterschied, dass in den Endlagen
open bzw.
closed eingetragen wird.
Da ich den Überblick verloren habe folgende Frage:
Ich nutze 36_Shelly.pm in der Version "4.06e 13.07.2023", das Update ist derzeit ausgeschlossen. Sind die damaligen Änderungen inzwischen in die "normale" Version eingeflossen? Anders gefragt: Kann ich das Update für 36_Shelly.pm wieder anschalten?
Zitat von: curt am 13 Januar 2024, 17:45:58Kann ich das Update für 36_Shelly.pm wieder anschalten?
Ja.
Das Modul 36_Shelly.pm ist seit einigen Wochen wieder regulär verfügbar.
@Starkstrombastler
Danke. Ich versuche ein kleineres Intervall.
vb
Zitat von: VB90 am 15 Januar 2024, 21:17:00Ich versuche ein kleineres Intervall.
...und warum keine Actions?
Dank Empfehlung im anderen Thread habe ich nun ein shelly3em, das hat der Elektriker bereits in den Stromkasten eingebaut. Leider verstehe ich einige Dinge nicht.
Insbesondere habe ich Schwierigkeiten, die vielen Readings zu interpretieren, was bedeuten die denn alle? Gibt es da vielleicht eine erklärende Liste zu?
Ich suche die gesamte vorzeichenlose Energieabnahme (also über alle drei Phasen). Ist das energyReturned_TTL?
Und da lacht mich ein Schalter an, ich kann da etwas ein- und ausschalten. Aktuelles state ist "off". Aber was schalte ich denn da konkret?
(Nein, ich trau mich nicht. Anschließend ist das Haus ausgeschaltet und geht nicht mehr an...)
Zitat von: curt am 16 Januar 2024, 22:18:31Dank Empfehlung im anderen Thread habe ich nun ein shelly3em, das hat der Elektriker bereits in den Stromkasten eingebaut. Leider verstehe ich einige Dinge nicht.
Insbesondere habe ich Schwierigkeiten, die vielen Readings zu interpretieren, was bedeuten die denn alle? Gibt es da vielleicht eine erklärende Liste zu?
Ich suche die gesamte vorzeichenlose Energieabnahme (also über alle drei Phasen). Ist das energyReturned_TTL?
Und da lacht mich ein Schalter an, ich kann da etwas ein- und ausschalten. Aktuelles state ist "off". Aber was schalte ich denn da konkret?
(Nein, ich trau mich nicht. Anschließend ist das Haus ausgeschaltet und geht nicht mehr an...)
Hallo,
hat der Elektriker die Bedienungsanleitung mitgenommen?
Eine Übersicht: https://shelly-api-docs.shelly.cloud/gen1/#shelly-gas-settings
Grüße Jörg
PS: Ein Hallo und ein Danke, dass ihr mir helft wäre wirklich nett.
Der 3EM hat ein Relais, das wird geschaltet.
Wenn du da nichts angeschlossen hast, passiert auch nichts...
Außer: klackendes Relais und das "Lämpchen" in der Oberfläche.
Eine Gesamtleistung etc. gibt es nicht.
Aber das geht mit einem simplen userReadings...
Welche Readings verstehst du nicht?
Ist doch eigentlich eindeutig?
Immer pro "Messpunkt" (Phase): Spannung, Strom, Leistung und Energie...
Du hast den 3EM schon mittels Shelly Modul eingebunden und nicht mqtt?
(da gibt es u.U. andere/mehr Readings?)
Gruß, Joachim
Mal vorab: Ich weiß nicht, wie ich noch formulieren soll, damit sich wirklich niemand auf den Schlips getreten fühlt. Ich meine schon, dass ich neutral und höflich frug.
Zitat von: JoWiemann am 16 Januar 2024, 22:45:58hat der Elektriker die Bedienungsanleitung mitgenommen?
Eine Übersicht: https://shelly-api-docs.shelly.cloud/gen1/#shelly-gas-settings
PS: Ein Hallo und ein Danke, dass ihr mir helft wäre wirklich nett.
Hallo Jörg,
ich danke herzlich für Deinen Beitrag, der eher keine Hilfe war: Die in der Packung beiliegende Anleitung hat tatsächlich der Elektriker mitgenommen. Allerdings waren da im Wesentlichen nur Einbauhinweise. Den genannten Link kannte ich nicht, allerdings tauchen die Readings dort nicht auf.
Und zu Deiner persönlichen Ansprache:
Vor drei Tagen in dem von mir initiierten Frage-Thread https://forum.fhem.de/index.php?topic=136647.0 habe ich bei jeder für mich hilfreichen Antwort "gefällt mir" geklickt, zusätzlich mich dann in einem abschließenden Beitrag bedankt. Das einführende "Hallo" ist in vielen Foren verpönt. Meist wird erwartet, kurz und präzise seine Frage(n) zu stellen. Aber ich werde versuchen, mich entsprechend Deiner Hinweise anzupassen.
Danke.
Zitat von: MadMax-FHEM am 16 Januar 2024, 23:25:55Der 3EM hat ein Relais, das wird geschaltet.
Wenn du da nichts angeschlossen hast, passiert auch nichts...
Außer: klackendes Relais und das "Lämpchen" in der Oberfläche.
Danke für die Erläuterung, ich bin beruhigt.
Zitat von: MadMax-FHEM am 16 Januar 2024, 23:25:55Eine Gesamtleistung etc. gibt es nicht.
Aber das geht mit einem simplen userReadings...
Ich suche das Reading, welches umgangssprachig "in meinem Haus werden derzeit 1,23 kW verbraucht/abgenommen" abbildet. (Notfalls die drei, die ich addieren muss.)
Zitat von: MadMax-FHEM am 16 Januar 2024, 23:25:55Welche Readings verstehst du nicht?
Ist doch eigentlich eindeutig?
Immer pro "Messpunkt" (Phase): Spannung, Strom, Leistung und Energie...
Ich habe im Studium vor gut 30 Jahren mal zwei Semester E-Technik gehört. Aber das hilft wenig. Offen gesagt verstehe ich die Bedeutung der meisten Readings nicht. Ich weiß nicht, was apparentpower, current, energyReturned, energy, powerFactor, power, reactivepower bedeutet, auch für was TTL in diesem Zusammenhang steht, ist mir nicht klar.
Total_Energy hat einen negativen Wert, energyReturned_TTL ist der gleiche Wert, vorzeichenlos. Klar ist mir auch das nicht.
Frei loszuraten scheint mir wenig sinnvoll. Aber darauf scheint es hinauszulaufen, ich traue mich kaum noch zu fragen: Es gibt gute Chancen, erstmal einen Anranzer zu bekommen, siehe oben.
Zitat von: MadMax-FHEM am 16 Januar 2024, 23:25:55Du hast den 3EM schon mittels Shelly Modul eingebunden und nicht mqtt?
Gruß, Joachim
Ja, natürlich das Shelly-Modul, ich bin im richtigen Thread.
Folgend ein List, damit jeder sehen kann, was bei mir an Readings vorhanden ist:
DEF 192.168.x.y
FUUID [...]
INTERVAL 60
NAME Hausanschluss
NR 2039
STATE off
TCPIP 192.168.x.y
TYPE Shelly
eventCount 10
units 0
READINGS:
2024-01-16 23:56:00 Total_Energy -2234.6
2024-01-16 23:56:00 apparentpower_0 152.0
2024-01-16 23:56:00 apparentpower_1 123.3
2024-01-16 23:56:00 apparentpower_2 381.6
2024-01-16 19:11:47 cloud disabled
2024-01-16 19:11:55 coiot enabled
2024-01-16 19:11:55 coiot_period 15
2024-01-16 23:55:00 current_0 0.67
2024-01-16 23:55:00 current_1 0.54
2024-01-16 23:56:00 current_2 1.68
2024-01-16 23:56:00 energyReturned_0 735.6
2024-01-16 23:56:00 energyReturned_1 365.5
2024-01-16 23:56:00 energyReturned_2 1133.5
2024-01-16 23:56:00 energyReturned_TTL 2234.6
2024-01-16 19:11:47 energy_0 0
2024-01-16 19:11:47 energy_1 0
2024-01-16 19:11:47 energy_2 0
2024-01-16 19:11:47 energy_TTL 0
2024-01-16 19:11:47 firmware v1.14.0
2024-01-16 19:11:55 name Hausanschluss
2024-01-16 19:11:47 network <html>connected to <a href="http://192.168.x.y">192.168.x.y</a></html>
2024-01-16 22:26:35 network_rssi -58
2024-01-16 19:11:47 network_ssid [SSID]
2024-01-16 19:11:55 network_threshold -70
2024-01-16 19:11:47 overpower_0 off
2024-01-16 19:11:47 overpower_1 -
2024-01-16 19:11:47 overpower_2 -
2024-01-16 23:55:00 powerFactor_0 -0.46
2024-01-16 23:49:56 powerFactor_1 -0.93
2024-01-16 23:56:00 powerFactor_2 -0.72
2024-01-16 23:56:00 power_0 -69.93
2024-01-16 23:56:00 power_1 -114.63
2024-01-16 23:56:00 power_2 -274.72
2024-01-16 23:56:00 power_TTL -459.28
2024-01-16 23:56:00 power_TTLc -459.28
2024-01-16 23:56:00 reactivepower_0 135.0
2024-01-16 23:56:00 reactivepower_1 45.4
2024-01-16 23:56:00 reactivepower_2 264.9
2024-01-16 19:11:47 relay off
2024-01-16 19:11:47 source input
2024-01-16 19:11:47 state off
2024-01-16 19:11:47 timer 0
2024-01-16 23:56:00 voltage_0 229.87
2024-01-16 23:56:00 voltage_1 230.18
2024-01-16 23:56:00 voltage_2 229.63
2024-01-16 19:11:39 webhook_cnt 0
2024-01-16 19:11:39 webhook_ver 0
helper:
Sets config interval password reboot:noArg update:noArg name reset:disconnects on off toggle on-for-timer off-for-timer
Attributes:
model shelly3em
room Shelly
Hallo
Hatte mich letztes Jahr beim Einbau auch geärgert, dass die Anleitung sich zu den Bedienelemeten ausschweigt und man Online schon ein wenig rumsuchen muß.
- der Taster ist Reset
- die LED am Taster zeigt den Status von Cloud, AP und WiFi
- die obere LED kann wohl mit aktueller Firmware als Verbrauchsanzeige konfiguriert werden
Gruß Ralf
Auf die Schnelle zu deinen Readings:
energyReturned ist Richtung EVU (Einspeisung) und energy die verbrauchten kWh. Die TTL-Werte sind die vom Modul errechneten Werte über drei Phasen.
Offensichtlich sind aber die Messwandler verkehrt herum eingebaut, da dein Verbrauch als Einspeisung gezählt wird und die Leistung negativ.
Da muss der Elektriker noch mal ran.
Gruß Ralf
Edit:
Schau mal in die Hilfe, da hat Starkstrombastler einiges zu Readings beschrieben.
Wenn du das Modul Shelly-Monitor nicht nutzt kannst du das Coiot-Protokoll abschalten. Dann schickt der Shelly keine Daten ins WLAN (die du ggfs. nicht auswertest).
Zitat von: curt am 17 Januar 2024, 00:25:55Folgend ein List, damit jeder sehen kann, was bei mir an Readings vorhanden ist:
Da sind zum Einen die Leistungs-Readings:
power - Leistung
reactivepower - Blindleistung
apparentpower - Scheinleistung
und die Energy-Readings:
energy - bezogene Energie
energyReturned - eingespeiste Energie
die Indizes 0,1,2 sind die drei Phasen, und TTL ist die Summe davon.
Total_Energie ist die Summe von 'energy - energyReturned'
power_TTLc ist die aus den Energy-Readings berechnete durchschnittliche Leistung im letzten Intervall.
Das ganze setzt aber den korrekten Einbau der Wandler voraus.
Einheiten werden mit dem Attribut showunits sichtbar gemacht.
Zitat von: RalfRog am 17 Januar 2024, 00:57:51Offensichtlich sind aber die Messwandler verkehrt herum eingebaut, da dein Verbrauch als Einspeisung gezählt wird und die Leistung negativ. Da muss der Elektriker noch mal ran.
Wichtiger Hinweis, ich hätte mangels Vergleich das nicht erkennen können.
Zitat von: RalfRog am 17 Januar 2024, 00:57:51Wenn du das Modul Shelly-Monitor nicht nutzt kannst du das Coiot-Protokoll abschalten. Dann schickt der Shelly keine Daten ins WLAN (die du ggfs. nicht auswertest).
Das gibt es aber nicht bei den 1PMplus und 2PMplus? Ich kannte das nicht, habe mich eingelesen. Und dann abgeschaltet.
@Starkstrombastler
Nun verstehe ich die Readings.
Danke euch beiden.
Zitat von: Starkstrombastler am 15 Januar 2024, 21:19:57Zitat von: VB90 am 15 Januar 2024, 21:17:00Ich versuche ein kleineres Intervall.
...und warum keine Actions?
Ich hatte keine große Zeit mich mit dem Shelly auseinander zu setzen.
Ich habe jetzt mal eine Action eingetragen, bislang sieht das gut aus.
Danke.
vb
Zitat von: VB90 am 19 Januar 2024, 22:29:22Ich hatte keine große Zeit mich mit dem Shelly auseinander zu setzen.
Das geht jedem irgendwie so. Niemand kann sich mit allem intensiv auseinandersetzen.
Zitat von: VB90 am 19 Januar 2024, 22:29:22Ich habe jetzt mal eine Action eingetragen, bislang sieht das gut aus.
Wir sind eine Gemeinschaft von Lernenden:
Kannst Du bitte freundlicherweise erörtern, was Dein Ziel war und wie Du das (mit Code-Beispiel) umgesetzt hast?
Ich nutze manchmal einen ShellyPlugPlus - funktioniert. Meistens liegt der Plug aber in der Schublade, müßte also disabled werden. Dazu habe ich gemäß Doku das Attribut interval auf 0 gesetzt. Trotzdem gibt's (beim fhem Booten) einige Fehlermeldungen:
2024.01.22 13:34:49 1: [Shelly_webhook] Device ShellyPlug has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2024.01.22 13:34:58 1: [Shelly_status] Device ShellyPlug has Error 'not connected (no route)', state is set to 'Error: Network'
2024.01.22 13:35:02 1: [Shelly_webhook] Error ShellyPlug: network status is not connected
2024.01.22 13:35:05 1: [Shelly_status] Device ShellyPlug has Error 'not connected (no route)', state is set to 'Error: Network'
2024.01.22 13:35:05 1: [Shelly_status] Device ShellyPlug has Error 'not connected (no route)', state is set to 'Error: Network'
2024.01.22 13:35:05 1: [Shelly_status] Device ShellyPlug has Error 'not connected (no route)', state is set to 'Error: Network'Gibt es noch eine weitere Einstellung, um den Plug temporär vollständig zu deaktivieren (ohne Fehlermeldungen)?
Grüßle, Michael
Die Meldung gibt es aber dann nur beim fhem-Start bzw. Initialisierung des Devices?
Das Attribut interval wirkt erst danach, denke ich.
Also fhem startet, Device wird initialisiert und versucht den Shelly zu erreichen -> geht schief -> Meldung.
Danach greift das Attribut und es sollte Ruhe sein, ist zumindest bei mir so, bei den Shelly die ich nur temporär nutze...
Gruß, Joachim
Zitat von: olwaldi am 24 Januar 2024, 14:17:44Meistens liegt der Plug aber in der Schublade, müßte also disabled werden. Dazu habe ich gemäß Doku das Attribut interval auf 0 gesetzt. Trotzdem gibt's (beim fhem Booten) einige Fehlermeldungen:
Danke für den Hinweis.
Mit dem nächsten Update wird vor der Abfrage von Statusinformationen des Shelly eine Abfrage des Attributes Interval durchgeführt. Die Fehlermeldungen beim Starten sollten damit nicht mehr auftreten.
Zitat von: MadMax-FHEM am 24 Januar 2024, 15:14:55Also fhem startet, Device wird initialisiert und versucht den Shelly zu erreichen -> geht schief -> Meldung.
Danach greift das Attribut und es sollte Ruhe sein, ist zumindest bei mir so, bei den Shelly die ich nur temporär nutze...
Stimmt - ist also wirklich "Jammern" auf hohem Niveau meinerseits. Aber Starkstrombastler wird's nichtsdestotrotz fixen.
Danke, Michael
Zitat von: curt am 23 Januar 2024, 03:24:01Zitat von: VB90 am 19 Januar 2024, 22:29:22Ich hatte keine große Zeit mich mit dem Shelly auseinander zu setzen.
Das geht jedem irgendwie so. Niemand kann sich mit allem intensiv auseinandersetzen.
Zitat von: VB90 am 19 Januar 2024, 22:29:22Ich habe jetzt mal eine Action eingetragen, bislang sieht das gut aus.
Wir sind eine Gemeinschaft von Lernenden:
Kannst Du bitte freundlicherweise erörtern, was Dein Ziel war und wie Du das (mit Code-Beispiel) umgesetzt hast?
In erster Linie war mir das Intervall der Aktualisierung zu lang.
Ich habe lediglich das Beispiel von oben an meine Device angepasst und war damit erfolgreich.
Allerdings ist diese Lösung nach meiner Meinung nicht perfekt.
So wie ich mich kenne, weißt ich davon in nem Jahr nix mehr.
Tauchen dann Probleme auf, oder ich muss den shelly tauschen, suche ich mich wund.
Um das zu verhindern, habe ich gern absolut alles im fhem.
vb
Wir haben mehrere Shellys im Einsatz.
bei den Shelly plus 2PM gibt es neben on und off (klein geschrieben) auch ON und OFF (groß geschrieben).
In der Hilfe steht folgendes:
Bei bestimmten Shelly Modellen können URLs (Webhooks) festgelegt werden, welche bei Eintreten bestimmter Ereignisse ausgelöst werden. Beispielsweise lauten die Webhooks für die Information über die Betätigung lokaler Eingänge wie folgt:
Button switched ON url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20<Devicename>%20button_on%20[<channel>]
Button switched OFF url: http://<FHEM IP address>:<Port>/fhem?cmd=set%20<Devicename>%20button_off%20[<channel>]
Das bedeutet, wenn ich ein ON sende ist es für den Shelly wie wenn ich den angeschlossenen Taster betätige und
on sich verhält wie wenn ich auf der Shelly-Weboberfläche einschalte.
Wir haben bei uns eine Deckenbeleuchtung, welche zwei separate Stromkreise hat.
Normal sollen beide Stromkreise mit einen Wechselschalter geschaltet werden.
Dies haben wir mit den Shelly Plus 2PM so gelöst, dass der letzte Schalter der Wechselschaltung auf den Eingang 1 des Shelly geht.
Direkt im Shelly sind dann Regeln programmiert, dass wenn Schalter Kontakt 1 an dann auch Kontakt 2 an und ebenso bei aus. In FHEM würde das ON und OFF entsprechen.
Um die Kanäle direkt in FHEM anzusprechen wurde mit set xtrachannels zwei neue Geräte erstellt.
In FHEM kann ich nun mit ON/OFF die ganze Decke steuern und mit on/off in den beiden Geräten jeweils einzeln steuern.
Neu möchten wir nun gerne beide Kanäle einzeln und auch gleichzeitig mit Sprache und Alexa schalten.
Über Alexa bekomme ich jedoch nur ein on bzw. off, jedoch kein ON/OFF.
Mit Attribut defchannel kann ich einen Kanal bzw. Relais für on/off zuweisen aber nicht beide gleichzeitig.
Ich sehe nun zwei Lösungsmöglichkeiten, die ich aber beide nicht umsetzen kann:
a) Ich bekomme die Meldung von Alexa von on auf ON und von off auf OFF umgeändert
b) Oder on und off sende auf beide Kanäle des Shelly
Oder es gibt eine andere Lösung.
Wer kann mir helfen?
ON/OFF bei Alexa sollte mittels homebridgeMapping möglich sein?
Evtl. geht auch eventMap, nutze ich aber selbst nicht...
Gruß, Joachim
Zitat von: teufelchen am 06 Februar 2024, 06:09:24Neu möchten wir nun gerne beide Kanäle einzeln und auch gleichzeitig mit Sprache und Alexa schalten.
Ich schlage vor das mittels Alexa-Routinen zu lösen. Dazu die beiden readingsProxy-Devices jeweils als Alexa-Gerät definieren. Damit können die beiden Kanäle unabhängig voneinander via Alexa geschaltet werden.
Dann in der Alexa-App zwei Routinen "schalte das Licht im Wohnzimmer ein" bzw. "aus" definieren und die zuvor definierten Alexa-Geräte mit entsprechenden Befehlen hinzufügen.
@ Starkstrombastler: Ich mag keine Routinen in der Alexa-App. Einerseits weil die Weboberfläche mittels PC nicht mehr unterstützt wird. Und weil ich das dann jeweils im Profil von meiner Frau und mir einrichten muss.
@ MadMax-FHEM: Danke für den Hinweis, ich versuche gerade zu verstehen wie ich das damit umsetzen kann.
Als weitere Lösung würde mir ein von Alexa geschalteter Dummy einfallen der dann über ein Notify die Übersetzung von Dummy "on" auf Shelly "ON" und off auf OFF vornimmt.
Aktuell scheint mir der Ansatz mit homebridgeMapping am "schlankesten" umsetzbar.
Der einfachste Ansatz besteht hier im Einsatz von LightScene. Das Wohnzimmer kennt damit vier verschiedene Szenen: Alle_an,Esstisch,Sitzgruppe,Zu_Dunkel. In Alexa werden einfach entsprechende Räume definiert, und schon geht das.
Ist bei mir mit bis zu 6 Szenen für 8 Leuchten in Betrieb und funktioniert seit etwa 2014 wunderbar.
LG
pah
Moin,
ich bekomme in schöner Regelmäßigkeit diese Meldungen im Log - hat das was zu beduten? Die Devices funktionieren trotzdem soweit ohne Probleme
2024.02.11 13:11:38.124 2: [Shelly_Set] stored keys for device ShellyPlugS_Kueche_LichtArbeitsflaeche "config interval password reboot:noArg update:noArg name reset:disconnects on off toggle on-for-timer off-for-timer" in helper
2024.02.11 13:11:38.139 2: [Shelly_Set] stored keys for device Shelly1_GaesteWC_Fenster "config interval password reboot:noArg update:noArg name reset:disconnects on off toggle on-for-timer off-for-timer" in helper
Gruß, Christoph
Zitat von: caldir65 am 11 Februar 2024, 13:57:03ich bekomme in schöner Regelmäßigkeit diese Meldungen im Log - hat das was zu beduten?[Shelly_Set] stored keys for device ... in helper
Ja klar hat das was zu bedeuten: nämlich genau das, was da geschrieben ist. Die Meldung sollte aber nur einmalig nach einem Neustart bzw. define/modify kommen.
Ansonsten ist das aber kein Grund zur Sorge, das Ablegen der Keys in einem Helper ist eine Abkürzung und spart deren Ermittlung beim nächsten Abruf durch FHEMWEB.
Ok danke. Ich hatte nur durch ein anderes Modul Abstürze, und dan diese Meldung halt direkt danach kamen, wollte ich mich nur vergewissern...
Gruß, Christoph
Ich habe ein paar grundsätzliche Fragen zu den Shelly Plus Devices (ganz speziell zum Shelly Plus Plug S)
Mir ist in der Web-Oberfläche des Device aufgefallen, dass dort angezeigt wird, was den letzten Schaltbefehl ausgelöst hat. Hier steht dan so etwas "Last triggered by Http" oder "Last triggered by Button". Ich würde diese Unterscheidung gerne dafür nutzen, um eine Auslösung per Button einem Schaltbefehl per FHEM (http) vorzuziehen. Die Frage wäre: Kann das Modul diesen "Last triggered by" auch als Reading ausgeben?
Dann ist mir noch aufgefallen, dass das Reading "power" nur ausgegeben wird, wenn man im Webinterface des Shelly Plus Plug S unter den Einstellungen im Bereich MQTT die Option "Generic status update over MQTT" einschaltet. Die Frage hier wäre: Welche Einstellungen (Enable 'MQTT Control', Enable RPC over MQTT, RPC status notifications over MQTT und Generic status update over MQTT) wirken sich auf das Modul aus bzw. sind für den korrrekten Betrieb des Moduls notwendig?
Über ein paar Antworten würde ich mich sehr freuen.
Viele Grüße
Holger
Zitat von: gent am 12 Februar 2024, 23:22:10Mir ist in der Web-Oberfläche des Device aufgefallen, dass dort angezeigt wird, was den letzten Schaltbefehl ausgelöst hat.
Im Shelly-Modul wird der Auslöser des letzten Schaltens im Reading "source" ausgegeben.
Zitat von: gent am 12 Februar 2024, 23:22:10Dann ist mir noch aufgefallen, dass das Reading "power" nur ausgegeben wird, wenn man im Webinterface des Shelly Plus Plug S unter den Einstellungen im Bereich MQTT die Option "Generic status update over MQTT" einschaltet.
Das hört sich so an, als ob du garnicht das Shelly-Modul nutzt, sondern die Einbindung via MQTT. Dann müsstest du an anderer Stelle hier im Forum suchen.
Alternativ bist du natürlich gerne eingeladen, das Shelly-Modul zu nutzen:
define <name> Shelly <ip-adresse>
Hallo zusammen,
Bin seit Jahren passiver Mitleser hier im Forum, aber nun bin ich irgendwie mit meinem Latein am Ende. Aktuell versuche ich neue Shelly Plus2PM einzubinden und stoße auf merkwürdige Phänomene. Der SW-Stand der neuen Shellys ist 1.2.0.
Für meine Automationspläne soll der Shelly beim Anzug und Abfall eines seiner Relais ein Get-Request an FHEM senden, es sieht bspw. so aus:
http://<URL und Port>/fhem?cmd=setreading%20Schlafzimmer%20mitnehmer%20on&XHR=1
Dies habe ich unter "Actions" hinterlegt und es wird auch beim Anzug des Relais abgesendet. Mit den Gen 1 Shellys ging so etwas immer problemlos mit genau einem Request. Mit den Shelly Plus2PM geschieht jedoch etwas merkwürdiges, der Shelly wiederholt eigenständig diese Sendung insgesamt 3 Mal im exakten Abstand von jeweils 16 Sekunden.
Ich habe das mit 2 Shelly Plus2PM probiert mit demselben Ergebnis. Ich habe auch andere IP-Adressen in meinem System angesprochen (mit dazu passenden Get-Requests natürlich), um FHEM als Fehlerquelle auszuschließen. Auch so finden die genannten Wiederholungen statt.
Gibt es hierzu bereits Erfahrungen? Vielleicht interessiert das auch die Shelly Entwickler...
Grüße aus meiner Home Automation Bastelstube sendet
Wolfgang
Zitat von: Wolfgang Lachmann am 15 Februar 2024, 20:25:24Hallo zusammen,
Bin seit Jahren passiver Mitleser hier im Forum, aber nun bin ich irgendwie mit meinem Latein am Ende. Aktuell versuche ich neue Shelly Plus2PM einzubinden und stoße auf merkwürdige Phänomene. Der SW-Stand der neuen Shellys ist 1.2.0.
Für meine Automationspläne soll der Shelly beim Anzug und Abfall eines seiner Relais ein Get-Request an FHEM senden, es sieht bspw. so aus:
http://<URL und Port>/fhem?cmd=setreading%20Schlafzimmer%20mitnehmer%20on&XHR=1
Dies habe ich unter "Actions" hinterlegt und es wird auch beim Anzug des Relais abgesendet. Mit den Gen 1 Shellys ging so etwas immer problemlos mit genau einem Request. Mit den Shelly Plus2PM geschieht jedoch etwas merkwürdiges, der Shelly wiederholt eigenständig diese Sendung insgesamt 3 Mal im exakten Abstand von jeweils 16 Sekunden.
Lass mal
&XHR=1 weg
Hallo Starkstrombastler,
schnell probiert und schon klappt's! Ich wollte eigentlich mein WLAN von unnötigem HTML-Müll entlasten, den sowieso keiner liest!
Die Gen 1 Shellys mögen das...
Also: It's not a bug, it's a feature.
Vielen Dank jedenfalls für die schnelle Hilfe.
Schönen Abend noch
Wolfgang
Hallo,
Ich bin neu hier im Forum, lese aber schon eine ganze Weile mit und habe bisher immer eine Lösung für meine Probleme gefunden. Jetzt finde ich keine Möglichkeit für die Einbindung eines Shelly Plus Uni.
Hat schon jemand einen Shelly Plus Uni eingebunden?
Das Shelly Modul hat diesen Shelly noch nicht zur Auswahl im model Attribut.
Ist es geplant diesen im Modul aufzunehmen?
Hat jemand Erfahrung mit der Einbindung mittels MQTT?
Vielen Dank
lg
Christian
Zitat von: ChristianP5r am 16 Februar 2024, 19:25:41Das Shelly Modul hat diesen Shelly noch nicht zur Auswahl im model Attribut.
Ist es geplant diesen im Modul aufzunehmen?
Ja, kommt, aber erst Ende Februar.
Hallo zusammen,
der Shelly RGBW2 kennt zum Dimmen kein dimup/dimdown sondern nur pct.
Jemand von euch schon was gebastelt um mittels eines Schalters (Tradfri) hoch und runter zu dimmen?
Gruss Gerd
Zitat von: GeZi3560 am 21 Februar 2024, 14:17:40der Shelly RGBW2 kennt zum Dimmen kein dimup/dimdown sondern nur pct.
Das aktuelle Shelly-Modul bietet sehr wohl dimup / dimdown für den RGBW2 im White-Mode. Ist dein FHEM aktuell?
Danke für deinen Input.
Habe die aktuelle FHEM version (extra nochmal einen Update all gefahren) und aktuelle Firmware des RGBW2.
Template ist das Shelly2RGBW-4W-Split
dimup / dimdown ist weder in der Set Auswahl noch wir es als manuelles set angenommen.
" Unknown argument dimup, choose one of off on pct pct_on off-till-overnight off-for-timer off-till on-till on-for-timer on-till-overnight toggle blink intervals attrTemplate"
Was mir auffällt ist das Attribut Template "attrTemplateVersion 20210103", passt das ?
Gruss Gerd
defmod MQTT2_shellyrgbw2_98CDAC266DA2 MQTT2_DEVICE shellyrgbw2_98CDAC266DA2
attr MQTT2_shellyrgbw2_98CDAC266DA2 autocreate 0
attr MQTT2_shellyrgbw2_98CDAC266DA2 comment Channel 1 for MQTT2_shellyrgbw2_98CDAC266DA2, see also MQTT2_shellyrgbw2_98CDAC266DA2_CH2, MQTT2_shellyrgbw2_98CDAC266DA2_CH3 and MQTT2_shellyrgbw2_98CDAC266DA2_CH4
attr MQTT2_shellyrgbw2_98CDAC266DA2 icon light_control
attr MQTT2_shellyrgbw2_98CDAC266DA2 model shelly2rgbw_4w_split
attr MQTT2_shellyrgbw2_98CDAC266DA2 readingList shellies/shellyrgbw2-98CDAC266DA2/white/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
shellies/shellyrgbw2-98CDAC266DA2/white/0:.* state\
shellies/shellyrgbw2-98CDAC266DA2/white/0/set:.* { json2nameValue($EVENT) }\
shellies/shellyrgbw2-98CDAC266DA2/online:.* online\
shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-98CDAC266DA2...mac.*, ? json2nameValue($EVENT) : return }
attr MQTT2_shellyrgbw2_98CDAC266DA2 room MQTT2_DEVICE
attr MQTT2_shellyrgbw2_98CDAC266DA2 setList off:noArg shellies/shellyrgbw2-98CDAC266DA2/white/0/command off\
on:noArg shellies/shellyrgbw2-98CDAC266DA2/white/0/command on\
pct:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-98CDAC266DA2/white/0/set {"mode":"white","brightness":"$EVTPART1"}\
pct_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-98CDAC266DA2/white/0/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}\
x_update:noArg shellies/shellyrgbw2-98CDAC266DA2/command update_fw\
x_mqttcom shellies/shellyrgbw2-98CDAC266DA2/command $EVTPART1
attr MQTT2_shellyrgbw2_98CDAC266DA2 setStateList on off
attr MQTT2_shellyrgbw2_98CDAC266DA2 webCmd on:off:pct
setstate MQTT2_shellyrgbw2_98CDAC266DA2 on
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:18:02 IODev myBroker
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:19:28 associatedWith MQTT2_shellyrgbw2_98CDAC266DA2_CH2,MQTT2_shellyrgbw2_98CDAC266DA2_CH3,MQTT2_shellyrgbw2_98CDAC266DA2_CH4
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:19:27 attrTemplateVersion 20210103
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 brightness 1
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 has_timer false
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 ison true
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 mode white
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:19:28 online true
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 overpower false
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 power 0.77
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 source http
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 state on
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 timer_duration 0
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 timer_remaining 0
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 timer_started 0
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:37:32 transition 0
setstate MQTT2_shellyrgbw2_98CDAC266DA2 2024-02-22 09:19:28 x_mqttcom set x_mqttcom announce
Zitat von: GeZi3560 am 22 Februar 2024, 09:33:48Template ist das Shelly2RGBW-4W-Split
Das hatten wir hier schon öfter: In diesem Thread behandeln wir das Shelly-Modul, welches via
HTTP mit den Shellies kommuniziert. Für deine Problemstellung musst du bitte an anderer Stelle im Forum suchen oder du probierst das Modul aus:
define <name> Shelly <ip-adresse>
Dass FHEM-User keine Doku lesen können, ist bekannt. Neuerdings aber werden nicht mal mehr die Überschriften gelesen. Oder liegt das daran, dass zu viele MQTT verwenden, obwohl sie davon eigentlich nichts verstehen?
LG
pah
Moin,
ich habe so bisher nichts gefunden - unterstützt das Modul eigendlich den ShellyPlus H&T (mit Display)?
Gruß, Christoph
Zitat von: caldir65 am 23 Februar 2024, 17:47:31unterstützt das Modul eigendlich den ShellyPlus H&T (mit Display)?
Vom Shelly-Modul werden bisher keine batteriebetriebenen Devices unterstützt, weil das regelmäßige Pollen der Standzeit nicht zuträglich ist.
Da
Temperature und
Humidity auch vom
Shelly Plus Uni abgebildet werden, wird die Integration des
Plus H&T im Zusammenhang mit der Integration des neuen
Uni zur Verfügung stehen.
Bitte dazu in diesem neuen Thread (https://forum.fhem.de/index.php?topic=137222.0) die Antworten des Shelly posten.
Moin,
danke für Deine Info. Leider habe ich das Device (noch?) nicht, kann daher leider auch noch keine Meldungen liefern...
Gruß, Christoph
Ich habe nun wie in #840 vorgeschlagen meine RGBW2 mit dem Shelly Modul angebunden und es funktioniert wie gewünscht.
Danke für den Hinweis. Ich werde mich intensiver mit dem Modul beschäftigen.
Das RGBW Modul hängt bei mir hinter einem Switch der das Netzteil und somit das RGBW2 Modul Stromlos schaltet.
Das hat nun zu Folge das mein Log mit
"
2024.02.29 12:08:24 1: [Shelly_status] Device ShellyDimmer has Error 'not connected (no route)', state is set to 'Error: Network'
überflutet wurde.
Abhilfe hat das Attr Interval 0 gebracht. Was nun aber auch zu Folge hat das keine Reading updates mehr kommen.
Aber, auch andere Shellys welche offline sind (angebunden über MQTT) melden nun diesen Fehler.. haben aber kein Attr Interval das gesetzt werden kann.
Es ist wie immer, wenn man ein Thema löst, macht man zwei andere Baustellen auf. :-)
zu Kommentar #841: Wenn ich gemeint bin. Ich war mit nicht bewusst das es das Shelly Modul gibt. Ich nutze Shellys seit ca. 4 Jahren problemlos mit MQTT und hatte deshalb auch keinen Bedarf nach zu suchen ob es andere Möglichkeiten gibt.
Zitat von: GeZi3560 am 29 Februar 2024, 12:24:13Das hat nun zu Folge das mein Log mit
"
2024.02.29 12:08:24 1: [Shelly_status] Device ShellyDimmer has Error 'not connected (no route)', state is set to 'Error: Network'
überflutet wurde.
Für genau dieses Problem wird das nächste (große) Update des Moduls das Intervall bei Netzwerkausfall kontinuierlich erhöhen, so dass am Ende nur noch bspw. alle 12 Stunden ein Verbindungsversuch gestartet wird, mit ensprechend reduzierten Logs bei Nichterreichbarkeit. Zum Update siehe den oben verlinkten Entwicklungsthread, aber das wird bestimmt noch zwei Wochen dauern.
Edit:
Zitat von: GeZi3560 am 29 Februar 2024, 12:24:13Abhilfe hat das Attr Interval 0 gebracht. Was nun aber auch zu Folge hat das keine Reading updates mehr kommen.
Du kannst das Intervall mit einem at o.ä. entsprechend deinen Schaltvorgängen anpassen und folgende Befehle senden:
set <name> interval 0 oder
set <name> interval -1.
Alternativ kannst du für das RGBW-Device den verbose level auf 0 stellen.
Hallo,
ich habe mir ein Shelly 1 vor meine Heizkreispumpe gebaut, das die Pumpe abschaltet, wenn die alle Ventile der Heizkreise der Fußbodenheizung geschlossen sind.
Nun bekomme ich permanent Fehlermeldungen:
[Shelly_Set] calling for device KG_FBH_Pumpe_Heizraum with command 'on', no parameter
[Shelly_Set] calling for device KG_FBH_Pumpe_Heizraum with command 'off', no parameterDas Schalten klappt, so wie es soll, nur die Fehlermeldungen brauche in nicht im Log.
Das List des Device lautet wie folgt:
Internals:
DEF 192.168.2.194
FUUID 65c22f29-f33f-aab4-736c-045d2b765414ae0d
INTERVAL 300
NAME KG_FBH_Pumpe_Heizraum
NR 1826
STATE on
TCPIP 192.168.2.194
TYPE Shelly
eventCount 137
units 0
READINGS:
2024-03-05 09:33:00 cloud enabled(connected)
2024-02-05 16:21:54 coiot enabled
2024-02-05 16:21:54 coiot_period 15
2024-02-12 14:32:56 current 0.069
2024-02-12 14:32:56 energy 4245.603
2024-02-12 14:35:51 firmware v1.14.1-rc1(update needed to v1.14.0)
2024-02-12 14:14:06 frequency 50
2024-03-01 16:24:03 input off
2024-02-06 14:08:23 input_mode switch straight follow
2024-02-12 14:33:00 inttemp 58
2024-02-05 16:21:54 name Heizung_Pumpenschalter_FBH
2024-02-12 14:35:51 network <html>connected to <a href="http://192.168.2.194">192.168.2.194</a></html>
2024-02-12 14:33:19 network_disconnects 7
2024-03-06 15:14:01 network_rssi -72
2024-03-01 16:24:03 network_ssid NobbiBox
2024-02-12 14:35:57 network_threshold -70
2024-02-06 23:28:51 overpower 0
2024-02-12 14:33:00 power 6.1
2024-02-06 14:08:14 protection none
2024-03-06 15:09:00 relay on
2024-02-12 14:36:00 source http
2024-03-06 15:09:00 state on
2024-03-06 15:14:01 timer 0
2024-02-12 14:32:56 voltage 235.4
2024-03-02 21:16:58 webhook_cnt 0
2024-03-02 21:16:58 webhook_ver 0
helper:
Sets config interval password reboot:noArg update:noArg name reset:disconnects on off toggle on-for-timer off-for-timer
Attributes:
alias FBH-Pumpe Heizung im KG
devStateIcon on.*:li_wht_on off.*:li_wht_off
event-min-interval .*:300
event-on-change-reading .*
fm_type onbutton,offbutton
icon li_wht_on
interval 300
model shelly1
room Favourites,Heizung,Shelly-Devices
verbose 3
webCmd on:offWas will/sollte mir die Fehlermeldung sagen und wie kann ich sie abstellen?
Wieso sollte das eine Fehlermeldung sein? ::)
pah
Ich verwende einen Shelly 3EM.
Ich habe das Attribute shellyuser gesetzt.
Ich habe das Passwort für das Web Interface des Shelly 3EM im Shelly 3EM Webinterface gesetzt und im FHEM device shelly_em3.
Das Passwort besteht nur aus Buchstaben und Zahlen.
Ich bekomme Updates zu den Readings (power,...).
Ich kann allerdings nicht das Relais im Shelly 3EM schalten
set shelly_em3 on 0Unsuccessful: Network Error for device shelly_em3, try device get status
version => 5.20 24.01.2024
Was kann ich tun, um das Relais im Shelly 3EM zu schalten?
Selbst gelöst:
Löschen und neu Anlegen des Devices hat den Fehler behoben.
Zitat von: Prof. Dr. Peter Henning am 06 März 2024, 15:28:10Wieso sollte das eine Fehlermeldung sein? ::)
pah
Eine gute Frage, die mich auf die Idee brachte, verbose auf "2" zu stellen - - - und schon sind die Meldungen weg.
Natürlich hätte ich auch selbst drauf kommen müssen, trotzdem Danke!
Zitat von: 50watt am 06 März 2024, 16:48:34Löschen und neu Anlegen des Devices hat den Fehler behoben.
Schön, dass das Modul dann so wie erwartet funktioniert. Wenn es solche Probleme gibt, dann empfiehlt es sich zunächst eine Neudefinition anzustoßen, also mittels
defmod .... oder dem
DEF Button auf der Weboberfläche, denn dadurch werden grundlegende Einstellungen angestossen.
Zitat von: uron am 06 März 2024, 15:17:11Was will/sollte mir die Fehlermeldung sagen und wie kann ich sie abstellen?
Nun, wie bereits festgestellt, ist das keine Fehlermeldung, sondern ein Logeintrag über etwas, was im Modul passiert. Und sowas ist bei einer Fehlersuche genauso wichtig wie Fehlermeldungen.
Moin,
Ich bin seit kurzem neuer Besitzer eines
"Shelly Plus 0-10V Dimmer E86BEAE4D2CC| 1.2.2| ce341dc8"
Zum steuern von dimmbar LED Vorschaltgeräten.
Das funktioniert über das eigene Webinterface auch super.
Leider bekomme ich über Fhem die Steuerung nicht zum laufen.
Ich konnte das Device anlegen und es wurde auch automatisch als
"model shellyplusdimmer" erkannt.
Leider führt ein "on oder off" nur zu einer Fehlermeldung:
"Error: forbidden command 'on' for device shelly010 (-1)"
Jetzt zur Frage:
Wird der spezielle Dimmer überhaupt unterstützt?
Oder hab ich da etwas grundlegend falsch gemacht?
Ich hoffe jemand von euch hat einen erhellenden Tip für mich.
Schöne Grüße Björn
Raw Definitions:
defmod shelly010 Shelly 192.168.178.98
attr shelly010 model shellyplusdimmer
attr shelly010 verbose 5
setstate shelly010 Error: Network
setstate shelly010 2024-03-07 13:42:45 addon sensor
setstate shelly010 2024-03-07 13:42:45 cloud disabled
setstate shelly010 2024-03-07 13:49:52 config successful
setstate shelly010 2024-03-07 13:42:45 firmware v1.2.2
setstate shelly010 2024-03-07 13:42:45 input_0 unknown
setstate shelly010 2024-03-07 13:42:45 input_0_mode button straight
setstate shelly010 2024-03-07 13:42:45 input_1 unknown
setstate shelly010 2024-03-07 13:42:45 input_1_mode button straight
setstate shelly010 2024-03-07 13:42:45 name Dimmer
setstate shelly010 2024-03-07 19:37:14 network <html>connected to <a href="http://192.168.178.98">192.168.178.98</a> (Wifi)</html>
setstate shelly010 2024-03-07 19:05:17 network_disconnects 1
setstate shelly010 2024-03-07 20:33:14 network_rssi -55
setstate shelly010 2024-03-07 13:42:45 network_ssid Unimatrix-Zero
setstate shelly010 2024-03-07 13:42:45 network_threshold -80
setstate shelly010 2024-03-07 19:05:17 state Error: Network
setstate shelly010 2024-03-07 13:42:45 webhook_cnt 8
setstate shelly010 2024-03-07 13:42:45 webhook_ver 8
Zitat von: bjbrill am 07 März 2024, 20:42:45Ich konnte das Device anlegen und es wurde auch automatisch als
"model shellyplusdimmer" erkannt.
Leider führt ein "on oder off" nur zu einer Fehlermeldung:
"Error: forbidden command 'on' for device shelly010 (-1)"
Da hast du alles richtig gemacht. Es kommt aber zur Fehlermeldung, weil die eigentliche Funktion des Plus-Dimmers noch nicht vom Modul abgedeckt wird.
Ich kann da nur um etwas Geduld bitten - ein großes Update des Moduls ist in Arbeit und da werden neue Shellies mit enthalten sein.
Ok, danke für die Info.
Dann brauche ich jetzt erst einmal nicht weiter probieren.
Bis zur Unterstützung des Dimmers helfe ich mir einfach mit Webaufrufen aus.
({ GetFileFromURL('http://192.168.178.98/rpc/Light.Set?id=0&on=true&brightness=70&transition_duration=20') })
Ist zwar etwas krückig, funktioniert aber erstenmal.
Schöne Grüße Björn
Hallo,
Ich hätte da mal einen feature request.
Vielleicht ist das ja machbar.
Ich habe in meinem Netz jetzt mal einen shelly als rangeextender eingesetzt.
Da funktioniert soweit ganz gut.
Jedoch würde ich gerne an diesem device sehen welche clients sich da angemeldet haben
Das kann man über folgenden api call machen:
http://<IP>/rpc/Wifi.ListAPClients
Das ergibt z.B. folgende Ausgabe:
{
"ts":1710287246,
"ap_clients":[
{
"mac":"XX:XX:XX:XX:XX:XX",
"ip":"192.168.33.5",
"ip_static":false,
"mport":12660,
"since":1710285405
},
{
"mac":"XX:XX:XX:XX:XX:XX",
"ip":"192.168.33.3",
"ip_static":false,
"mport":12524,
"since":1710284249
},
{
"mac":"XX:XX:XX:XX:XX:XX",
"ip":"192.168.33.2",
"ip_static":false,
"mport":12626,
"since":3
}
]
}
Was hier wichtig wäre ist der externe Link im Bild.
[attach id=177059]Bildschirmfoto 2024-03-13 um 00.52.31.png[/attach]
Würde mich freuen, wenn man das bei einem rangeextender einbauen könnte.
Gruß
Hubert
Zitat von: carlos am 13 März 2024, 01:01:02Ich habe in meinem Netz jetzt mal einen shelly als rangeextender eingesetzt.
Das Thema wird hier (https://forum.fhem.de/index.php?msg=1306987) weiter verfolgt.
Moin zusammen,
supportet dies Modul auch den "Shelly Button1" ?
Hintergrund:
Ich habe bereits viele Shelly Devices mit diesem Modul erfolgreich im Einsatz.
Aktuell überlege ich, zwei vorhandene LED-Stripes mittels Shelly RGBW2 smart zu machen. Jedoch braucht es dann einen physischen Wandschalter Aufputz mit Batterie zum "manuellen" Schalten. Da dachte ich, könnte ich den Shelly Button1 einmal für ausprobieren (bzw. ich kenne sonst auch bisher noch keine batteriebetr. Aufputz-Schalter/Taster (ausser IKEA Tradfri))
Zitat von: Dracolein am 18 März 2024, 10:58:04supportet dies Modul auch den "Shelly Button1" ?
Derzeit nicht.
Wäre aber denkbar, wenn das BLU Device an einem Shelly-BLU-Gateway hängen würde und dann via HTTP erreichbar wäre.
Falls jemand dazu etwas berichten möchte, dann bitte im Entwicklungs-Thread (https://forum.fhem.de/index.php?msg=1306987).
Zitat von: Starkstrombastler am 18 März 2024, 11:47:14Zitat von: Dracolein am 18 März 2024, 10:58:04supportet dies Modul auch den "Shelly Button1" ?
Derzeit nicht.
Wäre aber denkbar, wenn das BLU Device an einem Shelly-BLU-Gateway hängen würde und dann via HTTP erreichbar wäre.
Falls jemand dazu etwas berichten möchte, dann bitte im Entwicklungs-Thread (https://forum.fhem.de/index.php?msg=1306987).
Danke für die Rückmeldung, dann lasse ich von dem Teil als simpler Enduser direkt die Finger und suche mir einen anderen Aufputz-Taster
Zitat von: Starkstrombastler am 13 Februar 2024, 09:33:36Zitat von: gent am 12 Februar 2024, 23:22:10Mir ist in der Web-Oberfläche des Device aufgefallen, dass dort angezeigt wird, was den letzten Schaltbefehl ausgelöst hat.
Im Shelly-Modul wird der Auslöser des letzten Schaltens im Reading "source" ausgegeben.
Zitat von: gent am 12 Februar 2024, 23:22:10Dann ist mir noch aufgefallen, dass das Reading "power" nur ausgegeben wird, wenn man im Webinterface des Shelly Plus Plug S unter den Einstellungen im Bereich MQTT die Option "Generic status update over MQTT" einschaltet.
Das hört sich so an, als ob du garnicht das Shelly-Modul nutzt, sondern die Einbindung via MQTT. Dann müsstest du an anderer Stelle hier im Forum suchen.
Alternativ bist du natürlich gerne eingeladen, das Shelly-Modul zu nutzen: define <name> Shelly <ip-adresse>
Ich nutze das Shelly Modul. Hier mein def:
defmod KU.Spuelmaschine Shelly 192.168.178.194
attr KU.Spuelmaschine DbLogExclude .*
attr KU.Spuelmaschine DbLogInclude power
attr KU.Spuelmaschine alexaName Spülmaschine
attr KU.Spuelmaschine alias Spülmaschine
attr KU.Spuelmaschine group Strom
attr KU.Spuelmaschine model shellyplusplug
attr KU.Spuelmaschine room 02_Mitte->Küche
attr KU.Spuelmaschine siriName Spülmaschine
attr KU.Spuelmaschine userReadings updateneeded {if(ReadingsVal($NAME,"firmware","") =~ ("needed") ){'true'} else {'false'}}
Zitat von: gent am 20 März 2024, 19:50:18Dann ist mir noch aufgefallen, dass das Reading "power" nur ausgegeben wird, wenn man im Webinterface des Shelly Plus Plug S unter den Einstellungen im Bereich MQTT die Option "Generic status update over MQTT" einschaltet.
Auf solche Zusammenhänge kommt man wohl nur durch Zufall. Da ich aber keinen
Shelly Plus Plug S hier habe, die Frage in die Runde, ob dieses Verhalten auch sonst beobachtet wird.
Zitat von: Starkstrombastler am 20 März 2024, 19:59:33Auf solche Zusammenhänge kommt man wohl nur durch Zufall. Da ich aber keinen Shelly Plus Plug S hier habe, die Frage in die Runde, ob dieses Verhalten auch sonst beobachtet wird.
Kann ich bei mir nicht bestätigen (Shelly-Firmware 1.2.3, 36_Shelly.pm:v5.20.0-s28413/2024-01-24).
vG Jens
Hallo
Kann ich auch nicht bestätigen.
Das war bei mir im PlusPlug noch nie gesetzt und trotzdem bekomme ich schon immer Power im aktuellen Modul als auch beim alten (4.02f mit Modell shellyplus1pm) Modul angezeigt.
Firmware 0.12.99-plugsprod1
Gruß Ralf
Anderes Thema:
habe grade das im Log gesehen, nachdem ich versucht habe einen shellydimmer komplett auszuschalten:
2024.03.20 23:34:21.115 1: [Shelly_Set] WZ.Deckenfluter Error: wrong pct value '0' given, must be 1 ... 100
Hier die def:
defmod WZ.Deckenfluter Shelly 192.168.178.197
attr WZ.Deckenfluter DbLogExclude .*
attr WZ.Deckenfluter alexaName Deckenfluter
attr WZ.Deckenfluter alias Deckenfluter
attr WZ.Deckenfluter group Licht
attr WZ.Deckenfluter mode white
attr WZ.Deckenfluter model shellydimmer
attr WZ.Deckenfluter room 02_Mitte->Wohnzimmer,Homekit
attr WZ.Deckenfluter siriName Deckenfluter
attr WZ.Deckenfluter userReadings attr WZ.Deckenfluter userReadings updateneeded {if(ReadingsVal($NAME,"firmware","") =~ ("needed") ){'true'} else {'false'}}
Zitat von: gent am 20 März 2024, 23:42:50habe grade das im Log gesehen, nachdem ich versucht habe einen shellydimmer komplett auszuschalten:
2024.03.20 23:34:21.115 1: [Shelly_Set] WZ.Deckenfluter Error: wrong pct value '0' given, must be 1 ... 100
Das Modul verhält sich hier so wie der Shelly-Dimmer, um den Zustand "eingeschaltet mit 0% Helligkeit", also de facto "aus", zu vermeiden.
Moin,
ich habe heute mal ein Update gemacht, dazu kam auch das Shelly Module update. Seitdem lädt er das Modul nicht mehr
2024.03.22 11:44:16.142 1: reload: Error:Modul 36_Shelly deactivated:
Global symbol "$oldtimer" requires explicit package name (did you forget to declare "my $oldtimer"?) at ./FHEM/36_Shelly.pm line 1977.
Global symbol "$oldtimer" requires explicit package name (did you forget to declare "my $oldtimer"?) at ./FHEM/36_Shelly.pm line 1979.
2024.03.22 11:44:16.142 0: Global symbol "$oldtimer" requires explicit package name (did you forget to declare "my $oldtimer"?) at ./FHEM/36_Shelly.pm line 1977.
Global symbol "$oldtimer" requires explicit package name (did you forget to declare "my $oldtimer"?) at ./FHEM/36_Shelly.pm line 1979.
Zitat von: Kai-Alfonso am 22 März 2024, 11:48:06ich habe heute mal ein Update gemacht, dazu kam auch das Shelly Module update. Seitdem lädt er das Modul nicht mehr
Hallo,
meine Vermutung. In beiden Zeilen wird ein Kommando zusammengebaut. Leider mit Anführungszeichen und nicht mit Hochkomma. Somit versucht Perl Variablen, wie $oldtimer zu evaluieren.
Grüße Jörg
Hi Jörg,
Zitat von: JoWiemann am 22 März 2024, 12:16:03meine Vermutung. In beiden Zeilen wird ein Kommando zusammengebaut. Leider mit Anführungszeichen und nicht mit Hochkomma. Somit versucht Perl Variablen, wie $oldtimer zu evaluieren.
richtig vermutet - danke für den Tipp. Mit ' statt " in den beiden Zeilen ging es dann bei mir.
Frage: hatte noch niemand vor mir den Fehler? Hatte auf die Schnelle nix gefunden
Besser: $oldtimer im Modulcode löschen, das wird erst im nächsten großen Update verwendet.
Korrektur ist bereits eingecheckt.
Zitat von: Kai-Alfonso am 22 März 2024, 13:39:13Frage: hatte noch niemand vor mir den Fehler? Hatte auf die Schnelle nix gefunden
Ja ich. Mit dem vorhergehenden Modul aus dem restorDir und gesichertem fhem.cfg alles wiederhergestellt.
Guten Abend,
ich hoffe meine Frage ist hier richtig gestellt.
gestern nach update,
Error:Modul 36_Shelly deactivated:
Global symbol "$oldtimer" requires explicit package name (did you forget to declare "my $oldtimer"?) at ./FHEM/36_Shelly.pm line 1977.
Global symbol "$oldtimer" requires explicit package name (did you forget to declare "my $oldtimer"?) at ./FHEM/36_Shelly.pm line 1979.
Die Beiträge dazu hab ich gelesen helfen mir aber nicht.
mfg
Wolfgang
Shellys zu Ostern preisreduziert bei Amazon.
LG
pah
Zitat von: wolsch am 22 März 2024, 17:22:26Die Beiträge dazu hab ich gelesen helfen mir aber nicht.
Nun, was ist passiert? Dem Modulautor ist beim Vorhaben
"mal eben schnell eine kleine Änderung" ein Fehler unterlaufen, was natürlich keine Absicht war.
Erfahrene User nutzen die Fehlerangabe (...Shelly.pm line 1977...) um sich die Stelle im Quellcode anzuschauen und evtl. zu editieren.
Der Vorschlag, die Anführungszeichen zu ändern ist aber nicht unbedingt zielführend, weil zwar der urpsprüngliche Fehler nicht mehr auftritt, aber dafür ein unsinniger Befehl an einen Shelly-Dimmer gesendet wird.
Mein Vorschlag zur Änderung des Quellcodes (Löschen von
$oldtimer) richtet sich aber auch nur an erfahrene User.
Die Angabe
Korrektur ist eingecheckt, heißt, dass eine korrigierte Version ab dem nächsten Tag ca. 08:00 Uhr via
update zur Verfügung steht (also seit heute Morgen).
Alternativ lässt sich die vorhergehende Version des fehlerhaften Moduls aus dem
restoreDir wieder zurückholen. Im konkreten Fall wird dazu die Datei 36_Shelly.pm aus dem Verzeichnis /opt/fhem/restoreDir/update/2024-03-22/FHEM/ in das Verzeichnis /opt/fhem/FHEM/ kopiert und anschließend mit dem FHEM-Befehl
reload 36_Shelly.pm in das laufende System geladen.
/opt/fhem/ ist hier das Stammverzeichnis von FHEM, das lautet in der jeweiligen Installation eventuell auch anders.
Ich hoffe, das hilft ein wenig die oben diskutierten Maßnahmen besser zu verstehen.
Hallo Starkstrombastler,
tolle Antwort hab die 36_Shelly.pm aus dem restore kopiert.
Scheint alles gut su sein.
Danke für die Tips
Wolfgang
Hallo zusammen,
inzwischen habe ich ne Runde neue Shelly Plus S gekauft...leider sind die "alten" Shelly Plug S kaum noch zu finden, weshalb ich dann die Shelly Plug Plus S gekauft habe...nur leider scheinen diese (noch) nicht mit dem Modul in FHEM zu funktionieren. Kann ich etwas tun, damit dieses Modell auch vom Modul unterstützt wird? Das war mit den "alten" Shellys immer so einfach...oder müssen wir hier jetzt tatsächlich über MQTT gehen (sehe ich eher als Rückschritt)...
Danke in die Runde! ;D
Hallo
Check mal ob das Attribut Model gesetzt ist.
model shellyplusplug
Ansonsten setze es mal.
Gruß Ralf
@homespinner
Ich habe gestern erst einen neuen Plus S eingebunden, absolut problemlos.
Ist dein System aktuell?
vb
Moin,
Ich habe seit heute auch Probleme mit einem PlugS.
Kurios ist nur, ich habe 2 davon und einer läuft Problemlos.
Der andere wirft alle 10 Sekunden folgendes ins log
2024.03.24 19:02:09.700 2: myShelly_Tablet: undefined value for source
Was kann das sein?
Grüsse Daniel
Zitat von: Shadow3561 am 24 März 2024, 19:07:152024.03.24 19:02:09.700 2: myShelly_Tablet: undefined value for source
Das Schreiben des Readings "source" hat also nicht funktioniert, weil der zu schreibende Wert undefiniert ist.
Um dem auf die Spur zu kommen, benötige ich mehr Informationen:
a) eine Kopie der Definition "copy for forum"
b) einen kurzen Abschnitt aus der Logdatei, hierzu für das betroffene Device für einige Sekunden verbose=5 setzten, so dass der fehlerhafte Schreibvorgang erfasst wird.
Moin,
Hier der Logauzug mit verbose 5
2024.03.24 20:05:19.092 4: [Shelly_status] myShelly_Tablet: next update in 10 seconds
2024.03.24 20:05:29.141 4: [Shelly_status(1G)] issue a non-blocking call to http://192.168.1.73/status
2024.03.24 20:05:29.316 5: [Shelly_status] device myShelly_Tablet of model shellyplug has returned data
{"wifi_sta":{"connected":true,"ssid":"o2-WLAN06","ip":"192.168.1.73","rssi":-54},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"20:05","unixtime":1711310729,"serial":1,"has_update":false,"mac":"4C11AE041575","relays":[{"ison":false,"has_timer":false,"timer_remaining":0,"overpower":false}],"meters":[{"power":0.00,"is_valid":true,"timestamp":1711310729,"counters":[0.000, 0.000, 0.000],"total":1178570}],"temperature":31.99,"overtemperature":false,"tmp":{"tC":31.99,"tF":89.58, "is_valid":"true"},"update":{"status":"unknown","has_update":false,"new_version":"","old_version":"20200309-104506/v1.6.0@43056d58"},"ram_total":50608,"ram_free":39612,"fs_size":233681,"fs_free":167919,"uptime":49618652}
2024.03.24 20:05:29.336 5: [Shelly_Set] FhemWeb is requesting set-commands for device myShelly_Tablet
2024.03.24 20:05:29.336 5: [Shelly_rssi] returns -54 to device myShelly_Tablet
2024.03.24 20:05:29.337 2: myShelly_Tablet: undefined value for source
2024.03.24 20:05:29.337 4: [Shelly_proc1G] myShelly_Tablet: Looking for metering values
2024.03.24 20:05:29.337 5: [Shelly_proc1G] myShelly_Tablet : power=0 TTL=0, energy=19642.8 TTL=1178570
2024.03.24 20:05:29.357 5: [Shelly_Set] FhemWeb is requesting set-commands for device myShelly_Tablet
2024.03.24 20:05:29.357 4: [Shelly_status] myShelly_Tablet: proc1G returned with value=10
2024.03.24 20:05:29.358 4: [Shelly_status] myShelly_Tablet: next update in 10 secondsZitat von: Starkstrombastler am 24 März 2024, 19:51:18a) eine Kopie der Definition "copy for forum"
damit kann ich nichts anfangen, daher die RAW-Def
defmod myShelly_Tablet Shelly 192.168.1.73
attr myShelly_Tablet DbLogExclude cloud,firmware,network,overpower,relay,relay_0
attr myShelly_Tablet DbLogInclude state, power
attr myShelly_Tablet alias Ladegerät Wallpanel
attr myShelly_Tablet interval 10
attr myShelly_Tablet mode relay
attr myShelly_Tablet model shellyplug
attr myShelly_Tablet room Tablet Flur
attr myShelly_Tablet stateFormat {\
my $gesamt = sprintf("%.2f",ReadingsVal($name,"energy","")/1000);;;;\
my $gesamtname = "Gesamtverbrauch: $gesamt kWh";;;;\
my $pic = ReadingsVal($name,"running","") eq "läuft"?'message_socket@green':'message_socket';;;;\
my $text = ReadingsVal($name,"running","") eq "läuft"?"lädt gerade - Aktuell: ".ReadingsVal($name,"power","")." W":'Standby';;;;\
"<div><a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a> ; ; ;".FW_makeImage($pic)." ; ; ;$text ; ; ;$gesamtname</div>"\
}
attr myShelly_Tablet timeout 120
attr myShelly_Tablet userReadings running {ReadingsVal($name,"power",0) ne "0" ? "läuft" : "fertig"}
attr myShelly_Tablet verbose 0
attr myShelly_Tablet webCmd :
setstate myShelly_Tablet <div><a href="/fhem?cmd.dummy=set myShelly_Tablet toggle&XHR=1"></a> ; ; ;<svg class=" message_socket" data-txt="message_socket" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="470pt" viewBox="0 0 468 470" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,470) scale(0.158108,-0.158108)" stroke="none"> <path d="M75 2941 c-16 -10 -39 -28 -50 -41 -20 -22 -20 -36 -20 -1415 l0 -1393 25 -27 c55 -59 -38 -55 1445 -55 1483 0 1390 -4 1445 55 l25 27 0 1394 0 1394 -38 37 -37 38 -1383 3 c-1332 2 -1383 1 -1412 -17z m2743 -1453 l-3 -1343 -1340 0 -1340 0 -3 1330 c-1 732 0 1336 3 1343 3 9 282 12 1345 12 l1340 0 -2 -1342z"/> <path d="M589 2417 c-19 -13 -39 -38 -46 -57 -15 -45 -18 -1676 -3 -1731 6 -19 22 -46 36 -60 l26 -24 885 0 885 0 29 33 29 32 0 878 c0 964 4 904 -60 937 -25 13 -145 15 -888 15 l-859 0 -34 -23z m785 -142 c22 -22 33 -25 101 -25 68 0 79 3 101 25 25 25 25 25 216 25 l192 0 158 -157 158 -157 0 -490 0 -491 -167 -167 -168 -168 -187 0 c-137 0 -188 3 -188 12 0 6 -7 20 -17 30 -13 15 -31 18 -101 18 -87 0 -122 -13 -122 -47 0 -10 -35 -13 -172 -13 l-173 0 -167 167 -168 168 0 480 0 480 167 167 168 168 172 0 c170 0 172 0 197 -25z"/> <path d="M954 1589 c-16 -18 -19 -37 -19 -111 0 -118 10 -128 132 -128 76 0 86 2 108 25 22 21 25 33 25 100 0 73 -10 112 -34 127 -6 4 -52 8 -102 8 -80 0 -93 -3 -110 -21z"/> <path d="M1780 1590 c-17 -17 -20 -33 -20 -108 0 -80 2 -91 23 -110 20 -19 35 -22 110 -22 120 0 127 8 127 133 0 123 -4 127 -128 127 -79 0 -95 -3 -112 -20z"/> </g> </svg> ; ; ;Standby ; ; ;Gesamtverbrauch: 19.64 kWh</div>
setstate myShelly_Tablet 2024-03-24 16:45:59 cloud disabled
setstate myShelly_Tablet 2024-03-24 16:46:08 coiot disabled
setstate myShelly_Tablet 2024-03-24 16:46:08 coiot_period 15
setstate myShelly_Tablet 2024-03-24 16:47:04 config updating
setstate myShelly_Tablet 2024-03-24 19:00:38 energy 19642.8
setstate myShelly_Tablet 2024-03-24 16:45:59 firmware v1.6.0
setstate myShelly_Tablet 2024-03-24 20:08:02 inttemp 31.88
setstate myShelly_Tablet 2024-03-24 20:04:58 network <html>connected to <a href="http://192.168.1.73">192.168.1.73</a></html>
setstate myShelly_Tablet 2024-03-24 20:04:48 network_disconnects 1
setstate myShelly_Tablet 2024-03-24 20:06:20 network_rssi -54
setstate myShelly_Tablet 2024-03-24 16:45:59 network_ssid o2-WLAN06
setstate myShelly_Tablet 2024-03-24 20:04:58 overpower off
setstate myShelly_Tablet 2024-03-24 19:08:18 power 0
setstate myShelly_Tablet 2024-03-24 19:10:09 relay off
setstate myShelly_Tablet 2024-03-24 20:08:12 running fertig
setstate myShelly_Tablet 2024-03-24 20:04:58 state off
setstate myShelly_Tablet 2024-03-24 16:54:41 timer 0
setstate myShelly_Tablet 2024-03-24 16:45:58 webhook_cnt 0
setstate myShelly_Tablet 2024-03-24 16:45:58 webhook_ver 0
Grüsse
Daniel
Zitat von: Shadow3561 am 24 März 2024, 20:08:57setstate myShelly_Tablet 2024-03-24 16:45:59 firmware v1.6.0
Die Firmware auf dem Shelly scheint nicht aktuell zu sein. Aktuell: 1.14.0
Im Übrigen findest du den Befehl für "Copy for forum.." in der Device-Ansicht ganz unten...
Copy for forum.png
Da scheint bei mir wohl etwas gewaltig nicht zu stimmen.
Die Firmware vom Shelly habe ich am Samstag aktualisiert. Ich bin mir ziemlich sicher, das dies auf 1.14 war.
Copy for Forum gibt es bei mir nicht. Fhem ist aktuell. Gestern habe ich ein update gefahren.
So, Firmware-Update habe ich hinbekommen. Das FHEM-Log bleibt sauber.
Danke für den Hinweis mit der Firmware. Darauf wäre ich nie gekommen weil ich ja bereits die Firmware aktualisiert habe. Leider ist dabei wohl etwas schief gegangen.
Danke
EDIT:
zu Copy for FHEM
Dies ist erscheint bei mir nur bei einigen Styles aber nicht bei allen.
Hallo zusammen,
ich bin gerade dabei mit einem Shelly Plus 2PM meine Zirkulationspumpe zu steuern.
Dazu hab ich per Addon 3 Temperatursensoren DS18B20 angeschlossen.
In Fhem nutze ich das Shelly Modul dazu um alles auszulesen. Dabei bekomme ich leider kein guten Update Interval hin.
Meine Versuche bisher waren:
- Automatisch generierte Webhooks => Diese funktionieren nicht, da bei mir nur HTTPS mit Passwort erlaubt ist, es wird aber http ohne passwort generiert.
- Attribut interval auf 10 sekunden stellen => Damit wird z.b. das reading "inttemp" alle 10 sekunden aktualisiert, jedoch die Readings "temperature_0" bis "temperature_2" werden nur alle 4 Minuten aktualisiert.
Was mach ich hier falsch? Wie kann ich die Webhooks richtig anlegen lassen, bzw. das Interval für die Temperaturen runtersetzen.
define ShellyWarmwasser Shelly 192.168....
attr ShellyWarmwasser event-min-interval .*:3600
attr ShellyWarmwasser event-on-change-reading .*
attr ShellyWarmwasser interval 10
attr ShellyWarmwasser mode relay
attr ShellyWarmwasser model shellyplus2pm
attr ShellyWarmwasser userReadings energy_kWh_0:energy_0.* monotonic {ReadingsVal("ShellyWarmwasser","energy_0",0)/1000;;},\
energy_kWh_1:energy_1.* monotonic {ReadingsVal("ShellyWarmwasser","energy_1",0)/1000;;}
attr ShellyWarmwasser webhook WEB
...
setstate ShellyWarmwasser 2024-03-26 23:48:44 webhook_cnt 9
setstate ShellyWarmwasser 2024-03-27 00:33:16 webhook_ver 26
Zitat von: Hadl am 27 März 2024, 01:06:17ich bin gerade dabei mit einem Shelly Plus 2PM meine Zirkulationspumpe zu steuern.
Ich schlage vor, die Zirkulationssteuerung weitestgehend vom Shelly autonom durchführen zu lassen. Das mindert die Last auf dem FHEM-Server und funktioniert notfalls auch ohne FHEM.
1. Auf der Weboberfläche des Shelly eine Action für den Temperatursensor anlegen.
Diese Action soll auslösen, wenn die Temperatur einen festgelegten Wert überschreitet:
- Unter 'Then Do' eine
lokale URL auswählen,
- unter Action 'Control Output' wählen,
- unter 'Target Component' den zu schaltenden Ausgang wählen,
- unter 'Output State' 'off' wählen.
2. Ein- und Ausschaltvorgänge sollen an Fhem gemeldet werden. Dazu FHEM vorbereiten:
- ein neues FHEMWEB Device z.B. mit Namen 'HOOK' anlegen, mit der lokalen Adresse des FHEM-Servers und einem neu gewähltem Port.
- CSFR-Token ausschalten:
attr HOOK csfrToken none - ein allowed Device anlegen und mit dem zuvor definiertem FHEMWEB-Device verknüpfen:
attr <allowedDevice> validFor HOOK
- Die Kommunikation einschränken mit
attr <allowedDevice> allowedDevices <IP-Adresse des Shelly>
3. Auf dem Shelly die automatisch angelegte Action _SWITCH_ON_ bearbeiten:
- In der URL die Portnummer auf den im oben erstellen FHEMWEB Device ändern
- ggf. enthaltenes Token entfernen (einschl. des vorangestellten "&")
4. Gleiches Vorgehen für Action _SWITCH_OFF_
5. Übrige Actions auf dem Shelly deaktivieren (oder löschen)
6. Polling Intervall für das Shelly-Device auf einen großen Wert, z.B. 300 Sekunden, stellen.
7. Fertig.
Wird der Ausgang des Shelly mittels Taster am Shelly, via FHEM "set ... on" oder via Shelly-App eingeschaltet,
meldet dies die Action _SWITCH_ON_ an FHEM. Das Shelly-Modul sendet daraufhin eine Statusanfrage an den Shelly
und kann damit ohne spürbare Verzögerung alle Readings, z.B. auch Power, aktualisieren.
Wird die gewünschte Temperatur erreicht, schaltet der Shelly selbständig aus und informiert FHEM via Action _SWITCH_OFF_,
woraufhin die Readings wieder aktualisiert werden.
Wenn das Ganze so wie beschrieben funktioniert, lässt es sich noch weiter verfeinern...
Hallo Starkstrombastler,
vielen Dank für deine Hinweise, ja so ähnlich hatte ich das vor.
Dein Tip mit dem seperaten FHEMWEB Device, welches weder https, noch Passwort, noch CSFR hat heißt werde ich probieren.
Heißt das im Umkehrschluss das es mit alle dem garnicht möglich ist?
Wenn ich die Actions manuell bearbeite, werden die dann nicht wieder von Fhem zyklisch überschrieben, oder muss ich dann die "Webhook" wieder ausschalten?
Was leider damit nicht klappt, ist das ich meinen Temperaturverlauf in höherer Messrate in Fhem sehe. Hier würden mir am Anfang wirklich 10 Sekunden etwas bringen um z.B. abschätzen zu können wielange die Pumpe laufen muss bis das ganze System gespült ist (Hab Vorlauf und 2 Rückläufe am Shelly gemessen)
Soll ich dann analog zu den Switches auch die Temperaturen mit über den FHEMWEB HOOK laufen lassen?
Warum schlägst du nur vor, die beiden Switches per Hook anzubinden und nicht gleich alle Signale?
Manche Signale wie Power währen trotzdem schon mindestens jede Minute mal interessant. Vielleicht ist das aber auch nur meine Vorliebe für Viele Diagramme mit guter Auflösung.
Hallo,
ich habe eine Frage zu den Shelly´s plus 2pm. Habe davon 2 Stck. angeschlossen und möchte sie mit dem Modul Shelly nutzen (für Beleuchtung und ohne MQTT).
Die übliche Prozedur mit einbinden ins WLAN, Name, Update usw. habe ich gemacht. Das Ein- und Ausschalten per Schalter funktioniert.
Danach habe ich ein Gerät in Fhem angelegt. (define Li.Kueche.Deckenlampe Shelly 192.168.178.113) Habe erwartet, das ich jetzt ein Gerät mit zwei Kanälen habe. Dem war bei mir aber nicht so, also habe ich ein zweites Gerät mit der gleichen IP angelegt und jedem Gerät 1x das "attr defchannel 0" und dem anderen "attr defchannel 1" zugeordnet. Jetzt kann ich die Relais per Fhem schalten, allerdings werden beim Schalten von Kanal0 beide Relais ein- bzw. ausgeschaltet. Außerdem steht state immer auf OK, ich hätte gern ein Symbol bzw. den Status An/aus.
Wie muss ich die Geräte in Fhem anlegen? oder fehlen noch Attribute?
Hier noch ein List von den beiden Geräten.
Li.Kueche.Deckenlampe
Internals:
CFGFN
DEF 192.168.178.113
FUUID 66031a7c-f33f-2fb6-0d86-3fc9dfce40ba6bc9
INTERVAL 60
NAME Li.Kueche.Deckenlampe
NR 69301
SHELLYID shellyplus2pm-xxxxxxxxxxxxxxxx
STATE OK
TCPIP 192.168.178.113
TYPE Shelly
eventCount 2878
units 0
OLDREADINGS:
READINGS:
2024-03-26 19:58:52 cloud disabled
2024-03-26 19:59:25 config successful
2024-03-27 20:41:57 current_0 0.16
2024-03-27 20:41:57 current_1 0.095
2024-03-27 20:41:57 energy_0 607.219
2024-03-27 20:41:57 energy_1 219.231
2024-03-26 19:58:52 firmware v1.2.2
2024-03-27 20:05:51 frequency_0 50
2024-03-27 20:05:51 frequency_1 50
2024-03-27 20:24:51 input_0 off
2024-03-26 19:58:52 input_0_mode switch straight follow
2024-03-27 18:36:51 input_1 off
2024-03-26 19:58:52 input_1_mode switch straight follow
2024-03-27 20:41:57 inttemp 52.5
2024-03-26 19:58:52 name Shelly-Kueche
2024-03-26 19:58:52 network <html>connected to <a href="http://192.168.178.113">192.168.178.113</a> (Wifi)</html>
2024-03-27 13:37:38 network_disconnects 2
2024-03-27 20:32:51 network_rssi -53
2024-03-26 19:58:52 network_ssid BRxxxxxxxx
2024-03-26 19:58:52 network_threshold -80
2024-03-27 13:39:06 overpower_0 0
2024-03-27 13:39:06 overpower_1 0
2024-03-27 20:41:57 pfactor_0 0.95
2024-03-27 20:41:57 pfactor_1 0.67
2024-03-27 20:41:57 power_0 35.8
2024-03-27 20:41:57 power_1 14.9
2024-03-26 19:57:55 protection_0 none
2024-03-26 19:58:55 protection_1 none
2024-03-27 20:40:56 relay_0 on
2024-03-27 20:40:56 relay_1 on
2024-03-27 20:40:56 source_0 http
2024-03-27 20:40:56 source_1 http
2024-03-27 20:41:57 state OK
2024-03-26 19:58:55 timer_0 -
2024-03-26 19:58:55 timer_1 -
2024-03-27 20:41:57 voltage_0 233.7
2024-03-27 20:41:57 voltage_1 233.8
2024-03-26 20:56:36 webhook_cnt 2
2024-03-26 20:56:36 webhook_ver 8
helper:
Sets config interval password reboot:noArg update:noArg name reset:disconnects,energy on off toggle on-for-timer off-for-timer ON:noArg OFF:noArg xtrachannels:noArg
hmccu:
Attributes:
alias Licht Kueche Deckenlampe
defchannel 1
event-on-change-reading .*
eventMap ON:An OFF:Aus
group Lichtschalter
mode relay
model shellyplus2pm
room Küche,Licht
userattr LS.All LS.All_map Licht.All Licht.All_map structexclude
Li.Kueche.Wandlampe
Internals:
CFGFN
DEF 192.168.178.113
FUUID 66031a1b-f33f-2fb6-551f-f2b139ea2255cc8e
INTERVAL 60
NAME Li.Kueche.Wandlampen
NR 69292
SHELLYID shellyplus2pm-xxxxxxxxxx
STATE OK
TCPIP 192.168.178.113
TYPE Shelly
eventCount 2990
units 0
OLDREADINGS:
READINGS:
2024-03-26 19:58:47 cloud disabled
2024-03-27 20:42:59 current_0 0.159
2024-03-27 20:42:59 current_1 0.096
2024-03-27 20:42:59 energy_0 607.885
2024-03-27 20:42:59 energy_1 219.503
2024-03-26 19:58:47 firmware v1.2.2
2024-03-27 20:05:51 frequency_0 50
2024-03-27 20:05:51 frequency_1 50
2024-03-27 20:25:27 input_0 off
2024-03-26 19:58:47 input_0_mode switch straight follow
2024-03-27 18:37:26 input_1 off
2024-03-26 19:58:47 input_1_mode switch straight follow
2024-03-27 20:42:59 inttemp 53.4
2024-03-26 19:58:47 name Shelly-Kueche
2024-03-26 19:58:47 network <html>connected to <a href="http://192.168.178.113">192.168.178.113</a> (Wifi)</html>
2024-03-27 13:38:14 network_disconnects 3
2024-03-27 20:33:27 network_rssi -53
2024-03-26 19:58:47 network_ssid BRxxxxxxxxx
2024-03-26 20:01:04 network_threshold -80
2024-03-27 13:38:21 overpower_0 0
2024-03-27 13:38:21 overpower_1 0
2024-03-27 20:42:59 pfactor_0 0.96
2024-03-27 20:42:59 pfactor_1 0.66
2024-03-27 20:42:59 power_0 35.5
2024-03-27 20:40:58 power_1 14.9
2024-03-26 19:56:28 protection_0 none
2024-03-26 19:58:59 protection_1 none
2024-03-27 20:24:59 relay_ off
2024-03-27 20:40:58 relay_0 on
2024-03-27 20:40:58 relay_1 on
2024-03-27 20:40:58 source_0 http
2024-03-27 20:40:58 source_1 http
2024-03-27 20:42:59 state OK
2024-03-26 19:58:59 timer_0 -
2024-03-26 19:58:59 timer_1 -
2024-03-27 20:41:58 voltage_0 233.8
2024-03-27 20:40:58 voltage_1 233.9
2024-03-26 20:57:07 webhook_cnt 2
2024-03-26 20:57:07 webhook_ver 8
helper:
Sets config interval password reboot:noArg update:noArg name reset:disconnects,energy on off toggle on-for-timer off-for-timer ON:noArg OFF:noArg xtrachannels:noArg
hmccu:
Attributes:
alias Licht Küche Wandlampen
defchannel 0
event-on-change-reading .*
eventMap on:An off:Aus
group Lichtschalter
mode relay
model shellyplus2pm
room Küche,Licht
userattr LS.All LS.All_map Licht.All Licht.All_map structexclude
Vielen Dank und Gruß
besmart
Zitat von: Hadl am 27 März 2024, 20:03:20Dein Tip mit dem seperaten FHEMWEB Device, welches weder https, noch Passwort, noch CSFR hat heißt werde ich probieren.
Heißt das im Umkehrschluss das es mit alle dem garnicht möglich ist?
Der CSFR-Token muss halt bei jedem Neustart von FHEM aktualisiert werden. Das ist in der aktuellen Modulversion aber noch nicht so schön gelöst (zyklische Prüfung). Passwort sollte gehen, muss aber manuell eingetragen werden.
HTTPS derzeit vom Modul nicht unterstützt.
Zitat von: Hadl am 27 März 2024, 20:03:20Wenn ich die Actions manuell bearbeite, werden die dann nicht wieder von Fhem zyklisch überschrieben, oder muss ich dann die "Webhook" wieder ausschalten?
In der aktuellen Modulversion wird die Action gelöscht, wenn du das Attr webhook entfernst.
Das automatische Update der Webhooks beschränkt sich auf Portnummer und CSFR-Token und das auch nur, wenn der Name der Action mit _Unterstrich_ anfängt und aufhört.
Zitat von: Hadl am 27 März 2024, 20:03:20Was leider damit nicht klappt, ist das ich meinen Temperaturverlauf in höherer Messrate in Fhem sehe. Hier würden mir am Anfang wirklich 10 Sekunden etwas bringen um z.B. abschätzen zu können wielange die Pumpe laufen muss bis das ganze System gespült ist (Hab Vorlauf und 2 Rückläufe am Shelly gemessen)
Das ist davon abhängig, was der Shelly bereitstellt. Du kannst natürlich auch eine Action mit dem Sensorwert an FHEM adressieren. Sollte ohnehin automatisch angelegt worden sein. Du kannst auch mit
set <name> interval 10 das Interval mit dem Einschalten der Pumpe verringern und dann wieder mit
set <name> interval -1 auf den Originalwert zurückgehen.
Zitat von: Hadl am 27 März 2024, 20:03:20Soll ich dann analog zu den Switches auch die Temperaturen mit über den FHEMWEB HOOK laufen lassen?
Ja, sonst macht der HOOK keinen Sinn.
Zitat von: Hadl am 27 März 2024, 20:03:20Warum schlägst du nur vor, die beiden Switches per Hook anzubinden und nicht gleich alle Signale?
Wenn der Shelly via Action/Webhook einen Befehl an das Modul sendet (z.B. Ausgang ist EIN), wird dieser Befehl sofort verarbeitet und mit einer Sekunde Verzögerung eine Anfrage
get <shelly> status gestartet. So werden alle Status-Werte*) abgeholt und die Power-Readings sind aktuell (der Shelly misst im Sekundentakt). Du kannst dann auch am Reading source erkennen, wodurch der Schaltvorgang ausgelöst wurde. Eine Action beispielsweise auf den Tastereingang am Shelly wird deswegen nicht benötigt und sollte im Sinne geringerer Systemlasten nicht aktiviert sein.
*) wieso die Temperatur nur alle 4 Minuten kommt muss ich mir anschauen.
Jetzt bin ich mal gespannt, wie gut das Ganze funzt.
Zitat von: beSmart am 27 März 2024, 21:18:22Danach habe ich ein Gerät in Fhem angelegt. (define Li.Kueche.Deckenlampe Shelly 192.168.178.113) Habe erwartet, das ich jetzt ein Gerät mit zwei Kanälen habe. Dem war bei mir aber nicht so, also habe ich ein zweites Gerät mit der gleichen IP angelegt und jedem Gerät 1x das "attr defchannel 0" und dem anderen "attr defchannel 1" zugeordnet. Jetzt kann ich die Relais per Fhem schalten, allerdings werden beim Schalten von Kanal0 beide Relais ein- bzw. ausgeschaltet. Außerdem steht state immer auf OK, ich hätte gern ein Symbol bzw. den Status An/aus.
Du hast sehr wohl ein Gerät mit 2 Kanälen, nur eben nicht in der Übersichtsanzeige. Lass dir mit
set <name> xtrachannels zwei Proxy-Devices anlegen. Dann hast du zusätzlich zwei getrennte Geräte. Und mit den Befehlen ON und OFF im Shelly-Device kannst du bequem beide Kanäle gleichzeitig schalten.
@Hadl
ZitatHier würden mir am Anfang wirklich 10 Sekunden etwas bringen um z.B. abschätzen
Das ist ziemlich sinnlos, weil sich die Temperaturen auch bei einer Zirkulationsleitung nicht so schnell ändern.
ZitatManche Signale wie Power währen trotzdem schon mindestens jede Minute mal interessant. Vielleicht ist das aber auch nur meine Vorliebe für Viele Diagramme mit guter Auflösung.
Den Begriff "Signale" kennen wir in FHEM nicht. Es ist außerdem sonnenklar, dass eine Vielzahl von Shelly-Devices die FHEM-Hauptschleife ganz schön ausbremsen können - aus dem Grund schlägt Starkstrombastler ja vor, die Regelung der Zirkulationspumpe unabhängig von dieser Hauptschleife zu machen. Bei mir ist das seit inzwischen mehr als 10 Jahren durch ein drahtgebundenes System realisiert. Dessen Latenz und Belastung der FHEM-Hauptschleife sind so gering, dass die Regelung und Messung problemlos in FHEM gemacht werden können, siehe hier: https://wiki.fhem.de/wiki/1W-WPump.
@beSmart
ZitatHabe erwartet, das ich jetzt ein Gerät mit zwei Kanälen habe. Dem war bei mir aber nicht so, also habe ich ein zweites Gerät mit der gleichen IP angelegt und jedem Gerät 1x das "attr defchannel 0" und dem anderen "attr defchannel 1" zugeordnet.
Schwerer Fehler, man legt niemals verschiedene Devices an, die auf dieselbe IP-Adresse zugreifen. Und das mit den Kanälen steht seit Anbeginn in der CommandRef zum Modul.
LG
pah
Zitat von: Starkstrombastler am 27 März 2024, 22:09:43Der CSFR-Token muss halt bei jedem Neustart von FHEM aktualisiert werden. Das ist in der aktuellen Modulversion aber noch nicht so schön gelöst (zyklische Prüfung). Passwort sollte gehen, muss aber manuell eingetragen werden.
HTTPS derzeit vom Modul nicht unterstützt.
OK, ich hab nun mal ein neues FHEMWEB und allow ohne Https, Passwort und CSFR angelegt.
Zitat von: Starkstrombastler am 27 März 2024, 22:09:43In der aktuellen Modulversion wird die Action gelöscht, wenn du das Attr webhook entfernst.
Das automatische Update der Webhooks beschränkt sich auf Portnummer und CSFR-Token und das auch nur, wenn der Name der Action mit _Unterstrich_ anfängt und aufhört.
Ich hab sie nun manuel bearbeitet, bisher wurde von fhem noch nichts überschrieben.
Zitat von: Starkstrombastler am 27 März 2024, 22:09:43Das ist davon abhängig, was der Shelly bereitstellt. Du kannst natürlich auch eine Action mit dem Sensorwert an FHEM adressieren. Sollte ohnehin automatisch angelegt worden sein. Du kannst auch mit set <name> interval 10 das Interval mit dem Einschalten der Pumpe verringern und dann wieder mit set <name> interval -1 auf den Originalwert zurückgehen.
Naja viele der Werte thes Shelly sind schon in kürzeren Zeiten, oder noch besser bei Änderungen relevant. Mit den Werten die einen Hook haben klappt das jetzt auch gut. Andere wie z.B. Strom oder Leistung muss ich weiterhin Pollen. Dafür nehm ich jetzt 60 Sekunden.
Zitat von: Starkstrombastler am 27 März 2024, 22:09:43Wenn der Shelly via Action/Webhook einen Befehl an das Modul sendet (z.B. Ausgang ist EIN), wird dieser Befehl sofort verarbeitet und mit einer Sekunde Verzögerung eine Anfrage get <shelly> status gestartet. So werden alle Status-Werte*) abgeholt und die Power-Readings sind aktuell (der Shelly misst im Sekundentakt). Du kannst dann auch am Reading source erkennen, wodurch der Schaltvorgang ausgelöst wurde. Eine Action beispielsweise auf den Tastereingang am Shelly wird deswegen nicht benötigt und sollte im Sinne geringerer Systemlasten nicht aktiviert sein.
Warum sollte denn nur der erste Wert nach einer Sekunde relevant sein. Das wäre dann z.B. der Anlaufstrom, wenn aber der Strom im Betrieb sinkt wäre das auch interessant.
Bei meiner kleinen Pumpe spielt das keine Rolle, die hat immer ca. 5W
Was aber genau beim Status alles dabei ist hab ich noch nicht rausgefunden, es werden auf jedem Fall einige Werte aktualisiert, wenn ein/ausgeschalten wird.
Zitat von: Starkstrombastler am 27 März 2024, 22:09:43*) wieso die Temperatur nur alle 4 Minuten kommt muss ich mir anschauen.
Jetzt bin ich mal gespannt, wie gut das Ganze funzt.
Jetzt klappts super, auch wenn mir das anlegen des FHEMWEB und des allow doch etwas Zeit gekostet hat, da ich durch ein fehlendes "global" im FHEMWEB nichts vom Shelly bekommen hab.
Naja ein bischen schlechtes Gefühl bleibt, jetzt eine unsichere Hintertür geöffnet zu haben...
Zitat von: Prof. Dr. Peter Henning am 28 März 2024, 04:25:24@Hadl
Das ist ziemlich sinnlos, weil sich die Temperaturen auch bei einer Zirkulationsleitung nicht so schnell ändern.
Wenn ich die Pumpe einschalte, steigt nach 1-3 Minuten die Temperatur am Rücklauf doch ziemlich schnell an, selbst in 10 Sekunden tut sich da einiges.
Ob man den Punkt aber so genau braucht ist sicherlich fraglich. Man könnte die Pumpe auch problemlos noch ne Minute länger laufen lassen, nachdem das System schon durchgewärmt ist.
Zitat von: Prof. Dr. Peter Henning am 28 März 2024, 04:25:24Den Begriff "Signale" kennen wir in FHEM nicht. Es ist außerdem sonnenklar, dass eine Vielzahl von Shelly-Devices die FHEM-Hauptschleife ganz schön ausbremsen können - aus dem Grund schlägt Starkstrombastler ja vor, die Regelung der Zirkulationspumpe unabhängig von dieser Hauptschleife zu machen. Bei mir ist das seit inzwischen mehr als 10 Jahren durch ein drahtgebundenes System realisiert. Dessen Latenz und Belastung der FHEM-Hauptschleife sind so gering, dass die Regelung und Messung problemlos in FHEM gemacht werden können, siehe hier: https://wiki.fhem.de/wiki/1W-WPump.
Ja, ich hab vor soviel es geht den Shelly intern machen zu lassen.
Ein paar Verknüpfungen, z.B. aktivieren der Pumpe wenn der Sollwert durch den Brenner fast erreicht ist um die desinfektion zu verbessern muss ich aber dann in Fhem machen.
Ein Heizstab zur PV Anlage ist auch noch geplant, hier könnten auch ein paar Fhem Logiken kommen.
Das ist jetzt doch sehr Off-Topic, hier geht es um den Support für das Modul, bitte zu solchen Fragen wie "Zirkulationspumpensteuerung" einen eigenen Thread aufmachen. Dort kann ich auch gerne etwas zu dem Thema "Desinfektion" schreiben, da kursieren nämlich vollkommen absurde Ideen.
Und bitte nicht jedesmal ganze Absätze zitieren - das bläst die Datenmenge hier im Forum unnötig auf.
LG
pah
@Hadl: Das hört sich insgesamt doch ganz gut an. Ich muss mich jetzt leider etwas kurz fassen, daher nur eine Anmerkung:
Zitat von: Hadl am 29 März 2024, 02:28:50Warum sollte denn nur der erste Wert nach einer Sekunde relevant sein. Das wäre dann z.B. der Anlaufstrom, wenn aber der Strom im Betrieb sinkt wäre das auch interessant.
Nein, es geht nicht um den Anlaufstrom (das spielt sich im Milli-Sekunden Bereich ab). Fragt man den Status des Shelly direkt nach dem Einschalten ab, bekommt man als Antwort 0 Watt, obwohl die Pumpe läuft. Weil das etwas blöd wäre, gibt es die 1 Sekunde Verzögerung. Das ist die Periode, mit der der Shelly Strom/Leistung ermittelt.
Hi,
gibt es im Shellymodul ein Problem mit der Sommer- / Winterzeitumstellung ?
Siehe: https://forum.fhem.de/index.php?topic=137711.0 (https://forum.fhem.de/index.php?topic=137711.0)
Zitat von: Jewe am 31 März 2024, 20:56:17Hi,
gibt es im Shellymodul ein Problem mit der Sommer- / Winterzeitumstellung ?
Siehe: https://forum.fhem.de/index.php?topic=137711.0 (https://forum.fhem.de/index.php?topic=137711.0)
Hallo,
es wird zwei mal fhem('{$isdst}') im Modul aufgerufen. Mit fhem('{$isdst}', 1) wird der Log verbose 3 Eintrag unterbunden.
Grüße Jörg
Zitat von: JoWiemann am 31 März 2024, 21:36:28Zitat von: Jewe am 31 März 2024, 20:56:17Hi,
gibt es im Shellymodul ein Problem mit der Sommer- / Winterzeitumstellung ?
Siehe: https://forum.fhem.de/index.php?topic=137711.0 (https://forum.fhem.de/index.php?topic=137711.0)
Hallo,
es wird zwei mal fhem('{$isdst}') im Modul aufgerufen. Mit fhem('{$isdst}', 1) wird der Log verbose 3 Eintrag unterbunden.
Grüße Jörg
Im Modul selbst, oder ?
Danke, Jens
Zitat von: Jewe am 31 März 2024, 21:39:17Zitat von: JoWiemann am 31 März 2024, 21:36:28Zitat von: Jewe am 31 März 2024, 20:56:17Hi,
gibt es im Shellymodul ein Problem mit der Sommer- / Winterzeitumstellung ?
Siehe: https://forum.fhem.de/index.php?topic=137711.0 (https://forum.fhem.de/index.php?topic=137711.0)
Hallo,
es wird zwei mal fhem('{$isdst}') im Modul aufgerufen. Mit fhem('{$isdst}', 1) wird der Log verbose 3 Eintrag unterbunden.
Grüße Jörg
Im Modul selbst, oder ?
Danke, Jens
Hallo Jens,
wir befinden uns im Support Thread zum Modul 36_Shelly.pm
Grüße Jörg
Hallo Jörg,
hast natürlich recht... so nun ist wieder Ruhe im Logfile...
Danke, Jens
Darf ich bitte mit einem anderen Problem stören, es ist eine vermutlich dumme Frage:
Ich habe etwa 20 plus1pm und plus2pm verbauen lassen, angebunden über ein Wlan mit Mash-Expander. Wenn nun der Strom kurz weg war (Stadtwerke oder auch Sicherung mal aus), melden sich nicht alle Shelly zurück. Auf den ersten Blick wirkt es so als ob sie das erst nach einer Zustandsänderung tun. Blöd ist das insbesondere bei Steckdosen.
Was macht ihr, um das Problem zu entgehen? Falls ihr das Problem nicht habt - wie würdet ihr das angehen? Da gibt es doch im Shelly irgendwelche Web-Kommandos, kann man die dafür irgendwie missbrauchen? Andere Ideen?
Zunächst mal: vielen Dank für die weitere Pflege! :)
Ich hab zugegebenermassen mal abgewartet, bis etwas Ruhe in das Shelly-Thema kam aber nun wollte ich updaten 8)
Zunächst mal auf meinem Testsystem...
Fhem update durchgeführt und:
- beim 3EM ist mir aufgefallen, dass nun ein webCmd da ist (also die "klickbaren" on/off), kriegt man ja weg, indem man webCmd : setzt <- done
ebenfalls ist nun mein stateFormat bzw. das was angezeigt wird "grün", ok auch das lässt/ließ sich beheben, indem ich einfach weitere Formatierungen angegeben habe <- done
- bei Shelly1 usw. ist mir nichts aufgefallen :)
EDIT: außer, wenn, wie bei mir, die FW zu alt ist ;)
- allerdings ist bei meinem Shelly 2.5 als roller das Reading state "unbrauchbar"! "Früher" stand hier moving_up/moving_down/stopped "Jetzt" (nach update) steht dort pct-xxx also der pct-Wert. Damit ist nat. mein devStateIcon/stateFormat und meine "Klick-Steuerung" nicht mehr möglich :-\ Und: ich sehe da jetzt leider keine (simple) Lösung auf meiner Seite (außer ein wildes userReadings: wenn pct weniger wird, dann ist wohl moving_down, wenn sich pct nicht ändert: stopped ABER: das krieg ich ja mangels Events nicht mit :-\ und wenn pct größer wird, dann ist moving_up)
Und eine Kleinigkeit noch: beim Einfügen per rawDef (vom aktuellen auf das Testsystem zum Testen) kam die Meldung "[Shelly_Attr] Schaltaktor_WoZi_Rollo: Setting the mode attribute for this device is not possible only works for model=shelly2|shelly2.5|shellyplus2pm|shellypro2|shellyrgbw|shellybulb" ist nicht schlimm und wird ja dann auch selbst behoben (bzw. habe ich einfach die rwaDef noch mal eingefügt und dann ging es ohne Meldung)... Das ist aber nur "sehr kosmetisch" ;)
Anbei mal ein altes list (36_Shelly.pm 26017 2022-05-02 07:04:23Z phenning):
Internals:
DEF 192.168.10.160
DURATION 0
FUUID 613e30d1-f33f-753d-a707-857b132e65273e46
INTERVAL 5
MOVING stopped
NAME Schaltaktor_WoZi_Rollo
NR 2054
STATE 1:100
<br>
2:stopped
3:stopped
4:stopped
<br>
5:default
TARGETPCT 100
TCPIP 192.168.10.160
TYPE Shelly
eventCount 209592
READINGS:
2021-09-12 18:54:42 cloud disabled
2022-02-27 22:48:44 config btn_type= [channel 0]
2024-04-03 12:59:48 energy_0 35.8
2022-02-03 16:02:49 firmware v1.11.7
2024-04-03 12:59:59 inttemp 55
2024-04-03 12:59:59 last_dir up
2024-03-29 00:55:24 network <html>connected to <a href="http://192.168.10.160">192.168.10.160</a></html>
2024-04-03 12:59:59 pct 100
2024-04-03 12:59:59 position open
2024-04-03 12:59:59 power 0
2024-04-03 12:59:48 power_0 0
2022-02-27 22:48:44 relais_0_sw default
2024-04-03 12:59:59 state stopped
2021-09-12 18:55:42 stop_reason normal
Attributes:
alias Rollo
comment disable local switches:
set Rollo config btn_type detached 0
(re)enable local switches:
set Rollo config btn_type momentary 0
devStateIcon {my $ShutterPos=ReadingsNum($name, "pct", 100); my $ClosedPos = AttrNum($name, "my_closedposition", 25); my $icon="1..*:fts_shutter_100"; if($ShutterPos > 80){$icon="1..*:fts_shutter_10"}elsif($ShutterPos > 60){$icon="1..*:fts_shutter_30"}elsif($ShutterPos > 40){$icon="1..*:fts_shutter_50"}elsif($ShutterPos > 20){$icon="1..*:fts_shutter_80"}; $icon .= " 2.stopped:control_arrow_down:pct+$ClosedPos 2.moving_up:control_arrow_down 2.moving_down:control_arrow_down\@red 3..*:time_manual_mode:stop 4.moving_down:control_arrow_up 4.stopped:control_arrow_up:open 4.moving_up:control_arrow_up\@red"; $icon.=" 5.detached:fts_shutter_manual\@red:default 5.default:fts_shutter_automatic\@green:detach"; return $icon;}
event-on-change-reading .*
group Klima
icon fts_shutter_updown
interval 5
mode roller
model shelly2.5
my_closedposition 25
my_shadowposition 62
room Overview Ambient,Wohnzimmer
sortby 06
stateFormat 1:pct
<br>
2:state
3:state
4:state
<br>
5:relais_0_sw
userattr my_shadowposition my_closedposition
webCmd :
Und ein neues list (36_Shelly.pm 28696 2024-03-22 08:36:42Z Starkstrombastler):
Internals:
CFGFN
DEF 192.168.10.160
DURATION 0
FUUID 660d3462-f33f-ff8d-5838-d718b546d56e3a7b
INTERVAL 5
MOVING stopped
NAME Schaltaktor_WoZi_Rollo
NR 245
SHELLY SHSW-25
STATE 1:100
<br>
2:pct-100
3:pct-100
4:pct-100
<br>
5:relais_0_sw
TCPIP 192.168.10.160
TYPE Shelly
eventCount 160
units 0
OLDREADINGS:
READINGS:
2024-04-03 12:50:16 cloud disabled
2024-04-03 12:50:38 coiot enabled
2024-04-03 12:50:38 coiot_period 15
2024-04-03 13:00:18 config mode=roller [channel s]
2024-04-03 13:08:01 energy 44.6
2024-04-03 12:50:16 firmware v1.11.7
2024-04-03 13:00:21 input_0 off
2024-04-03 13:00:21 input_1 off
2024-04-03 13:13:24 inttemp 54.9
2024-04-03 12:50:16 inttempStatus Normal
2024-04-03 13:07:20 last_dir up
2024-04-03 12:50:16 network <html>connected to <a href="http://192.168.10.160">192.168.10.160</a></html>
2024-04-03 13:12:17 network_rssi -57
2024-04-03 12:50:16 network_ssid MadMax-IoT-Network
2024-04-03 12:50:38 network_threshold -70
2024-04-03 13:00:21 overpower 0
2024-04-03 13:07:20 pct 100
2024-04-03 13:07:20 position open
2024-04-03 13:07:10 power 0
2024-04-03 13:07:05 power_last 301.8 down
2024-04-03 13:07:20 state pct-100
2024-04-03 12:50:21 stop_reason normal
2024-04-03 12:50:20 webhook_cnt 0
2024-04-03 12:50:20 webhook_ver 0
helper:
Sets config interval password reboot:noArg update:noArg name reset:disconnects closed open stop:noArg pct:slider,0,1,100 delta zero:noArg predefAttr:noArg
Attributes:
alias Rollo
comment disable local switches:
set Rollo config btn_type detached 0
(re)enable local switches:
set Rollo config btn_type momentary 0
devStateIcon {my $ShutterPos=ReadingsNum($name, "pct", 100); my $ClosedPos = AttrNum($name, "my_closedposition", 25); my $icon="1..*:fts_shutter_100"; if($ShutterPos > 80){$icon="1..*:fts_shutter_10"}elsif($ShutterPos > 60){$icon="1..*:fts_shutter_30"}elsif($ShutterPos > 40){$icon="1..*:fts_shutter_50"}elsif($ShutterPos > 20){$icon="1..*:fts_shutter_80"}; $icon .= " 2.stopped:control_arrow_down:pct+$ClosedPos 2.moving_up:control_arrow_down 2.moving_down:control_arrow_down\@red 3..*:time_manual_mode:stop 4.moving_down:control_arrow_up 4.stopped:control_arrow_up:open 4.moving_up:control_arrow_up\@red"; $icon.=" 5.detached:fts_shutter_manual\@red:default 5.default:fts_shutter_automatic\@green:detach"; return $icon;}
event-on-change-reading .*
group Klima
icon fts_shutter_updown
interval 5
mode roller
model shelly2.5
my_closedposition 25
my_shadowposition 62
room Overview Ambient,Wohnzimmer
sortby 06
stateFormat 1:pct
<br>
2:state
3:state
4:state
<br>
5:relais_0_sw
userattr my_shadowposition my_closedposition
webCmd :
Und auch 2 Bilder, wie es vor und nach dem Update aussieht...
Ich hoffe da lässt sich was machen...
...ansonsten muss ich shelly wohl vom Update ausschliessen :-\
Und halt dann auf neue Shelly verzichten :-\
EDIT: ok, "Kommando halb zurück". Hat wohl etwas gedauert bis sich das Device neu "eingerüttelt" hat? Jetzt kommt zumindest wieder drive-up bzw. drive-down :) Für stopped (das es nicht mehr gibt) muss ich mir halt jetzt was überlegen... Mal sehen...
EDIT: so nun tut es (fast) wieder. statt stopped einfach "pct-(1?[0-9]?[0-9])" und tut. ABER: irgendwie wird pct gleich auf das Ziel gesetzt und es gibt (zumindest bei mir) keine aktuellen "Zwischenwerte" mehr :-\ Auch in anderen Readings nicht. Am Ende der Fahrt, also wenn ich dann vor Ende stoppe steht (nat.) wieder die aktuelle Position drin. Das Reading position verhält sich parallel... Ist jetzt nicht so wichtig aber dann habe ich halt keine unterschiedlichen Icons mehr während fahrt (nicht, dass ich da groß drauf schauen würde ;) Aber naja 8) )...
EDIT: ok war wohl schon immer so, also dass beim Fahren keine "Zwischen-Icons" kamen... ;) -> SORRY! 8)
ACHJA: ist nat. keine Kritik an der tollen Arbeit! Aber wenn bei/nach einem Update so viel zu tun ist ;) Daher natürlich: vielen Dank weiterhin!!
EDIT: werde noch etwas testen und v.a. FWs updaten und dann verm. morgen fhem auch auf dem Hauptsystem "auf Stand" bringen... :)
Gruß, Joachim
Zitat von: MadMax-FHEM am 03 April 2024, 13:19:46EDIT: werde noch etwas testen und v.a. FWs updaten und dann verm. morgen fhem auch auf dem Hauptsystem "auf Stand" bringen...
Oh je, hier hat das Updaten wohl ganz schön an den Nerven gefressen...
Möglicherweise sind die Probleme im
rawDef begründet: Im Standardverfahren wird zunächst 'nur' das Device mittels
define definiert. In der aktuellen Version dauert das eine Weile, weil verschiedene Abfragen mittels Timer gestaffelt durchgeführt werden. Wenn dann die
attr dazwischenfunken könnte es dann solche Effekte geben.
Wenn es bei Dir nicht so eilig ist, schlage ich vor noch etwas abzuwarten und dann mit dem "großen" Update des Shelly-Moduls weiter zu machen. Da wird auf diese Timer verzichtet und die Definition ist deshalb wesentlich flüssiger. Und vieles mehr.
Das Update wird zunächst als Beta-Version zur Verfügung gestellt (siehe hier (https://forum.fhem.de/index.php?topic=137222.0)) - Tester willkommen ! !
Ich muss aber alle Shelly-Fans noch etwas vertrösten - eben kommt alles zusammen: die Glasfaser-Truppe will meinen Hof aufreisen, der Anstreicher stellt das Gerüst ans Haus, der Heizi steht mit der WP in den Startlöchern - und überall gibt es vorab noch einiges an Technik zu tunen....
@Starkstrombastler:
ZitatIch muss aber alle Shelly-Fans noch etwas vertrösten - eben kommt alles zusammen
Einerseits habe ich ein klein wenig ein schlechtes Gewissen - aber andererseits bin ich Dir sehr dankbar, dass Du das Modul übernommen hast. Die Komplexität des Shelly-Zoos ist inzwischen ganz enorm. Kleiner Tipp deshalb von meiner Seite: Die Aktie wird inzwischen auch in Deutschland gehandelt. Hat ihren Wert innerhalb eines Jahres in etwa verdreifacht, https://www.boerse-frankfurt.de/aktie/allterco-jsco
@curt:
Zitatmelden sich nicht alle Shelly zurück
Wieso sollten diese sich "melden"?
LG
pah
Zitat von: Starkstrombastler am 07 April 2024, 18:16:15Oh je, hier hat das Updaten wohl ganz schön an den Nerven gefressen...
Hallo Starkstrombastler!
Alles halb so wild (inzwischen) ;)
Sorry (noch mal) wegen dem "Wind"!
Zitat von: Starkstrombastler am 07 April 2024, 18:16:15Möglicherweise sind die Probleme im rawDef begründet: Im Standardverfahren wird zunächst 'nur' das Device mittels define definiert. In der aktuellen Version dauert das eine Weile, weil verschiedene Abfragen mittels Timer gestaffelt durchgeführt werden. Wenn dann die attr dazwischenfunken könnte es dann solche Effekte geben.
Ja, habe ich auch angenommen, dass eben per rawDef (beim Übertragen vom Haupt auf das Testsystem) der zeitliche Ablauf "nicht passt"...
Ist aber nicht schlimm.
Entweder warten oder einfach noch mal drüber...
Homematic CUL_HM ist bzgl. rawDef (noch) viel "aufwändiger"... 8)
Zitat von: Starkstrombastler am 07 April 2024, 18:16:15Wenn es bei Dir nicht so eilig ist, schlage ich vor noch etwas abzuwarten und dann mit dem "großen" Update des Shelly-Moduls weiter zu machen. Da wird auf diese Timer verzichtet und die Definition ist deshalb wesentlich flüssiger. Und vieles mehr.
Too late 8)
Habe das Hauptsystem schon einem Update unterzogen.
Was auf mich zukommt, hatte ich ja beim Testsystem gesehen und war vorbereitet :)
Zitat von: Starkstrombastler am 07 April 2024, 18:16:15Das Update wird zunächst als Beta-Version zur Verfügung gestellt (siehe hier (https://forum.fhem.de/index.php?topic=137222.0)) - Tester willkommen ! !
Leider bin ich die nächsten Tage dienstlich unterwegs...
...aber danach: Testsystem hab ich ja noch (genau für "sowas")...
Noch mal: vielen Dank!!!Gruß, Joachim