[Gelöst] MQTT2 Shelly - Befehle gehen nicht an Shelly

Christian_M · 26 Juni 2021, 22:46:22

Hallo zusammen,

ich betreibe mehrere Shelly 2.5 zur Bewässerungssteuerung.
Angebunden habe ich diese via MQTT.
Die meisten konnte ich recht einfach anbinden, aber einer macht mir Ärger den ich nicht verstehe.

Fehlerbeschreibung: Wenn ich den Shelly direkt schaltet sehe ich das auch augenblicklich in FHEM.
Wenn ich in FHEM schalte, wird mir zwar in FHEM ein neuer Status angezeigt, aber nur so lange, bis der Shelly seinen Status melden.
Ich habe das Template für Shelly25_Split genutzt, habe aber nur Fehler beim Schaltversuch bekommen und darum die Attribute von einem funktionierenden Device übernommen. Danach hab ich zumindest den Status gesehen.

readingList

Code Auswählen

shellies/shellyswitch25-68C63AF92588/relay/0:.* state
  shellies/shellyswitch25-68C63AF92588/relay/0:.* relay_0
  shellies/shellyswitch25-68C63AF92588/input/0:.* input_0
  shellies/shellyswitch25-68C63AF92588/online:.* online
  shellies/shellyswitch25-68C63AF92588/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-68C63AF92588...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shellyswitch25-68C63AF92588/relay/0/power:.* relay_0_power
  shellies/shellyswitch25-68C63AF92588/relay/0/energy:.* {'relay_0_energy' => sprintf("%.2f",$EVENT/60/1000)}
  shellies/shellyswitch25-68C63AF92588/temperature:.* temperature
  shellies/shellyswitch25-68C63AF92588/overtemperature:.* overtemperature
  shellies/shellyswitch25-68C63AF92588/longpush/0:.* longpush_0
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/input_event/0:.* { json2nameValue($EVENT) }
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/input_event/1:.* { json2nameValue($EVENT) }
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/temperature_f:.* temperature_f

getList:

Code Auswählen

power:noArg shellies/shellyswitch25-68C63AF92588/relay/power power

setList:

Code Auswählen

off:noArg shellies/shellyswitch25-68C63AF92588/relay/0/command off
  on:noArg shellies/shellyswitch25-68C63AF92588/relay/0/command on
  x_update:noArg shellies/shellyswitch25-68C63AF92588/command update_fw
  x_mqttcom shellies/shellyswitch25-68C63AF92588/command $EVTPART1

Für alle Ideen wäre ich dankbar.

supernova1963 · 27 Juni 2021, 05:48:40

Hallo Christian_M,

da nach Deiner Aussage die Anzeige der Veränderungen funktioniert, müßte readingList soweit passen.
Darauf basierend finde ich auch keine Fehler im setList.
Meine Vermutung ist, dass irgendetwas im defStateIcon oder webCmd Attribut nicht passen könnte.

Probiere doch einmal die Eingaben in fhem commandline:

Code Auswählen

set <fhem-device-Name> [on|off]
Oder poste die vollständige Ausgabe von:

Code Auswählen

list <fhem-device-Name>
(Ebenfalls als Eingabe in der fhem commandline)

lg

Gernot

Christian_M · 27 Juni 2021, 09:50:28

Hi Gernot,

der Set Befehl über die Commandline hat das gleiche Verhalten erzeugt wie bereits beschrieben.

Hier die Ausgabe von dem List:

