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
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:
power:noArg shellies/shellyswitch25-68C63AF92588/relay/power power
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
Für alle Ideen wäre ich dankbar.
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:
set <fhem-device-Name> [on|off]
Oder poste die vollständige Ausgabe von:
list <fhem-device-Name>
(Ebenfalls als Eingabe in der fhem commandline)
lg
Gernot
Hi Gernot,
der Set Befehl über die Commandline hat das gleiche Verhalten erzeugt wie bereits beschrieben.
Hier die Ausgabe von dem List:
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
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", ...
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
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:
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.
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.
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:
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.
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 (http://mqtt-explorer.com/) 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?
...
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:
list MQTT2_.* subscriptionsWenn 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...
### 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
{"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"):
{"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}
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...
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.
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=.
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
Zur Infrastruktur:
- 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.
Was jetzt aber verdächtig scheint:
list mqtt.* subscriptions ergab folgende Ausgabe:
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.5451Der 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.
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 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, ....
Zitat von: Christian_M am 28 Juni 2021, 21:06:24
Edit: hab den Server einmal gelöscht und neu aufgesetzt, hat aber nix geändert.
Die subscriptions werden vom jeweiligen Client übermittelt, und das sollte sich ggf. auch ändern, wenn es von dieser Seite aktualisiert wird. Vermutlich steht eben auf dem ESP noch irgendwo diese falsche Info. Zum Testen hätte ich eher die setList angepasst oder mal ein publish auf den mitgeteilten Topic versucht, statt die "Wind.*-Methode" anzuwenden...
Ansonsten: PowerLAN ist "noch berüchtigter" wie WLAN für Probleme (hier aber ohne LoRa-Selbstbau vermutlich kaum zu vermeiden).
Hallo Beta-User, hallo supernova,
der Fehler ist jetzt raus. es muss irgendwie mit den subscriptions zu tun gehabt haben.
Der Begriff Wind.* Methode sagt mir zwar nichts, aber ich vermute genau den Weg habe ich jetzt gemacht.
Nachdem ich das Device (nochmal) galöscht und auch den Shelly Resettet habe gingen die Befehle durch. In den Subscriptions ist jetzt auf der Prefix unter list mqtt.* subscriptions verschwunden.
Lesson Learned für mich: Finger weg von dem Custom Prefix.
Danke euch für die Unterstützung
VG
Christian
Hallo @Chritian_M,
freut mich, dass es funktioniert.
Gernot