Entwicklungs-Thread Modul 36_Shelly.pm

[Starkstrombastler]

Da sich die Anzahl der verfügbaren Shellies stetig vergrößert wird auch das Shelly-Modul 36_Shelly.pm entsprechend weiter entwickelt. Um den Support Thread zu entlasten soll die Weiterentwicklung in diesem Thread separat behandelt werden. Dazu gehört der u.a. Austausch von Testversionen und Auszügen aus der Kommunikation.

Dieser Thread behandelt NICHT die Einbindung der Shellies via MQTT und zugehöriger Templates!

Grundlage des Shelly-Moduls ist die Kommunikation via HTTP. Im Wesentlichen werden von Fhem Anfragen und Schaltbefehle an den Shelly geschickt und dessen Antwort ausgewertet.

Die grundlegenden Anfragen bei den Geräten der 2. Generation sind folgende:

Code Auswählen Erweitern

http://<ip-des-Shelly>/rpc/Shelly.GetStatus
http://<ip-des-Shelly>/rpc/Shelly.GetConfig
http://<ip-des-Shelly>/rpc/Shelly.GetDeviceInfoDa mir nicht alle Shelly-Modelle zur Verfügung stehen und weil sich die Inhalte je nach Konfiguration auch ändern können, bin ich darauf angewiesen, dass mir die Antworten der Shellies zur Verfügung gestellt werden (bitte unbedingt in Code-Tags!).

[JWRu]

Interessant wäre mal, welche Shelly-Sensoren/Aktoren zur Zeit unterstützt werden. Der Shelly-Gerätepark ist ja durch die Übernahme von Qubino (Z-Wave) ziemlich unübersichtlich geworden.
Welche Werte gibt's denn aktuell für das Attribut "model"? Ich habe leider nichts gefunden.

[Starkstrombastler]

Welche Werte gibt's denn aktuell für das Attribut "model"? Ich habe leider nichts gefunden.

Das Attribut model wird in den neueren Versionen des Moduls automatisch ermittelt und gesetzt. In der Attribut-Auswahl erscheint dann dieser Werte und auch 'generic'.

Um zu sehen, welche Werte das Attribut 'model' annehmen kann, kannst du dich wie folgt behelfen: definiere ein Dummy device vom Typ Shelly, z.B. so:  define dummy Shelly 1.2.3.4
Bei der Auswahl des Attributes 'model' werden dann alle derzeit möglichen Werte angeboten.

[JWRu]

Bei der Auswahl des Attributes 'model' werden dann alle derzeit möglichen Werte angeboten.

Super - danke!

[ChristianP5r]

Da mir nicht alle Shelly-Modelle zur Verfügung stehen und weil sich die Inhalte je nach Konfiguration auch ändern können, bin ich darauf angewiesen, dass mir die Antworten der Shellies zur Verfügung gestellt werden (bitte unbedingt in Code-Tags!).

Soll ich den Output des neuen Shelly Plus Uni hier posten oder hast du so ein Gerät selbst verfügbar? Würde mich schon auf eine Implementierung freuen 

[Starkstrombastler]

Soll ich den Output des neuen Shelly Plus Uni hier posten oder hast du so ein Gerät selbst verfügbar?

Ja bitte, hier posten. Habe selbst noch keinen Plus-Uni. Bis eine Testversion verfügbar ist wird es vermutlich aber noch zwei Wochen dauern.

Wenn du den ShellyPlusUni definierst define <name> Shelly <ip> sollte er mit dem Attribut model=generic angelegt werden, da der Plus Uni noch nicht gelistet ist. Du kannst dann versuchen das Attribut model manuell auf "ShellyPro2" zu stellen. Zumindest Ein- und Ausgänge sollten dann verfügbar sein.

[ChristianP5r]

Hallo,

Hier der Output des Shelly Plus Uni. Ich habe bei diesem den Counter (Wasserdurchflusssensor) und den analogen Eingang (Druckmesser/Wasserstand Zisterne) im Einsatz.

/rpc/Shelly.GetStatus

Code Auswählen Erweitern