Code Auswählen

 Internals:
   CFGFN      
   CID        shellyswitch25_68C63AF92588
   DEF        shellyswitch25_68C63AF92588
   DEVICETOPIC Bewaesserung_Weide_V02_01_01
   FUUID      60bbd8c1-f33f-5936-3205-adc04e0fc508f430
   IODev      mqttBroker
   LASTInputDev mqttBroker
   MSGCNT     548671
   NAME       Bewaesserung_Weide_V02_01_01
   NR         4027
   STATE      aus
   TYPE       MQTT2_DEVICE
   mqttBroker_MSGCNT 548671
   mqttBroker_TIME 2021-06-27 09:45:27
   OLDREADINGS:
   READINGS:
     2021-06-05 23:00:03   associatedWith  Bewaesserung_Weide_V02_01_01_CH2
     2021-06-05 23:00:03   attrTemplateVersion 20210126
     2021-06-26 18:55:30   event           S
     2021-06-26 18:55:30   event_cnt       22
     2021-06-27 09:45:27   input_0         0
     2021-06-26 22:15:52   input_1         0
     2021-06-26 18:55:30   longpush_0      0
     2021-06-26 17:30:55   online          false
     2021-06-27 09:45:27   overtemperature 0
     2021-06-27 09:45:27   relay_0         off
     2021-06-27 09:45:27   relay_0_energy  0.11
     2021-06-26 22:29:42   relay_0_energy_total 6624
     2021-06-27 09:45:27   relay_0_power   0.00
     2021-06-26 22:15:52   relay_1         off
     2021-06-26 22:15:52   relay_1_energy  0
     2021-06-26 22:15:52   relay_1_power   0.00
     2021-06-27 09:45:26   state           off
     2021-06-27 09:45:27   temperature     61.50
     2021-06-27 09:45:27   temperature_f   142.70
     2021-06-26 22:15:52   temperature_status Normal
     2021-06-05 23:00:03   x_mqttcom       set announce
Attributes:
   IODev      mqttBroker
   alias      Mulchrand
   autocreate 1
   comment    Channel 1 for Bewaesserung_Weide_V02_01_01, see also Bewaesserung_Weide_V02_01_01_CH2
   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" ; my $light = ReadingsVal($name,"state","off") eq "off"?"sani_water_tap" : ReadingsVal($name,"state","off") eq "on" ? 'humidity@blue' : 'sani_water_tap'; my $cons = ReadingsVal($name,"relay_0_power","unknown"); my $total = ReadingsVal($name,"relay_0_kWh","unknown"); my $temp = ReadingsVal($name,"temperature","-100"); "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch: $cons</div>"}
   eventMap   on:an off:aus
   getList    power:noArg shellies/shellyswitch25-68C63AF92588/relay/power power
   group      Bewässerung
   model      shelly25_split
   readingList shellies/shellyswitch25-68C63AF92588/relay/0:.* state
  shellies/shellyswitch25-68C63AF92588/relay/0:.* relay_0
  shellies/shellyswitch25-68C63AF92588/input/0:.* input_0
  shellies/shellyswitch25-68C63AF92588/online:.* online
  shellies/shellyswitch25-68C63AF92588/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-68C63AF92588...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shellyswitch25-68C63AF92588/relay/0/power:.* relay_0_power
  shellies/shellyswitch25-68C63AF92588/relay/0/energy:.* {'relay_0_energy' => sprintf("%.2f",$EVENT/60/1000)}
  shellies/shellyswitch25-68C63AF92588/temperature:.* temperature
  shellies/shellyswitch25-68C63AF92588/overtemperature:.* overtemperature
  shellies/shellyswitch25-68C63AF92588/longpush/0:.* longpush_0
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/input_event/0:.* { json2nameValue($EVENT) }
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/input_event/1:.* { json2nameValue($EVENT) }
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/temperature_f:.* temperature_f
   room       Außen->Weide,Dashboard
   setList    off:noArg shellies/shellyswitch25-68C63AF92588/relay/0/command off
  on:noArg shellies/shellyswitch25-68C63AF92588/relay/0/command on
  x_update:noArg shellies/shellyswitch25-68C63AF92588/command update_fw
  x_mqttcom shellies/shellyswitch25-68C63AF92588/command $EVTPART1
   webCmd     an:aus

Viele Grüße
Christian

Beta-User · 27 Juni 2021, 11:44:30

Im attrTemplate steht nichts von "an" und "aus"....

Vermutlich wirst du das durch eine etwas komplexere Fassung von eventMap lösen müssen, wenn es unbedingt deutsche Texte sein müssen

