[gelöst] ShellyPlus1 lässt sich schalten, bleibt im state set_off oder set_on

Begonnen von isy, 13 Januar 2022, 17:18:35

Vorheriges Thema - Nächstes Thema

isy

Moin zusammen,
habe den Shelly in Betrieb genommen, mit den Infos/Updates aus dem Thread "[gelöst] Shelly PLus 1"...... erscheinen alle GUI Informationen korrekt.
Schalten funktioniert einwandfrei.

Allerdings bleibt der STATE auf "set_on" oder "set_off" stehen:
STATE set_off

Kann man/ich das ändern oder ist das bei euch auch so?

VG Helmut

List im Anhang.
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Beta-User

...die Dinger sind irgendwie komisch...

Zum einen wundert mich, dass im jsonMap was fehlt, was bei dem angeblich (so das reading) angewandten attrTemplate drin sein müßte, zum anderen kommen da wieder Readings, die es gar nicht geben dürfte (die ganzen "params"-Dinger).
params_sys_available_updates_stable_version 0.9.1
würde ich mal dahingehend interpretieren, dass die firmware nicht aktuell ist? Wenn ja: die letzte stable nehmen (beta ist angeblich untauglich).

Ansonsten muss man afaik bei den Dingern irgendeinen MQTT-update-Schalter anmachen. Sollte im "Shelly"-Thread genauer zu finden sein.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Habe mir deinen Stand nochmal angesehen. Leider habe ich den eigentlich deutlichen Hinweis auf manuelle Manipulationen zunächst nicht für voll genommen, aber nochmal allerdeutlichst:
Zitat von: isy am 13 Januar 2022, 17:18:35
mit den Infos/Updates aus dem Thread "[gelöst] Shelly PLus 1"...... erscheinen alle GUI Informationen korrekt.
Der dortige Stand ist schlicht überholt, es macht überhaupt keinen Sinn, händisch irgendwas am Ergebnis von dem rumzuschrauben, was attrTemplate liefert (es sei denn, man weiß GENAU, was man tut).

