Support-Thread Modul 36_Shelly.pm

Starkstrombastler · 06 Juni 2023, 17:35:27

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 show
Das 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.

RalfRog · 06 Juni 2023, 22:59:07

Ah super schau ich mir an

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.

RalfRog · 07 Juni 2023, 09:58:21

Sieht ja ganz gut aus (Gen1: Shelly1 & Shelly1PM)

Code Auswählen

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

Starkstrombastler · 07 Juni 2023, 12:41:57

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.

Mal sehen...

RalfRog · 07 Juni 2023, 13:42:54

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!!!

RalfRog · 10 Juni 2023, 17:02:39

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

Starkstrombastler · 13 Juni 2023, 10:55:20

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> status
Das 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 0
In 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.

RalfRog · 13 Juni 2023, 22:29:14

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

RalfRog · 16 Juni 2023, 18:16:18

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:

Code Auswählen

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:

Code Auswählen

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 seconds

Was 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.

RalfRog · 16 Juni 2023, 18:45:39

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.

Code Auswählen

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:

Code Auswählen

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:

Code Auswählen

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:

Code Auswählen

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 Create

2023.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.

Starkstrombastler · 16 Juni 2023, 21:05:40

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 "shellyplusplugS". Das kann also nicht gehen.
Für einen schnellen Test bitte im Quellcode Zeile 257 das "S" entfernen.

Code Auswählen

"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

RalfRog · 16 Juni 2023, 23:42:26

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

RalfRog · 18 Juni 2023, 11:54:39

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)

Starkstrombastler · 18 Juni 2023, 18:01:53

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

Code Auswählen

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

Code Auswählen

http://<ip_des_Shelly>/rpc/shelly.ListMethods

RalfRog · 18 Juni 2023, 18:40:45

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:53
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
Code Auswählen Erweitern
http://<ip_des_Shelly>/rpc/webhook.ListSupported

Code Auswählen

{"hook_types":["switch.off","switch.on"],"types":{"switch.off":{},"switch.on":{}}}

Zitat von: Starkstrombastler am 18 Juni 2023, 18:01:53
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
Code Auswählen Erweitern
http://<ip_des_Shelly>/rpc/shelly.ListMethods

uiiii - ist ja (nicht unerwartet) deutlich kompexer als Gen1

Code Auswählen

{
	"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:53
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.

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.