. (es gibt - soweit ich mich entsine - die option, nur für FHEMWEB ein mapping anzulegen, ich weiß nur nicht, welchen key man dafür wählen musste; in die Richtung, aber eben nicht "usr":
{ usr => { "an" => "on", ...

Christian_M · 27 Juni 2021, 12:06:13

Hallo Beta-User,

danke für deine Antwort.
Das WebCmd in Verbindung mit dem EventMap hat in EventMap hat bei anderen Devices ganz gut funktioniert. In der SetList wird ja auch weiterhin on und off genutzt.

Wenn das der Fehler ist verstehe ich nicht warum das bei anderen Devices klappt.
Ich werde aber mal zum Test rausnehmen.

EDIT: Getestet: Die Übersetzung habe ich rausgenommen, die hatte nichts damit zu tun.

VG
Christian

supernova1963 · 27 Juni 2021, 16:47:38

Lösche ggf. 'mal die defStateIcon Einstellungen, damit sicher gestellt ist, dass da nicht an oder aus bei herauskommt.

Nutzt du MQTT2_SERVER?
Wenn ja, dann versuche doch 'mal die direkten publish Befehle:

Code Auswählen

set mqttBroker publish shellies/shellyswitch25-68C63AF92588/relay/0/command on
set mqttBroker publish shellies/shellyswitch25-68C63AF92588/relay/0/command off

Wenn nein, dann die entsprechenden publish Befehl des Broker devices.

Wenn das funktioniert, liegt's definitiv an den MQTT2_DEVICE Einstellungen.
Ich würde dann ein neues MQTT2_DEVICE ganz ohne templates Schritt für Schritt aufbauen.

Beta-User · 27 Juni 2021, 16:56:15

Ergänzend:

Zitat von: Christian_M am 26 Juni 2021, 22:46:22
Wenn ich in FHEM schalte, wird mir zwar in FHEM ein neuer Status angezeigt, aber nur so lange, bis der Shelly seinen Status melden.

Kannst du mal ein (raw-) list machen, nachdem du in FHEM "vermeintlich" geschaltet hattest und evtl. auch setStateList mit "on off" ergänzen?

Da sollte dann(z.B.) "set_on" in state stehen, bis der Befehl am Shelly angekommen ist - dauert das zu lange, hast du möglicherweise ein (WLAN-) Verbindungsproblem.

Christian_M · 27 Juni 2021, 21:16:10

Hallo nochmal:
@Supernova1963:
Das löschen von devStateIcon hatte leider keinen Effekt auf das verhalten.
Ich benutze auch mqtt2_Server, der publish Befehl hat aber leider keinen Effekt auf dem Shelly.

@Beta-User:
Ich habe setStateList mit on off ergänzt und erhalte folgende Ausgabe bei list -r nach dem schalten:

Code Auswählen

define Bewaesserung_Weide_V02_01_01 MQTT2_DEVICE shellyswitch25_68C63AF92588
attr Bewaesserung_Weide_V02_01_01 IODev mqttBroker
attr Bewaesserung_Weide_V02_01_01 alias Mulchrand
attr Bewaesserung_Weide_V02_01_01 autocreate 1
attr Bewaesserung_Weide_V02_01_01 comment Channel 1 for Bewaesserung_Weide_V02_01_01, see also Bewaesserung_Weide_V02_01_01_CH2
attr Bewaesserung_Weide_V02_01_01 getList power:noArg shellies/shellyswitch25-68C63AF92588/relay/power power
attr Bewaesserung_Weide_V02_01_01 group Bewässerung
attr Bewaesserung_Weide_V02_01_01 model shelly25_split
attr Bewaesserung_Weide_V02_01_01 readingList shellies/shellyswitch25-68C63AF92588/relay/0:.* state\
  shellies/shellyswitch25-68C63AF92588/relay/0:.* relay_0\
  shellies/shellyswitch25-68C63AF92588/input/0:.* input_0\
  shellies/shellyswitch25-68C63AF92588/online:.* online\
  shellies/shellyswitch25-68C63AF92588/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-68C63AF92588...mac.*, ? json2nameValue($EVENT) : undef }\
  shellies/shellyswitch25-68C63AF92588/relay/0/power:.* relay_0_power\
  shellies/shellyswitch25-68C63AF92588/relay/0/energy:.* {'relay_0_energy' => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/shellyswitch25-68C63AF92588/temperature:.* temperature\
  shellies/shellyswitch25-68C63AF92588/overtemperature:.* overtemperature\
  shellies/shellyswitch25-68C63AF92588/longpush/0:.* longpush_0\
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/input_event/0:.* { json2nameValue($EVENT) }\
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/input_event/1:.* { json2nameValue($EVENT) }\
shellyswitch25_68C63AF92588:shellies/shellyswitch25-68C63AF92588/temperature_f:.* temperature_f
attr Bewaesserung_Weide_V02_01_01 room Außen->Weide,Dashboard
attr Bewaesserung_Weide_V02_01_01 setList off:noArg shellies/shellyswitch25-68C63AF92588/relay/0/command off\
  on:noArg shellies/shellyswitch25-68C63AF92588/relay/0/command on\
  x_update:noArg shellies/shellyswitch25-68C63AF92588/command update_fw\
  x_mqttcom shellies/shellyswitch25-68C63AF92588/command $EVTPART1
attr Bewaesserung_Weide_V02_01_01 setStateList on off

setstate Bewaesserung_Weide_V02_01_01 set_on
setstate Bewaesserung_Weide_V02_01_01 2021-06-05 23:00:03 associatedWith Bewaesserung_Weide_V02_01_01_CH2
setstate Bewaesserung_Weide_V02_01_01 2021-06-05 23:00:03 attrTemplateVersion 20210126
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 20:44:18 event S
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 20:44:18 event_cnt 23
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 21:11:05 input_0 0
setstate Bewaesserung_Weide_V02_01_01 2021-06-26 22:15:52 input_1 0
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 20:44:18 longpush_0 0
setstate Bewaesserung_Weide_V02_01_01 2021-06-26 17:30:55 online false
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 21:11:05 overtemperature 0
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 21:11:05 relay_0 off
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 21:11:05 relay_0_energy 0.11
setstate Bewaesserung_Weide_V02_01_01 2021-06-26 22:29:42 relay_0_energy_total 6624
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 21:11:05 relay_0_power 0.00
setstate Bewaesserung_Weide_V02_01_01 2021-06-26 22:15:52 relay_1 off
setstate Bewaesserung_Weide_V02_01_01 2021-06-26 22:15:52 relay_1_energy 0
setstate Bewaesserung_Weide_V02_01_01 2021-06-26 22:15:52 relay_1_power 0.00
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 21:11:07 state set_on
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 21:11:05 temperature 62.54
setstate Bewaesserung_Weide_V02_01_01 2021-06-27 21:11:05 temperature_f 144.58
setstate Bewaesserung_Weide_V02_01_01 2021-06-26 22:15:52 temperature_status Normal
setstate Bewaesserung_Weide_V02_01_01 2021-06-05 23:00:03 x_mqttcom set announce

Tatsächlich steht set_on im state. Wenn das jedoch für ein permanentes W-Lan Probem steht, verstehe ich nicht warum ich zeitgleich auf das Web Interface des Shelly komme und auch die Ereignisse des Shelly erhalte. Das scheint mir nicht logisch.

supernova1963 · 28 Juni 2021, 06:40:44

Zitat von: Christian_M am 27 Juni 2021, 21:16:10
Ich benutze auch mqtt2_Server, der publish Befehl hat aber leider keinen Effekt auf dem Shelly.

Wenn wir alles richtig gemacht haben, liegt es aller Wahrscheinlichkeit nach nicht an der Definition des MQTT2_DEVICE und die Vermutung von @BetaUser, dass ggf. ein WLAN Problem vorliegen könnte "nimmt Gestalt an".
Hast du einen MQTT Client, wie z.B. MQTT Explorer im Einsatz?
Damit überprüfe ich, was unmittelbar am MQTT Broker passiert. Das hilft mir oft bei der Fehlersuche.
(Ja, ich weiß, es geht auch über "verbose" und die logs in fhem).

"set_on" ist keine Fehlermeldung, sondern ein Status, der dokumentiert, dass der Befehl übermittelt wurde. Normalerweise, wenn alles funktioniert hat, erfolgt kurzfristig die Antwort des Gerätes mit dem tatsächlichen Status, also im Idealfall "on".

Nächste Schritte bei der Vermutung eines WLAN Problems:
Was steht in den Log Dateien des Shelly, wenn du in den Settings unter Device Info "Enable Debug Log" aktiviert hast?
Sind dort "Probleme" zu erkennen:
Welche WLAN Router / Access Points mit welchen Firmware Stand verwendest du?
Welche Firmware hat der Shelly?
...

Beta-User · 28 Juni 2021, 07:51:56

Zitat von: Christian_M am 27 Juni 2021, 21:16:10
Tatsächlich steht set_on im state. Wenn das jedoch für ein permanentes W-Lan Probem steht, verstehe ich nicht warum ich zeitgleich auf das Web Interface des Shelly komme und auch die Ereignisse des Shelly erhalte. Das scheint mir nicht logisch.

An ein "permanentes" Problem glaube ich auch nicht unbedingt, es genügt aber eben auch, wenn die Verbindung im Moment des Sendens nicht 100% stabil ist:
Der MQTT2_SERVER publisht genau in dem Moment, in dem der Schaltbefehl kommt. Hört da die Gegenstelle grade nicht zu (AP-Wechsel, ...), ist die Info eben verloren und es kommt keine Antwort zurück. ("set_on" ist aber "nur" die Info, dass der Code auf MQTT2_DEVICE-Ebene "fehlerfrei" abgearbeitet wurde (Konfigurationsfehler, z.B. falsche Topics usw.) werden aber nicht erkannt!) und eben bisher keine Antwort/neue Info zurückkam).

Bei Verbindung mit dem Web-IF des Shelly dürfte jeweils eine Info kommen, ob ausstehende Daten da sind usw. und Schwächen der Verbindung dann eben durch entsprechendes Nachladen kompensiert werden. Schade, dass man bei den Shelly relativ wenig Daten zum WLAN-Status bekommt (z.B. RSSI-Werte).

Es sieht mir jedenfalls danach aus, als würde seitens FHEM erst mal alles korrekt erfolgen und der passende MQTT-Befehl an den erwarteten Topic gehen. Evtl. kannst du auch nochmal die "subscriptions" gegenchecken:

Code Auswählen

list MQTT2_.* subscriptions
Wenn es da keine (überraschende) Diskrepanzen zwischen den setList-Topics und den dortigen Angaben gibt, solltest du den Shelly mal näher an einen "guten" AP (keine Fritzbox!) bringen und checken, ob das "set_on" dann schneller verschwindet...

supernova1963 · 28 Juni 2021, 10:34:44

### OFF TOPIC ###

Zitat von: Beta-User am 28 Juni 2021, 07:51:56
...Schade, dass man bei den Shelly relativ wenig Daten zum WLAN-Status bekommt (z.B. RSSI-Werte).

Hallo @BetaUser,

ist der Wert im json des topics shellies/<shellymodel>-<deviceid>/info nicht der rssi Wert, den du vermisst:

Zitat von: shelly-api-docshttps://shelly-api-docs.shelly.cloud/#availability-and-announces
...
announce will trigger:
an announce packet by every Shelly connected to the broker on shellies/announce and, since v1.6.0, on shellies/<shellymodel>-<deviceid>/announce;
since v1.8.0, shellies/<shellymodel>-<deviceid>/info with the content of the http /status endpoint.
...

Mit dem announce command wird neben dem topic shellies/<shellymodel>-<deviceid>/announce und der Ausgabe

Code Auswählen

{"id":"ShellyMQTT-ID","model":"SHSW-25","mac":"123456789012","ip":"192.168.1.123","new_fw":false,"fw_ver":"20210429-100559/v1.10.4-g3f94cd7"}

auch /status bzw. MQTT topic: /shellies/<shellymodel>-<deviceid>/info ausgegeben (u.a. auch "wifi_sta": "rssi"):

Code Auswählen

{"wifi_sta":{"connected":true,"ssid":"RAUNETWLANIOT","ip":"10.100.1.60","rssi":-61},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"09:26","unixtime":1624865191,"serial":1,"has_update":false,"mac":"123456789012","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,"overtemperature":false,"is_valid":true,"source":"http"},{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"mqtt"}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1624872391,"counters":[0.000, 20.772, 0.000],"total":20},{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1624872391,"counters":[0.000, 39.231, 0.000],"total":39}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":1,"event":"","event_cnt":0}],"temperature":55.11,"overtemperature":false,"tmp":{"tC":55.11,"tF":131.19, "is_valid":true},"temperature_status":"Normal","update":{"status":"idle","has_update":false,"new_version":"20210429-100559/v1.10.4-g3f94cd7","old_version":"20210429-100559/v1.10.4-g3f94cd7"},"ram_total":49272,"ram_free":34752,"fs_size":233681,"fs_free":142066,"voltage":240.47,"ping_check":true,"uptime":183}