{"ble":{},"cloud":{"connected":true},"input:0":{"id":0,"state":false},"input:1":{"id":1,"state":false},"input:2":{"id":2,"counts":{"total":86127,"xtotal":179.43,"by_minute":[0,0,0],"xby_minute":[0.00,0.00,0.00],"minute_ts":1709288160},"freq":0.00},"input:100":{"id":100,"percent":87.1},"mqtt":{"connected":true},"switch:0":{"id":0, "source":"init", "output":false},"switch:1":{"id":1, "source":"init", "output":false},"sys":{"mac":"XXXXXXXXXXXX,"restart_required":false,"time":"11:16","unixtime":1709288197,"uptime":1107620,"ram_size":257356,"ram_free":98800,"fs_size":458752,"fs_free":143360,"cfg_rev":22,"kvs_rev":0,"schedule_rev":0,"webhook_rev":0,"available_updates":{"stable":{"version":"1.2.2"}},"reset_reason":1},"wifi":{"sta_ip":"X.X.X.X","status":"got ip","ssid":"X","rssi":-79},"ws":{"connected":false}}

/rpc/Shelly.GetConfig

Code Auswählen Erweitern

{"ble":{"enable":true,"rpc":{"enable":true},"observer":{"enable":false}},"cloud":{"enable":true,"server":"shelly-9-eu.shelly.cloud:6022/jrpc"},"input:0":{"id":0,"name":null,"type":"switch","enable":true,"invert":false},"input:1":{"id":1,"name":null,"type":"switch","enable":true,"invert":false},"input:2":{"id":2,"name":null,"type":"count","enable":true,"count_rep_thr":100,"freq_window":1,"freq_rep_thr":10,"xcounts":{"expr":"x/480","unit":"L"},"xfreq":{"expr":"x/480","unit":null}},"input:100":{"id":100,"name":"Schacht","type":"analog","enable":true,"invert":false,"report_thr":1.0,"range_map":[0.0,38.8],"xpercent":{"expr":null,"unit":null},"range":0},"mqtt":{"enable":true,"server":"X.X.X.X:xxxx","client_id":"shellyplusuni","user":null,"ssl_ca":null,"topic_prefix":"shellyplusuni","rpc_ntf":true,"status_ntf":false,"use_client_cert":false,"enable_rpc":true,"enable_control":true},"switch:0":{"id":0, "name":null,"in_mode":"follow","initial_state":"match_input", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay":60.00},"switch:1":{"id":1, "name":null,"in_mode":"follow","initial_state":"match_input", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay":60.00},"sys":{"device":{"name":null,"mac":"XXXXXXXXXXXX","fw_id":"20240213-140544/1.2.0-gb1b9aa8","discoverable":true,"eco_mode":false},"location":{"tz":"Europe/Vienna","lat":XX.X,"lon":XX.X},"debug":{"level":2,"file_level":null,"mqtt":{"enable":false},"websocket":{"enable":false},"udp":{"addr":null}},"ui_data":{},"rpc_udp":{"dst_addr":null,"listen_port":null},"sntp":{"server":"time.google.com"},"cfg_rev":22},"wifi":{"ap":{"ssid":"ShellyPlusUni","is_open":true, "enable":false, "range_extender": {"enable":false}},"sta":{"ssid":"X","is_open":false, "enable":true, "ipv4mode":"static","ip":"X.X.X.X","netmask":"X.X.X.X","gw":"X.X.X.X","nameserver":"X.X.X.X"},"sta1":{"ssid":null,"is_open":true, "enable":false, "ipv4mode":"dhcp","ip":null,"netmask":null,"gw":null,"nameserver":null},"roam":{"rssi_thr":-80,"interval":60}},"ws":{"enable":false,"server":null,"ssl_ca":"ca.pem"}}

/rpc/Shelly.GetDeviceInfo

Code Auswählen Erweitern

{"name":null,"id":"shellyplusuni","mac":"XXXXXXXXXXXX","slot":0,"model":"SNSN-0043X","gen":2,"fw_id":"20240213-140544/1.2.0-gb1b9aa8","ver":"1.2.0","app":"PlusUni","auth_en":false,"auth_domain":null}
Wenn du weitere Infos benötigst, gib mir einfach Bescheid.

DANKE!

[Neeein]

Hi,

ich habe unter Diesem Link die ShellyBlu (mit MQTT) in Fhem eingebunden.

Da es offensichtlich hier mit dem Shelly Modul weiter geht, wäre es schön, wenn ihr mir dabei helfen könntet, meine unterirdischen Programmierfähigkeiten zu überarbeiten oder einen anderen Lösungsansatz zu finden. 😊
Evtl. könnten wir die Lösung auch in ein neues-, oder in das ShellyModul überführen? Finde die Dummylösung von mir einfach nicht wirklich elegant...

Ich bin mir bewusst dass oben steht kein MQTT, aber will es trotzdem nicht unversucht lassen eine bessere Lösung als meine zu finden.


LG N3331N

[Starkstrombastler]

Evtl. könnten wir die Lösung auch in ein neues-, oder in das ShellyModul überführen?

Was geben denn die Shelly-Gateways aus, wenn du die im ersten Post aufgeführten Anfragen im Browser eingibst? Tauchen die BLU in irgendeiner Weise auf?

[Neeein]

Was geben denn die Shelly-Gateways aus, wenn du die im ersten Post aufgeführten Anfragen im Browser eingibst? Tauchen die BLU in irgendeiner Weise auf?

Da ich deine Frage nicht genau verorten kann bekommst du 2 Antworten

Antwort 1:
Wenn du auf Schritt 4 abzielst erstelle ich zuerst ein Notify, welcher auf Events der MQTT Devices (Plus/Pro) reagiert die ShellyBludaten betreffen. Löst das Notify aus wird immer die 99Utils aufgerufen um die Bludaten vom entsprechenden MQTT PRO/Plus) auszulesen und einen Dummy zu erstellen oder zu aktualisieren. Im Dummy sind dann die entsprechenden aus dem Payload Daten hinterlegt. 

Antwort 2:
Die Gateways reagieren auf die Bluetooth Beacons und verarbeiten diese über das eingefügte Skript. Die Gateways sind als MQTT-Devices in Fhem angelegt. Die Daten der ShellyBlu werden in den Readings der Shelly Pro/Plus MQTT-Devices abgelegt.
Da lese ich sie aus und schreibe Sie in einen Dummy, der dann das "ShellyBluDevice" darstellt.

Readings vom MQTTDevice:
*address ist die MAC des ShellyBlu
 Du darfst diesen Dateianhang nicht ansehen.

Dummy:
*address ist die MAC des ShellyBlu
 Du darfst diesen Dateianhang nicht ansehen.





Ich hoffe ich konnte deine Frage richtig deuten und beantworten, falls nicht bitte ich dich, sie mir einfach nochmal in anderer Form zu stellen

LG

[Starkstrombastler]

Da ich deine Frage nicht genau verorten kann bekommst du 2 Antworten

Nein, nein, das ist garnicht das was ich wollte.

Gib das hier mal in die Adresszeile deines Browsers ein, wobei die IP-Adresse des Gateway-Shelly entsprechend eingesetzt werden muss:

http://<ip-des-gateway-shelly>/rpc/Shelly.GetStatus

Der Shelly liefert dann Daten (als JSON), so ähnlich wie das ChristianP5r ein paar Posts weiter oben für den Shelly Plus Uni gepostet hat.

Da interessiert mich, ob bzw. wie der Shelly BLU in der Datenstruktur des Gateway-Shelly auftaucht.

[Neeein]

{"ble":{},"cloud":{"connected":false},"input:0":{"id":0,"state":false},"mqtt":{"connected":true},"script:1":{"id":1,"running":true,"mem_used":2982,"mem_peak":4438,"mem_free":22218},"switch:0":{"id":0, "source":"http", "output":false, "apower":0.0, "voltage":226.5, "freq":50.0, "current":0.000, "aenergy":{"total":1272.870,"by_minute":[0.000,0.000,0.000],"minute_ts":1709445900}, "ret_aenergy":{"total":0.000,"by_minute":[0.000,0.000,0.000],"minute_ts":1709445900},"temperature":{"tC":38.0, "tF":100.3}},"sys":{"mac":"84FCE63CD4FE","restart_required":false,"time":"07:05","unixtime":1709445926,"uptime":207222,"ram_size":258780,"ram_free":88876,"fs_size":1048576,"fs_free":704512,"cfg_rev":26,"kvs_rev":1,"schedule_rev":1,"webhook_rev":0,"available_updates":{},"reset_reason":3},"wifi":{"sta_ip":"192.168.20.69","status":"connecting","ssid":"WLAN IoT","rssi":-90},"ws":{"connected":false}}

Ich würde sagen nein.

[Starkstrombastler]

"ble":{}

Hätte gedacht, dass sich hier etwas zu BLU findet.

Vielleicht kann jemand anderes noch etwas zum Stichwort "Shelly BLU Gateway ohne MQTT" beitragen. Ansonsten wäre das erstmal kein Thema für das Shelly-Modul.

[Starkstrombastler]

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:

Code Auswählen Erweitern

http://<IP>/rpc/Wifi.ListAPClients
Das ergibt z.B. folgende Ausgabe:

Code Auswählen Erweitern

{
   "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



Ein erster Ansatz dazu wird sich im nächsten Beta-Update, welches hier veröffentlicht wird, finden.

[carlos]

Da stellt sich mir noch die Frage, ob man die shellies hinter dem rangeextender dann auch über das module definieren kann bzw. dann steuern kann.

Ich fürchte aber nicht.

Ich habe mal 3 tasmota Geräte hinter dem shelly rangeextender gesetzt.
Die funktionieren über MQTT dann auch sehr gut über das MQTT2 device modul.

Dann müsste ich aber bei den Shellies auf MQTT switchen, was ich aber ungern machen würde.

Denn das Shelly module ist (für mich) die bessere Wahl.

Gruß

Hubert

[Starkstrombastler]

Denn das Shelly module ist (für mich) die bessere Wahl.

freut mich zu hören.

Der Range-Extender wird im nächsten Update enthalten sind, das ist jetzt in der finalen Bearbeitung. Das sieht dann so aus, dass man auf dem Shelly mit aktivem Range-Extender die angebundenen Devices sieht. Im Modul wird dafür für jedes Device ein Reading ausgegeben, welches MAC, die IP des Access-Points, die (verlinkte) Adresse (mit Portnummer) im regulären WLAN sowie den Namen des Shelly (hier: X178) angibt:
Du darfst diesen Dateianhang nicht ansehen.
Das entfernte Device wird also im Shelly-Modul über die IP-Adresse des Range-Extender-Shellies zuzüglich einer vom Shelly vorgegebenen Port-Nummer (im Beispiel: 11101) definiert und verhält sich ansonsten wie ein "normaler" Shelly.

[carlos]

Ja das gefällt mir schon sehr gut. Da kennt man zumindest auf dem rangeextender die entfernten devices.
Aber kann ich dann auch ein:

Code Auswählen Erweitern

define <myEntferntesDevice Shelly> 192.168.178.211:11101machen um das device dann mit FHEM zu steuern?

Die shelly app funktioniert nach wie vor und auch der Browser Zugriff über IP:port.

[Starkstrombastler]

define <myEntferntesDevice Shelly> 192.168.178.211:11101

Ja, genau so habe ich das ja beschrieben.

[Jens_B]

Hat jetzt nicht unbedingt was mit dem Shelly Modul zu tun, aber ist jemandem eigentlich schon aufgefallen das die neuen Shellys, welche die Rangeextendermöglichkeit haben, ihr eigenes ungesichertes EinrichtungsWLAN nicht mehr abschalten, nachdem man sie ins eigene WLAN gebracht hat? Nicht schön...

gruß
Jens

[carlos]

By design würde ich sagen und du kannst es ja einfach absichern und gut is.
Gruß


Hubert

[Jens_B]

Der IT Affine Nutzer wird das machen. Aber ein einfacher Anwender eher nicht. Das haben die alten nicht gemacht. Und aus meiner Sicht ist das eine Sicherheitslücke. Jeder kann sich einfach mit dem Ding verbinden und kommt quasi in das Hauseigene Netz. Schlecht.
Man rechnet ja auch nicht unbedingt damit, das das Einrichtungs WLAN anbleibt, nachdem man den Shelly ins eigene Netz gebracht hat.

Gruß
Jens

[VB90]

Den "hauseigenen" AP zu deaktivieren dürfte reichen.
Mache ich sowieso, wenn ich das Bluetooth deaktiviere, um die Rechenlast zu minimieren.

Ich habe neulich mal "zum Spaß " den Eco-Modus aktiviert. Das bringt über 10Grad bei der internen Temperatur.
Erstaunlich viel in meinen Augen.

vb

[Jens_B]

Ja das ist klar das das reicht. Haben die alten Shellys automatisch gemacht, die neuen nicht. Und als IT Afiner Nutzer ist das klar das man dort schaut und Ausschaltet. Normaler Anwender nicht.
Ich habe hier in wenigstens 3 offene Shellys in der Nachbarschaft mit denen ich mich verbinden kann, weil die Einrichter es nicht besser wissen.
Ich finde sowas einfach unschön. Mit etwas Kenntnissen spielt man auf die Teile eine entsprechende Firmware auf...

[ChristianP5r]

Hallo,

Hier der Output des Shelly Plus Uni. Ich habe bei diesem den Counter (Wasserdurchflusssensor) und den analogen Eingang (Druckmesser/Wasserstand Zisterne) im Einsatz.

Hallo, ich wollte mal nachfragen ob es schon eine neue Version die den Shelly Plus Uni beinhaltet zum testen gibt?
danke

[Starkstrombastler]

ich wollte mal nachfragen ob es schon eine neue Version die den Shelly Plus Uni beinhaltet zum testen gibt?

die Testversion kommt voraussichtlich morgen!

[Starkstrombastler]

ich wollte mal nachfragen ob es schon eine neue Version die den Shelly Plus Uni beinhaltet zum testen gibt?

Wie versprochen, anbei Version Du darfst diesen Dateianhang nicht ansehen. zum Testen, insbesondere bezüglich der neuen Modelle ShellyPlusUni, ShellyPlusDimmer0-10V und ShellyProDimmer2.

Allerdings ist mir gerade aufgefallen, dass beim ShellyPro3EM nicht alle Readings aktualisiert werden - hier macht das Testen zunächst noch keinen Sinn. (Wer also im großen Stil testen möchte wartet am besten eine verbesserte Version ab).

[carlos]

Hallo,
Ich habe diese Version auch mal getestet hauptsächlich wegen der rangeextender Erweiterung.
Ich habe bei mir einen shelly als rangeextender konfiguriert und dahinter shellies und auch tasmota devices im Einsatz.
Bei den readings bzgl. der rangeextender Funktion wäre mein Vorschlag es so zu machen wie im Bild (ich habe dies bei mir mal in einer sub in myUtils abgebildet)
So hat man die Readings separiert und kann sie entsprechend in den z.b. MQTT2 tasmota devices über userreadings direkt mit integrieren, hier vor allem den externen/internen Link.
Bei den shellies ist das nicht unbedingt das Problem da diese über das Shelly module direkt mit IP:port definiert werden.
Bei MQTT2 (tasmota oder auch andere) devices geht das eben über den MQTT broker.

Nur als Anregung, keine Kritik.

Gruß

Hubert

[Starkstrombastler]

Bei den readings bzgl. der rangeextender Funktion wäre mein Vorschlag es so zu machen wie im Bild...
So hat man die Readings separiert und kann sie entsprechend in den z.b. MQTT2 tasmota devices über userreadings direkt mit integrieren, hier vor allem den externen/internen Link.

Anregungen willkommen! Die Readings könnten dann so aussehen:
ap_clients_0_extlink   http://123.345.123.178:9999
ap_clients_0_intlink   http;//123.345.33.4
ap_clients_0_mac       AA:BB:CC:DD:EE:FF
ap_clients_0_name      myTestShelly

Die Links wären dann so wie bisher klickbar. Allerdings ist der Link dann nicht so einfach z.B. via ReadingsVal() extrahierbar.
Das Reading '..name' wird nur ausgewiesen, wenn eine Name ermittelt werden kann.
Das bisherige Reading (gemäß Beispiel 'ap_clients_0') würde entfallen, um Dopplungen zu vermeiden.

[carlos]

Also mir wäre schon wichtig die interne IP und die externe IP:port mit ReadingsVal zu bekommen.
Einen Link kann man sich ja dann selbst zusammenbauen.
Ich mache das z.B. im stateFormat dann immer so:

Code Auswählen Erweitern

<a href="http://IPAddress" target="_blank">name</a>
oder als zusätzliches userreading am device dann direkt.

Gruß

Hubert

[bjbrill]

Ich teste Beta1 gerade mit dem ShellyPlusDimmer0-10V.
Bis jetzt scheint alles gut zu funktionieren.
Ich hab meine DOIF`s mal auf neue Modul umgebaut
und lasse es jetzt mal paar Tage laufen.
Danke für die Arbeit.

Gruß Björn

[Prof. Dr. Peter Henning]

Ich linke mich hier auch mal rein.

LG

pah

[gamauf]

Hallo!

Habe einen Shelly Pro1PM. Seit einem der letzten FW updates liefert dieser als Antwort auf "/rpc/Switch.GetStatus?id=0" unter anderem den Wert "ret_aenergy":

Code Auswählen Erweitern

{"id":0, "source":"http", "output":true, "apower":-16.9, "voltage":229.8, "freq":50.0, "current":0.255, "pf":0.03, "aenergy":{"total":349902.891}, "ret_aenergy":{"total":309190.757},"temperature":{"tC":42.3, "tF":108.1}}dies scheint die ins Netzt eingespeiste Energie zu sein im Gegensatz zu "aenergy" das die Summe aus bezogener und eingespeister Energie zu sein scheint.
Falls es leicht geht, würde ich mich freuen, wenn das Modul "ret_aenergy" in einem Reading verewigen könnte!

Danke!
Rainer

[Starkstrombastler]

Falls es leicht geht, würde ich mich freuen, wenn das Modul "ret_aenergy" in einem Reading verewigen könnte!

Kein Problem, kommt im nächsten Beta.

"ret_aenergy" ... scheint die ins Netzt eingespeiste Energie zu sein im Gegensatz zu "aenergy" das die Summe aus bezogener und eingespeister Energie zu sein scheint.

Kannst du das beobachten, wie verhält sich aenergy im Einspeisebetrieb?

[gamauf]

Danke!

Ja, "aenergy" zählt immer nur hoch, egal ob Verbrauch od. Eispeisung.

[Starkstrombastler]

Nach langer Ankündiung kommt hier die Beta-2 Version des Shelly-Moduls zum TESTEN.

Wesentliche Änderung ist der Ablauf der Kommunikation mit dem Shelly, d.h. die Abfrage von Status und Konfiguration o.a. erfolgt nicht gleichzeitig bzw. Timer-gesteuert, sondern nacheinander. Dadurch konnten unnötige Wartzeiten entfallen. Dies wird insbesondere bei der Definition von Devices sichtbar.

Neue Geräte wurde aufgenommen und sofern mir ein Gerät zum Testen vorliegt auch bei Bedarf im Code ergänzt.

Einige Readings wurden angepasst/entfernt/ergänzt.

Hier im Forum diskutierte Fehler wurden berücksichtigt.

Bitte beachten: die Online-Hilfe ist ggf. noch nicht überall aktualisiert, im Zweifesfall gilt aber die deutsche Fassung als führend.

Du darfst diesen Dateianhang nicht ansehen.

[caldir65]

Moin,

ich bin erst heute (nach zwei Wochen Abwesenheit wg. Urlaub) dazu gekommen, mit der Beta einen ShellyPus1 und Addon zu testen, da ich nur eine Temperatur, aber keine Luftfeuchte bekomme (vgl. hier) Leider ist es offenbar auch mit der Beta nicht anders. Ich habe auch extra einen weiteren Shelly zum Testen fertig gemacht, der bisher noch nicht mit fhem verbunden war. Anzeige/Daten am Shelly sind vorhanden, in fhem wird jedoch nur die Temperatur angezeigt.

Das Device:

Code Auswählen Erweitern

define ShellyPlus1_Wetter_TH_TEST Shelly 192.168.1.131
attr ShellyPlus1_Wetter_TH_TEST DbLogExclude .*
attr ShellyPlus1_Wetter_TH_TEST group Shelly
attr ShellyPlus1_Wetter_TH_TEST model shellyplus1
attr ShellyPlus1_Wetter_TH_TEST room Arbeitszimmer
#   CFGFN     
#   DEF        192.168.1.131
#   FUUID      668a7dcd-f33f-378b-7d6f-17cb15ffbb9365cf
#   INTERVAL   60
#   NAME       ShellyPlus1_Wetter_TH_TEST
#   NR         1708
#   NTFY_ORDER 50-ShellyPlus1_Wetter_TH_TEST
#   SHELLYID   shellyplus1-441793cf9254
#   STATE      off
#   TCPIP      192.168.1.131
#   TYPE       Shelly
#   eventCount 10
#   units      0
#   READINGS:
#     2024-07-07 13:36:46   addon           sensor
#     2024-07-07 13:36:46   ap              ShellyPlus1-441793CF9254 enabled open
#     2024-07-07 13:36:46   ap_clients      disabled
#     2024-07-07 13:36:46   ble             enabled
#     2024-07-07 13:36:46   cloud           disabled
#     2024-07-07 13:36:46   firmware        v1.3.3
#     2024-07-07 13:36:45   input           unknown
#     2024-07-07 13:36:46   input_0_function momentary
#     2024-07-07 13:36:46   input_mode      button straight enabled
#     2024-07-07 13:36:45   inttemp         48.3
#     2024-07-07 13:36:45   mac             44:17:93:CF:92:54
#     2024-07-07 13:36:45   model_ID        SNSW-001X16EU
#     2024-07-07 13:36:45   model_family    Plus/Gen2
#     2024-07-07 13:36:45   model_function  switch
#     2024-07-07 13:36:45   model_name      Shelly Plus 1
#     2024-07-07 13:36:46   name            Shelly1Plus_Test
#     2024-07-07 13:36:45   network         <html>connected to <a href="http://192.168.1.131">192.168.1.131</a> (Wifi)</html>
#     2024-07-07 13:36:45   network_rssi    -74
#     2024-07-07 13:36:45   network_ssid    Caldir_MacAran_IoT
#     2024-07-07 13:36:46   network_wifi_roaming -80
#     2024-07-07 13:36:45   relay           off
#     2024-07-07 13:36:45   source          init
#     2024-07-07 13:36:45   state           off
#     2024-07-07 13:36:45   temperature_0   23.2
#     2024-07-07 13:36:45   uptime          29
#     2024-07-07 13:36:46   webhook_cnt     0
#     2024-07-07 13:36:45   webhook_ver     7
#   helper:
#     Sets       config:ap_disable,ap_enable interval password reboot:noArg update:noArg name reset:disconnects,error actions on off toggle on-for-timer off-for-timer input:momentary,toggle,edge,detached,action
#     settings_time 1720352206.45761
#   hmccu:
#
setstate ShellyPlus1_Wetter_TH_TEST off
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 addon sensor
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 ap ShellyPlus1-441793CF9254 enabled open
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 ap_clients disabled
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 ble enabled
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 cloud disabled
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 firmware v1.3.3
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 input unknown
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 input_0_function momentary
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 input_mode button straight enabled
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 inttemp 48.3
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 mac 44:17:93:CF:92:54
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 model_ID SNSW-001X16EU
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 model_family Plus/Gen2
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 model_function switch
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 model_name Shelly Plus 1
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 name Shelly1Plus_Test
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 network <html>connected to <a href="http://192.168.1.131">192.168.1.131</a> (Wifi)</html>
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 network_rssi -74
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 network_ssid Caldir_MacAran_IoT
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 network_wifi_roaming -80
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 relay off
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 source init
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 state off
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 temperature_0 23.2
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 uptime 29
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:46 webhook_cnt 0
setstate ShellyPlus1_Wetter_TH_TEST 2024-07-07 13:36:45 webhook_ver 7

Selbstverständlich habe ich nach dem einkopieren der 36_Shelly-Beta auch fhem einmal neu gestartet...

[Starkstrombastler]

ShellyPus1 und Addon zu testen, da ich nur eine Temperatur, aber keine Luftfeuchte bekomme

dann poste doch bitte mal das Ergebnis von  http://<ip-adresse>/rpc/Shelly.GetStatus

[caldir65]

Moin, bitte sehr:

Code Auswählen Erweitern

{"ble":{},"cloud":{"connected":false},"humidity:100":{"id": 100,"rh":45.2},"input:0":{"id":0,"state":null},"mqtt":{"connected":false},"switch:0":{"id":0, "source":"init", "output":false,"temperature":{"tC":62.2, "tF":144.0}},"sys":{"mac":"441793CF9254","restart_required":false,"time":"14:18","unixtime":1720441096,"uptime":88922,"ram_size":247068,"ram_free":145148,"fs_size":458752,"fs_free":135168,"cfg_rev":27,"kvs_rev":0,"schedule_rev":0,"webhook_rev":7,"available_updates":{"beta":{"version":"1.4.0-beta1"}},"reset_reason":3},"temperature:100":{"id": 100,"tC":22.8, "tF":73.0},"wifi":{"sta_ip":"192.168.1.131","status":"got ip","ssid":"Caldir_MacAran_IoT","rssi":-70},"ws":{"connected":false}}

Gruß
Christoph

[Prof. Dr. Peter Henning]

Damit ist doch klar, dass die Kiste auch keine Feuchte liefert.
Klar, "humidity" habe ich überlesen...

LG

pah

[Starkstrombastler]

Damit ist doch klar, dass die Kiste auch keine Feuchte liefert.

Das Addon liefert Werte entsprechend der angeschlossenen Sensoren. Mit einem DHT22 eben auch Feuchtigkeit, so wie man hier sieht:

"humidity:100":{"id": 100,"rh":45.2}

[Starkstrombastler]

Mit der angekündigten  Testversion 6.00 Beta-3  werden zusätzlich zur Beta-2 folgende Ergänzungen und Änderungen realisiert:
 

• Shelly Plus Addon: humidity, input und voltmeter wurden ergänzt
• Sofern vom Shelly eine Verbindung zu einem anderen Shelly besteht (via range extender) wird ein Reading 'ap_clients_<nr>_model' mit der Modellbezeichnung des verbunden Shelly angelegt
• die Definition des Shelly-Devices kann jetzt auch mit einem DNS-Namen erfolgen (statt der IPv4-Adresse) Beispiele in der Commandref.
      Die IP-Adresse des Shelly wird im neuen Reading 'network_ip-address' abgelegt.
      Bei den PRO-Devices getrennte Readings für LAN und Wifi
• Shelly4pro (Gen1): Reading 'timer_<ch> werden unterstützt. Die verbleibenden Zeiten werden dabei interpoliert, weil sie von diesem Shelly nicht ausgegeben werden (fw 1.6.6)
• Shelly Plus Uni: Name des Reading für analog input wurde geändert
• Der Befehl 'set ... reset ...' wurde geändert auf 'set ... clear ...'. Damit lassen sich die Zähler für Disconnects, kumulierte Energie oder auch das Reading 'error' zurücksetzen
• Dimmbare Devices: der Befehl 'set ... pct 0 [channel]' ist erlaubt, es wird der Kanal ausgeschaltet
• weitere Korrekturen, die hier und da aufpoppen....

Ich bitte um Rückmeldungen, insbesondere auch dann wenn es keine Komplikationen gibt, denn das ist der angestrebte Zustand!

Du darfst diesen Dateianhang nicht ansehen.

[carlos]

Einen Fehler habe ich schon gefunden:
Bei Definition mit IP Adresse bekomme ich bei einem rangeextender die Clients.
Bei Definition mit DNS Name bekomme ich keine Client Namen und kein Client Model.

Gruß

Hubert

[Starkstrombastler]

Bei Definition mit DNS Name bekomme ich keine Client Namen und kein Client Model.

Hallo Hubert, danke fürs Testen.
Wenn der Shelly mit aktivem Range-Extender (RE) in FHEM mit seinem DNS-Namen definiert ist, dann muss auch der Client-Shelly mit dem DNS-Namen des Range-Extender definiert sein, also

Code Auswählen Erweitern

<DNS-Name des RE>:<Port>Der Client wird sich bei DEF mit seiner IPv4-Adresse scheinbar korrekt verhalten, aber nur solange bis sich die IP-Adresse des RE ändert. Und das ist ja der Grund für die Verwendung der DNS-Namen.

Der geschilderte Effekt tritt auch dann auf, wenn der Client des RE garnicht in FHEM definiert ist. Das ist beispielsweise dann der Fall, wenn ein SmartPhone mit dem RE verbunden ist.

[carlos]

Ok, alles klar.
Danke für die Erläuterung.
Ich habe fixe IP Adressen und werde sie dann weiter über die IP Adresse definieren.

Gruß

Hubert

[bjbrill]

Moin,
warscheinlich kein Fehler, aber
bei mir spamt die Shelly 0-10V Dimmer den sytemlog voll, wenn er nachts ausgechatet ist.
Hintergrund: Die 0-10V dimmer können nicht komplett abschalten, deshalb muss man dann den Strom abschalten. dadurch enstehen nachts hunderte Fehlermeldungen:

Code Auswählen Erweitern

2024.07.24 04:00:15 2: (Shelly_HttpResponse:err) Device myShelly0_10v has Error '192.168.178.49: No route to host (113) :: /rpc/Shelly.GetStatus'
2024.07.24 04:01:15 2: (Shelly_HttpResponse:err) Device myShelly0_10v has Error '192.168.178.49: No route to host (113) :: /rpc/Shelly.GetStatus'
2024.07.24 04:02:15 2: (Shelly_HttpResponse:err) Device myShelly0_10v has Error '192.168.178.49: No route to host (113) :: /rpc/Shelly.GetStatus'
2024.07.24 04:03:15 2: (Shelly_HttpResponse:err) Device myShelly0_10v has Error '192.168.178.49: No route to host (113) :: /rpc/Shelly.GetStatus'
2024.07.24 04:04:15 2: (Shelly_HttpResponse:err) Device myShelly0_10v has Error '192.168.178.49: No route to host (113) :: /rpc/Shelly.GetStatus'
2024.07.24 04:05Ich unterbinde das jetzt mit

Code Auswählen Erweitern

ignoreRegexp
.*Shelly_HttpResponse:err.*
da aber alle user des 0-10V dimmers das Problem haben werden, könnte das vielleicht von vornherein unterdrückt werden. Ansonnten sind mir bis jetzt keine Probleme aufgefallen.

lG Björn

[Starkstrombastler]

bei mir spamt die Shelly 0-10V Dimmer den sytemlog voll, wenn er nachts ausgechatet ist.
Hintergrund: Die 0-10V dimmer können nicht komplett abschalten, deshalb muss man dann den Strom abschalten. dadurch enstehen nachts hunderte Fehlermeldungen:

Was ist der Hintergrund, warum schaltest du dem Shelly die Stromversorgung weg? Reicht es nicht, die Steuerspannung für den Ausgang auszuschalten?

Du könntest natürlich das Polling vorher ausschalten, dann laufen auch keine Anfragen mehr ins Nirwana:  set <shelly> interval 0
und zurück mit  set <shelly> interval -1
Oder du setzt den verbose level des Devices auf 1 (oder 0).

Jeder der Probleme mit seinem Netzwerk hat, wird wohl froh sein, wenn ein vorübergehend "verloren" gegangener Shelly sich alsbald wieder meldet. Von daher ist das Beibehalten des Polling schon sinnvoll.
Auch ein Unterdrücken von wiederholten Meldungen hat seine Tücken, weil die ursprüngliche Meldung weit nach hinten rutscht und dann nicht mehr so sichtbar ist.
Aber vielleicht gibt es ja irgendwo brauchbare Vorbilder für eine solche Situation...

[gamauf]

Nach langer Ankündiung kommt hier die Beta-2 Version des Shelly-Moduls zum TESTEN.
...

Bin jetzt aus dem Urlaub zurück und hab die neue Version (danke dafür) eingespielt.
Habe jetzt neu die readings "energy_purchased" und "energy_returned".
Werde jetzt ein par Tage vergehen lassen müssen, bis ausreichend Werte protokolliert wurden.
Danke,
Rainer

[caldir65]

Shelly Plus Addon: humidity, input und voltmeter wurden ergänzt
...
Ich bitte um Rückmeldungen, insbesondere auch dann wenn es keine Komplikationen gibt, denn das ist der angestrebte Zustand!

Moin,

sorry, hab's verschwitzt - humidity ist jetzt da (humidity_0) und hat auch einen plausiblen Wert.
Danke

Gruß
Christoph

[Starkstrombastler]

Die neue Version 6.00 des Shelly Moduls ist ab dem 15.08.24 via regulärem Update verfügbar.

Zusammenfassung der wichtigsten Änderungen/Ergänzungen seit Version 5.21.1:

• Neuorganisation der HTTP-Kommunikation (insbesonder bei Gen2-Devices): nächste Anfrage wird erst bei Abschluss der vorhergehenden Anfrage gestartet, reduzierte Anzahl zyklischer Timer
• Verbesserung des Verhaltens von Dimmern und Leuchten
• Unterstützung DNS-Namen in der Definition, anstatt IP-Adresse
• Unterstützung Effekte bei RGBW2
• Unterstützung 'humidity', 'input', 'voltmweter' bei Shelly Plus Addon
• Unterstützung RangeExtender: Erweiterung Definition für gekoppelte Geräte, gekoppelte Geräte werden in Readings dargestellt; bei Non-FHEM Geräten wird 'no definiton' ausgegeben
• Unterstützung SetExtensions
• Unterstützung Readings 'energy_returned' und 'energy_purchased'  für Plus/Pro-Devices mit Leistungsmessung (PM)
• Unterstützung Reading 'timer' für Shelly4Pro (Gen1)
• Neu: Bei Geräten ohne Internetzugang wird im Reading 'firmware' ein Hinweis auf mögliches Firmware-Update ausgegeben
• Neu: Befehl  'set ... config ap_enable|ap_disable'  zur Kontrolle des Access-Points (nur Gen2)
• Neu: Durch Setzten des Attributs 'timeout' werden Readings mit den Response-Zeiten der HTTP-NonBlocking-Kommunikation angelegt (Max-Wert | letzter Wert); Readings werden mit 'set ... clear responsetimes' zurückgesetzt, durch Löschen des Attributes werden die Readings entfernt (timeout ist dann wieder auf Default-Wert=4sec)
• Neu:  Mit Attribut 'interval_power' wird ein zusätzlicher Timer für den Abruf der Leistungswerte in kurzen Intervallen (min. 1sec) angelegt, nur ShellyPro3EM
• Änderung:  ShellyPlusUni:  Readingname Analog Input
• Änderung:  dimmbare Geräte/Kanäle können mit Befehl 'set ... pct 0' ausgeschaltet werden 
• Änderung:  Wenn interval=0 gesetzt, wird state auf 'disabled' gesetzt
• Änderung:  Reading 'timestamp' entfällt
• Änderung:  Reading 'network_threshold' ist jetzt 'network_wifi_roaming', kann auch den Wert 'disabled' annehmen
• Änderung:  Reading 'errors' ist jetzt 'error_EM', nur ShellyPro3EM
• Änderung:  Internal 'SHELLY' ist jetzt Reading 'model_ID', neue Readings 'model_family', 'model_function', 'model_name'
• Änderung:  Befehl 'set ... reset ...' ist jetzt 'set ... clear ...'
• neue Geräte: ShellyPlus0-10VDimmer, ShellyProDimmer, ShellyPlusUni, Gen3-Devices, u.a.

Falls jemand Notifies oder andere Strukturen auf die geänderten Readings angelegt hat, möge er dies bitte ändern.

Die Befehlsreferenz (deutsche Fassung) ist entsprechend angepasst.

Die in diesem Thread hinterlegten Test-Versionen werden demnächst entfernt, da nicht mehr relevant.

Ich danke allen Testern und wünsche allen Nutzern des Shelly-Moduls viel Erfolg mit der verbesserten Version.

[derdon23]

Hi, vielen Dank für das Modul. Ich hab es schon eine Weile mit unterschiedlichen Shelly devices im Einsatz.

Unter anderem mit einem Pro3EM.
Dieser ist aufgrund des Einbaus im Zählerschrank leider WLAN mäßig grenzwertig unterwegs, funktionierte aber bisher problemlos.

Nach dem letzten Update verbleibt der pro3EM aber im STATE
Error: Network und es werden keine Verbrauchswerte mehr ausgelesen.

Das Gerät ist aber im WLAN problemlos erreichbar und witzigerweise werden auch 3 Werte (inttemp, WLAN rssi und uptime) kontinuierlich aktualisiert.

Kann ich irgendwas unternehmen um das zu beheben?

[VB90]

hat der Pro3 eventuell eine neue/andere IP bekommen?
Ich hatte das anfangs, bin dann dazu übergegangen, allen Shelly feste IP einzutragen.

Probleme mit dem Netzwerk habe ich auch öfter bei einer entfernten Installation.
Dort hilft bislang nur ein (wiederholter) Neustart des Shelly. Bei fest installieren Geräten nicht immer ganz einfach machbar.

vb

[Starkstrombastler]

Nach dem letzten Update verbleibt der pro3EM aber im STATE
Error: Network und es werden keine Verbrauchswerte mehr ausgelesen.

Das Gerät ist aber im WLAN problemlos erreichbar und witzigerweise werden auch 3 Werte (inttemp, WLAN rssi und uptime) kontinuierlich aktualisiert.

Ich habe tatsächlich in meiner Testumgebung den gleichen Effekt, ohne dass ich das bemerkt habe. Ursache ist der letzte Bug-Fix (use Sub::Util), der mit dem morgigen Update auf Modul-Version 6.00.4 zurückgenommen wird. Der ursprüngliche Anlass wird auf andere Weise gelöst.

Die Funktion subname wird also nicht mehr genutzt:

"Undefined subroutine &Sub::Util::subname called at ./FHEM/36_Shelly.pm line 6466."

hat der Pro3 eventuell eine neue/andere IP bekommen?
Ich hatte das anfangs, bin dann dazu übergegangen, allen Shelly feste IP einzutragen.

Statt fester IP können die Shellies auch mit ihrem DNS-Namen definiert werden, siehe CommandRef.

[derdon23]

Super, Dankeschön.
Ich hab das Update installiert und melde mich, falls ich den Fehler nochmals sehen sollte.

[derdon23]

Leider scheint das Problem noch zu bestehen.

Gestern Abend scheint der Pro3EM kurz disconnected gewesen zu sein und das Gerät im FHEM bleibt danach im "STATE Error: Network".

In den Readings stehen als letzte updates z.B.:

Code Auswählen Erweitern

Active_Power_S  402.8  2024-09-10 20:17:26
und der counter für disconnects ging kurz danach um 1 hoch (der stand vorher auf 2):

Code Auswählen Erweitern

network_disconnects  3  2024-09-10 20:18:16
Es werden weiterhin einige wenige Readings aktualisiert:

Code Auswählen Erweitern

inttemp 49.8 2024-09-11 16:12:08
network_rssi -59 2024-09-11 16:12:08
uptime 2738829 2024-09-11 16:12:23
und das Gerät selbst ist im Netzwerk auch problemlos erreichbar.

[Starkstrombastler]

Gestern Abend scheint der Pro3EM kurz disconnected gewesen zu sein und das Gerät im FHEM bleibt danach im "STATE Error: Network".

Ich denke, wir haben hier ein anderes Problem, wenngleich mit ähnlichen Folgen. Auf Grund des Disconnects bleibt der Timer für die Zählerwerte stehen.
Weil beim ShellyPro3EM mehrere Timer laufen, werden einige Readings noch weiter aktualisiert.
Zum Wiederbeleben:  Die Timer werden durch 'set ... interval ..' oder 'attr  ... [interval|interval_power] ...' neu gestartet.

Bezüglich der Ursache dieses Verhaltens bin ich noch am suchen....

[tobi01001]

Bezüglich der Ursache dieses Verhaltens bin ich noch am suchen....

Hi,

Die Ursache dürfte darin liegen, dass die neuen Timer in der Callback gesetzt werden. Wenn durch einen Netzwerkfehler der Non-Blocking Aufruf nicht durchgeht, bzw die Callback nicht aufgerufen wird, wird der Timer nicht neu gestartet.
Als Lösung könntest du den den/die Timer selbst im Aufruf selbst neu setzen (als Backup) und dann in der Callback dediziert löschen (passiert eh schon) und mit dem gewünschten Intervall neu setzen.


Gruß,
Tobi

[Starkstrombastler]

Wenn durch einen Netzwerkfehler der Non-Blocking Aufruf nicht durchgeht, bzw die Callback nicht aufgerufen wird, wird der Timer nicht neu gestartet.

Ja, genau so ist - manchmal braucht man eben einen Anstoss in die richtige Richtung.
Zur Lösung wird der/die Timer im Fall eines Timeouts einfach neu gestartet... 

Eine aktualisierte Version werde ich hier als Beta-Version zur Verfügung stellen.

[det.]

Sorry, war lange nicht hier - und hab eine dumme Frage: was kann ich tun, dass ein Shellyplusi4 das Event Eingang ändert Status von on zu off (oder umgekehrt) sofort meldet und nicht nach gefühlt über 30 s später?

[Starkstrombastler]

Sorry, war lange nicht hier - und hab eine dumme Frage: was kann ich tun, dass ein Shellyplusi4 das Event Eingang ändert Status von on zu off (oder umgekehrt) sofort meldet und nicht nach gefühlt über 30 s später?

Dafür sind die Actions das richtige Instrument. Richte mit Hilfe des Moduls die Actions auf dem Shelly ein:

Code Auswählen Erweitern

attr <name> webhook <hook>
set <name> actions create info
set <name> actions create index
    oder
set <name> actions create all

Mit create all werden die Actions disabled angelegt, du musst dann nach Bedarf aktivieren.

[caldir65]

Moin,

ich habe einen ShellyPlus1 mit Addon. Daran angeschlossen ist ein Reedkontakt. Wenn ich jetzt einen Magnet entsprechend anlege, kann ich in der Oberfläche vom Shelly eine Reaktion sehen, jedoch kommt davon nichts in fhem an.

Ein

Code Auswählen Erweitern

http://192.168.1.147/rpc/Shelly.GetStatusgibt mir als Ergebnis

Code Auswählen Erweitern

ble    {}
cloud   
connected    false
input:0   
id    0
state    false
input:100   
id    100
state    true
mqtt   
connected    false
switch:0   
id    0
source    "init"
output    false
temperature   
tC    54.5
tF    130
sys   
mac    "441793CF9254"
restart_required    false
time    "14:07"
unixtime    1727611636
uptime    685
ram_size    268812
ram_free    128928
fs_size    393216
fs_free    110592
cfg_rev    9
kvs_rev    0
schedule_rev    0
webhook_rev    0
available_updates    {}
reset_reason    3
wifi   
sta_ip    "192.168.1.147"
status    "got ip"
ssid    "Caldir_MacAran_IoT"
rssi    -79
ws   
connected    falsewobei der input:100 der Reed ist, in diesem Fall geschlossen

Hier einmal die aktuelle Definition:

Code Auswählen Erweitern

defmod ShellyPlus1_Schlafzimmer Shelly 192.168.1.147
attr ShellyPlus1_Schlafzimmer DbLogExclude .*
attr ShellyPlus1_Schlafzimmer event-on-change-reading .*
attr ShellyPlus1_Schlafzimmer group Shelly
attr ShellyPlus1_Schlafzimmer model shellyplus1
attr ShellyPlus1_Schlafzimmer room Arbeitszimmer,Schlafzimmer

setstate ShellyPlus1_Schlafzimmer off
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 addon sensor
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 ap ShellyPlus1-441793CF9254 disabled open
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 ap_clients disabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 ble enabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 cloud disabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:58:29 firmware v1.4.2(check internet for firmware v1.3.3)
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 input off
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 input_0_function follow
setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:07:34 input_1 on
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 input_1_mode switch straight enabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 input_mode switch straight enabled
setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:09:34 inttemp 54.5
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 mac 44:17:93:CF:92:54
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 model_ID SNSW-001X16EU
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 model_family Plus/Gen2
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 model_function switch
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:28 model_name Shelly Plus 1
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 name ShellyPlus1_Schlafzimmer
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 network <html>connected to <a href="http://192.168.1.147">192.168.1.147</a> (Wifi)</html>
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 network_ip-address 192.168.1.147
setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:08:34 network_rssi -73
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 network_ssid Caldir_MacAran_IoT
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 network_wifi_roaming -80
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 relay off
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 source init
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 state off
setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:09:34 uptime 824
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 webhook_cnt 0
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:29 webhook_ver 0
Könnte das evtl. auch entsprechend mit eingebaut werden?

Danke und Gruß
Christoph

[Starkstrombastler]

ich habe einen ShellyPlus1 mit Addon. Daran angeschlossen ist ein Reedkontakt. Wenn ich jetzt einen Magnet entsprechend anlege, kann ich in der Oberfläche vom Shelly eine Reaktion sehen, jedoch kommt davon nichts in fhem an.

Das Addon ist ja bereits integriert, aber offensichtlich passt da noch nicht alles. Schaue ich mir an, damit auch das funktioniert.

[caldir65]

Moin,

das hört sich gut an. Übrigens kommt ein am analogen Eingang des Addon wie folgt:

Code Auswählen Erweitern


ble {}
cloud
connected false
input:0
id 0
state false
input:100
id 100
percent 0
mqtt
connected false
switch:0
id 0
source "init"
output false
temperature
tC 65.3
tF 149.6
sys
mac "441793A58A54"
restart_required false
time "20:19"
unixtime 1727720370
uptime 99158
ram_size 253952
ram_free 140680
fs_size 393216
fs_free 110592
cfg_rev 6
kvs_rev 0
schedule_rev 0
webhook_rev 0
available_updates {}
reset_reason 3
wifi
sta_ip "192.168.1.164"
status "got ip"
ssid "Caldir_MacAran_IoT"
rssi -57
ws
connected false
Da variiert dann nur die Ausgabe der "percent" (0 = keine Bewegung)

Gruß
Christoph

[Starkstrombastler]

Ich habe einen ShellyPlus1 mit Addon. Daran angeschlossen ist ein Reedkontakt. Wenn ich jetzt einen Magnet entsprechend anlege, kann ich in der Oberfläche vom Shelly eine Reaktion sehen, jedoch kommt davon nichts in fhem an.

setstate ShellyPlus1_Schlafzimmer 2024-09-29 14:07:34 input_1 on
setstate ShellyPlus1_Schlafzimmer 2024-09-29 13:57:30 input_1_mode switch straight enabled

Das Shelly-Modul scheint aber korrekt zu arbeiten, das Reading input_1 wird mit Wert on dargestellt.
Es gilt dabei zu beachten, dass die Readings entsprechend dem Polling-Intervall gesetzt werden.

Sollen kurzzeitige Änderungen am Eingang erfasst werden, so sollte auf dem Shelly eine entsprechende Action angelegt werden.
Die URL für die Action "Input toggled on" sollte so aussehen (die Leerzeichen sind durch %20 zu ersetzen):

Code Auswählen Erweitern

http://192.168.1.147:8083/fhem?cmd=set Y174 input_on 1

Zu beachten ist, dass auf dem Shelly die Inputs des AddOn von 100 an aufwärts gezählt werden, im Fhem-Modul dagegen wird die Zählung nach den regulären Inputs fortgesetzt. Für den Shelly Plus 1 gilt also:
input:0     -->  input  bzw.  input_0   *)
input:100   -->  input_1
*) Das Modul wird noch korrigiert, mit dem Addon muss das Reading des 'regulären' Eingangs input_0 heißen.