Nach den Rückmeldungen von OdfFhem und smudo (bis hier: https://forum.fhem.de/index.php/topic,94060.msg1199718.html#msg1199718) gehe ich davon aus, dass die jetzigen attrTemplate-Fassungen mit der aktuellen firmware (iVm. passenden Einstellungen auf der firmware-Seite wie in der Beschreibung der attrTemplate jeweils auch benannt) kein Problem haben, und ansonsten jede Manipulation "gefahrgeneigt" ist...

Wenn dir am Ergebnis was nicht gefällt, kann man darüber diskutieren, aber bereits gelöste Probleme nochmal durchzukauen ist unnötig!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

isy

FW Update hatte ich gestern gemacht, 0.9.1, es gibt eine Beta 0.9.2, damit bin ich immer etwas vorsichtig.
Ich habe eben mal ein Reboot gemacht, ändert nichts.

Bei meinem ShellyPlus1 finde ich den Punkt "Generic status update over MQTT" im Shelly Menü gerade nicht.......
Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

Ja das Gefuckel ist unschön, da bin ich bei dir! Vor allem, ohne meinerseits zu wissen, was genau dahinter steckt.

Mit den o.g. RAW Ergänzungen funktionieren die Icons und der Shelly lässt sich schalten.

Mit dem Original Template nach manuellem Löschen / Autocreate geht das Schalten, aber der Status bleibt auf "set_toggle" stehen. Die Icons sind fehlerhaft, der Link zum Shelly führt zu einer leeren Seite.
Siehe Bild.

Das ist der aktuelle Standard des attrTemplate shellyPlus_1 ohne weitere Änderungen in der Def.

Ein Weg wird erst zu einem Weg, wenn man ihn geht

Beta-User

...betr. der MQTT-Einstellungen kenne ich das nur vom Hörensagen, 0.9.1 scheint bei dem plus1pm jedenfalls die passende Version zu sein und diese Art Einstellung zu kennen.

Klar ist: Wenn der Shelly nichts sendet, kann es nicht klappen, sendet er unter den "falschen Namen", schließt sich der Kreis nicht. Um ihn zu schließen, muss man den MQTT-Verkehr kennen, dann kann man eingreifen. Aber wenn die Senderichtung für toggle/on/off paßt, ist das schon mal was.

Die IP kommt erst mit einem reboot des ESP. Unter welchem Namen, wäre die Frage. => MQTT-Verkehr...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

isy

Bei weiterem Austesten des attrTemplates shellyPlus_1 wäre ich dabei...
Ein Weg wird erst zu einem Weg, wenn man ihn geht

isy

Im attrTemplate zum Shelly 1 Plus wird vermerkt:
NOTE: requires to activate generic status update in firmware settings

In anderen Foren: Generic status update over MQTT mus gesetzt werden.

Frage: Diese Option lässt sich bei der aktuellen Firmware 0.9.1 nicht mehr setzen? Fehlt daher Rückmeldung zum Schaltbefehl und der Shelly bleibt im Status "set_xx" stehen?

Ein Weg wird erst zu einem Weg, wenn man ihn geht

Beta-User

Zitat von: isy am 13 Januar 2022, 18:27:05
Bei weiterem Austesten des attrTemplates shellyPlus_1 wäre ich dabei...
So wie ich smudo verstanden habe, muss man eigentlich nichts mehr austesten, das funktioniert.

Zitat von: isy am 13 Januar 2022, 20:15:48
Im attrTemplate zum Shelly 1 Plus wird vermerkt:
NOTE: requires to activate generic status update in firmware settings
Da steht drin, was ich wusste bzw. aus den verfügbaren Infos zusammengekratzt habe. Das muss nicht richtig sein, aber es spricht vieles dafür, dass es richtig ist...

Zitat
In anderen Foren: Generic status update over MQTT mus gesetzt werden.

Frage: Diese Option lässt sich bei der aktuellen Firmware 0.9.1 nicht mehr setzen? Fehlt daher Rückmeldung zum Schaltbefehl und der Shelly bleibt im Status "set_xx" stehen?
Ich vermute: Es läßt sich setzen! Und ja: Wenn eine Rückmeldung kommt, die Auswertung dessen was kommt richtig ist (was ich vermute, dass es der Fall ist), dann wird auch "state" korrekt aus der Rückmeldung akutalisiert...

Ergo: "Finde den Knopf"...
Dann können wir ggf. besser beschreiben, wie/wo das mit dem generic status update geht bzw. gemeint ist.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

enno

Zitat von: Beta-User am 14 Januar 2022, 09:24:29
Ergo: "Finde den Knopf"...
Dann können wir ggf. besser beschreiben, wie/wo das mit dem generic status update geht bzw. gemeint ist.

Moin

der "Knopf" ist bei 8.1 und auch bei 9.1 zu finden unter:
Networks - Mqtt dann rechts neben "Generic status update over MQTT"...

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

isy

Moin enno,
super Tipp!

Meine Beobachtung: Der Menüpunkt ist verschwunden, auch nach Reboot! Eventuell muss nach FW Update ein Factory Reset gemacht werden.

Ich habe also einen Factory Reset durchgeführt und die beiden Funktionen (RPC und Update) werden angezeigt und ich habe sie aktiviert.
MQTT Verbindung eingegeben. Der Shelly läuft wieder.

Danach habe ich die alte Def gelöscht, per autocreate neu angelegt und das attrTemplate shellyPlus1 zugeordnet.
Damit wird jetzt der Status auf "on" oder "off" gesetzt.
Das runde Icon links bleibt allerdings rot und der Link führt zu einer leeren Seite "http://none/". Eine Temperatur von 58.2 Grad (intern?) wird angezeigt.
Siehe Bild.

Nach shutdown/restart in FHEM wird der Punkt jetzt grün angezeigt, der Link führt aber weiterhin ins Leer.

Damit bin ich also deutlich weiter!
Leider reichen meine Kenntnisse nicht aus, das Thema "Punkt" in die richtige Funktion zu bringen.

Ein Weg wird erst zu einem Weg, wenn man ihn geht

Beta-User

OK, also in der Tat ein Fall von "Banane" (Produkt reift beim Kunden...).

Nach dem ursprünglichen list müßte eigentlich weiter "params_wifi_sta_ip" geliefert werden, also das Reading "ip" passend gefüllt sein. Würde also auf ein fehlendes Leerzeichen vor "target" bei devStateIcon tippen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

isy

Alles gut!

Das von dir genannte Reading "ip" sehe ich nicht (hab ich was auf den Augen hi?). Und vor dem target steht kein Blank.
Internals:
   CID        shellyplus1_441793a724fc
   DEF        shellyplus1_441793a724fc
   DEVICETOPIC shellyplus1-441793a724fc
   FUUID      61e14022-f33f-27cb-0366-6a6489188831f816
   IODev      MyMQTT
   LASTInputDev MyMQTT
   MSGCNT     37
   MyMQTT_CONN MyMQTT_192.168.178.96_49281
   MyMQTT_MSGCNT 37
   MyMQTT_TIME 2022-01-14 10:39:23
   NAME       MQTT2_shellyplus1_441793a724fc
   NR         1124
   STATE      off
   TYPE       MQTT2_DEVICE
   JSONMAP:
     params_wifi_sta_ip ip
     switch_state state
     switch_temperature_tC temperature
     switch_temperature_tF 0
   READINGS:
     2022-01-14 10:29:40   IODev           MyMQTT
     2022-01-14 10:19:56   attrTemplateVersion 20220110
     2022-01-14 10:39:23   dst             shellyplus1-441793a724fc/events
     2022-01-14 10:39:23   method          NotifyStatus
     2022-01-14 10:29:52   mqtt_connected  true
     2022-01-14 10:29:52   online          true
     2022-01-14 10:36:05   params_events_1_cfg_rev 5
     2022-01-14 10:36:05   params_events_1_component wifi
     2022-01-14 10:36:05   params_events_1_event config_changed
     2022-01-14 10:36:05   params_events_1_restart_required false
     2022-01-14 10:36:05   params_events_1_ts 1642152966.20
     2022-01-14 10:29:52   params_mqtt_connected false
     2022-01-14 10:39:23   params_switch_0_id 0
     2022-01-14 10:39:23   params_switch_0_output false
     2022-01-14 10:39:23   params_switch_0_source MQTT
     2022-01-14 10:28:23   params_switch_0_temperature_tC 60.65
     2022-01-14 10:28:23   params_switch_0_temperature_tF 141.17
     2022-01-14 10:39:23   params_ts       1642153163.86
     2022-01-14 10:39:23   src             shellyplus1-441793a724fc
     2022-01-14 10:39:23   state           off
     2022-01-14 10:39:23   switch_id       0
     2022-01-14 10:39:23   switch_source   MQTT
     2022-01-14 10:39:23   temperature     59.3
Attributes:
   devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot': '10px-kreis-gruen'; $onl = FW_makeImage($onl); my $light = FW_makeImage(ReadingsVal($name,'state','off')); my $temp = ReadingsVal($name,'temperature','-100'); my $ip = ReadingsVal($name,'ip','none'); qq(<a href="http://$ip"target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a><div>Temp: $temp °C</div>)}
   devicetopic shellyplus1-441793a724fc
   icon       message_socket
   jsonMap    switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip
   model      shellyPlus_1
   readingList $DEVICETOPIC/online:.* online
  $DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }
  $DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }
  $DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }
  $DEVICETOPIC/status/switch_0:.* { $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT, 'switch_', $JSONMAP) }
  fhem2shelly/rpc:.* {}
   room       MQTT2_DEVICE
   setList    toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}
  off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}
  on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true}}
  on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}
  x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Update","params": {"stage":"stable"}}
  x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Reboot"}
   setStateList on off toggle
   webCmd     :