Beta-User · 28 Juni 2021, 11:35:27

Zitat von: supernova1963 am 28 Juni 2021, 10:34:44
ist der Wert im json des topics shellies/<shellymodel>-<deviceid>/info nicht der rssi Wert, den du vermisst:

Sorry, hatte nur bei dem einen Shelly, den ich im Einsatz habe kurz nachgesehen, ob ich da was finde...
Dass diese Werte ggf. auch über das Web-IF verfügbar sind, hatte ich eigentlich fast vermutet. Allerdings hilft auch das nur bedingt weiter, wenn nicht klar ist, warum die Verbindung - im Ergebnis - so wackelig ist, dass praktisch kein MQTT-Kommando ankommt. (ständiger Kanalwechsel? Überforderter AP? ...)
Ohne näheres über das technische Umfeld und tiefere Analysen wird man da kaum weiterkommen, mir ging es nur darum klarzustellen, dass es nur bedingt weiterhilft, dass es auf anderem Weg _scheinbar_ stressfrei läuft...

supernova1963 · 28 Juni 2021, 12:12:55

Zitat von: Beta-User am 28 Juni 2021, 11:35:27
... Allerdings hilft auch das nur bedingt weiter, wenn nicht klar ist, warum die Verbindung - im Ergebnis - so wackelig ist, dass praktisch kein MQTT-Kommando ankommt. (ständiger Kanalwechsel? Überforderter AP? ...)

Dein Vorschlag eine funktionierende stabile WLAN-Verbindung sicherzustellen, sollte der nächste Schritt für @Christian_M sein.

Christian_M · 28 Juni 2021, 21:06:24

Hello again,

also erst einmal Respekt und Danke an euch für die ausführliche Widmung mit der Ihr hier Wissensaufbau betreibt. *Hutzieh*. Nun wieder zur Sache.

Die W-Lan Verbindung habe ich wie folgt gecheckt:

Längeren Ping laufen lassen:
von 308 Paketen sind 308 Empfangen worden. Mittelwert Antwortzeit 17 ms.
RSSI auf dem Shelly gecheckt: -31 dBm
Über MQTT Explorer die gesendeten Nachrichten vom Shelly beobachtet. Die kommen in regelmäßigen Abständen rein. (@Supernova: Cooles Tool übrigens, danke für den Tipp)

Zum Shelly Log:
Das finde ich nicht sehr hilfreich. nach Aktivierung und mehreren versuchten Schaltungen über FHEM und mehreren erfolgreichen Schaltungen über das Shelly Webfrontend enthält das Log nur die Info, über welche IP ich auf das Web Interface Zugegriffen habe und die Info über einen Update Check den ich gestartet habe (Doppelte Einträge habe ich mal rausgenommen=.

Code Auswählen

1986744758837 json.c:420              RAM: 49272 total, 33648 free
1986749845697 mgos_http_server.c:180  0x3fff276c HTTP connection from 192.168.2.115:53044
1986795563633 shelly_sntp.c:433       minute tick at 20:32:00
1987024570355 shelly_update.c:306     cancel scheduled ota check
1987024575298 shelly_update.c:231     OTA check url http://api.shelly.cloud/files/firmware?type=SHSW-25&device=shellyswitch25-68C63AF92588&fw=20210429-100559%2fv1.10.4-g3f94cd7
1987024710272 mgos_http_server.c:180  0x3fff276c HTTP connection from 192.168.2.115:55315
1987024886736 shelly_update.c:345     no new firmware available...
1987024891255 shelly_update.c:314     fwinfo check in 86400 seconds

Der Shelly ist auf dem aktuellen Stand : 20210429-100559/v1.10.4-g3f94cd7
Als AP dient ein Devolo Dlan Adapter (Soll mittelfristig ausgetauscht werden, ist aber vorerst die einzige Chance W-Lan auf die Weide zu bekommen.

Code Auswählen


mqttBroker_192.168.2.79_2676     shellies/command=1624721457.54428 shellies/shellyswitch25-68C63AF92588_test/command=1624721457.54488 shellies/shellyswitch25-68C63AF92588_test/relay/0/command=1624721457.54573 shellies/shellyswitch25-68C63AF92588_test/relay/1/command=1624721457.54551 shellies/shellyswitch25-68C63AF92588_test/roller/0/command=1624721457.54531 shellies/shellyswitch25-68C63AF92588_test/roller/0/command/pos=1624721457.5451

Der Name "shellyswitch25-68C63AF92588_test" macht mich stutzig. Ich vermute das hat ist entstanden, als ich mit dem MQTT custom Prefix experimentiert habe.
Ich habe jetzt zum Test auf dem Shelly den Custom prefix noch einmal auf "shellyswitch25-68C63AF92588_test" gestellt, das ändert aber nichts.

Ich bin am überlegen, ob ich den MQTT2 Server einmal lösche und neu initialisiere.

Edit: hab den Server einmal gelöscht und neu aufgesetzt, hat aber nix geändert.

supernova1963 · 29 Juni 2021, 05:45:21

OK @Chritian_M,

ich gehe vom hier "geposteten" list device aus, das zeigt nichts von ..._test !
Das "prefix" muss selbstverständlich auf shelly und fhem übereinstimmen.

Wenn ich es korrekt zusammenfasse, haben wir ein fhem MQTT2_DEVICE für einen Shelly 2.5, der mit dem MQTT2_BROKER kommuniziert (subscriptions der readingList) aber keine Schaltbefehle annimmt (publish in der setList).
Wir gehen davon aus, dass es nicht an der WLAN Verbindung liegt.
Die in readingList definierten subscriptions funktionieren (autocreate scheint zu funktionieren)
Die setList commands des fhem MQTT2_DEVICE sehen korrekt aus.
Der Shelly 2.5 ist als DEVICE TYPE = Relay definiert.
MQTT ist am Shelly aktiviert.
Das webInterface des Shelly funktioniert.

Was wir bisher nicht hinbekommen haben, ist, dass der Shelly einen on oder off Befehl über MQTT publish ausführt.

Erzeugt der fhem Befehl

Code Auswählen

set Bewaesserung_Weide_V02_01_0 x_mqttcom announce im MQTT Explorer aktualisierte Einträge?
Hast du auch einmal versucht den setList Befehl für on oder off im MQTT Explorer über publish auszuführen?

Oder, alles auf Anfang fhem device löschen, Shelly reset, ....