Ein Weg wird erst zu einem Weg, wenn man ihn geht

Beta-User

Zitat von: isy am 14 Januar 2022, 10:53:02
Das von dir genannte Reading "ip" sehe ich nicht (hab ich was auf den Augen hi?).
Ich sehe es auch nicht, meine Erfahrungen mit dem pm4er und dem plus1pm waren allerdings so, dass das einen Reboot braucht, damit was kommt. Warum es hier nicht (mehr) klappt: keine Ahnung. In deinem ersten list aus dem Ausgangspost war die Info (unter anderem Namen) da, von daher sollte das gehen, sobald der Shelly das übermittelt, auf der FHEM-Seite kann man einstweilen jedenfalls mAn. in dieser Beziehung nichts verbessern.

Zitat
Und vor dem target steht kein Blank.
Kommt mit dem nächsten update, schadet sicher nicht... Bringt aber auch nichts, wenn der Shelly die IP nicht sendet.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

isy

Nach einem Reboot des Shelly wird das Reading "ip" gefüllt!
Danke für alle Mühen!

Fasse zusammen:
- Nach FW Update ist manuell ein Factory Reset angesagt.
- Shelly anlegen per autocreate
- attrTemplate shellyPlus_1 zuweisen
- FHEM shutdown/restart (hatte den Punkt auf "grün" gesetzt, jedoch noch keine IP im Reading)
- Shelly neu booten.
- GUI sieht gut aus, Link funktioniert!

VG Helmut
Ein Weg wird erst zu einem Weg, wenn man ihn geht