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.
...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.
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!
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.......
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.
...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...
Bei weiterem Austesten des attrTemplates shellyPlus_1 wäre ich dabei...
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?
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.
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
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.
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.
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 :
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.
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
Sehe ich wie Beta-User ... nach Anwendung des Templates MUSS der Shelly neu gestartet werden, ansonsten wird irgendwann vielleicht mal der params_wifi-Block transportiert. Dem sys-Block ergeht es ähnlich - beim Start ja, aonsonsten eher nicht ...
Ein bisschen zu spät, aber vielleicht den Reboot als Hinweis ins Template aufnehmen oder das reboot-Kommando am Template-Ende ausführen.
Generell gilt bei Firmware-Versionen vom Plus das schon bei den alten Shellies bekannte Verhalten. Im Zweifel hat jeder Plus nach Update diegleiche Version, aber das heisst nicht zwingend, dass jeder die gleichen Features hat ...
Bevor hier wieder RTL entstehen:
Zitat von: isy am 14 Januar 2022, 11:11:41
- Nach FW Update ist manuell ein Factory Reset angesagt.
Nur, wenn der Menüpunkt "Generic update" nicht vorhanden ist, sonst eher nicht zwingend!
Zwingend ist: der Punkt muss aktiviert sein!
Zitat
- FHEM shutdown/restart (hatte den Punkt auf "grün" gesetzt, jedoch noch keine IP im Reading)
Das ist unnötig! Der Shelly sendet den LWT-Status beim Verbinden mit dem Server. Daher reicht
Zitat- Shelly neu booten.
Werde den reboot-Befehl ins attrTemplate reinnehmen, das machen wir bei diversen Tasmota auch so...
Ich denke, das Reboot nach FW Update ist zwingend (gewesen).
Im alten Reading vor dem Reset gab es die Zeilen:
sys_available_updates version 0.9.1
sys_available_updates_beta_version 0.9.2-beta2
Jetzt gibt es nur noch:
sys_available_updates_beta_version 0.9.2-beta2
Das hätte ich schon eher mit notwendigem Factory Reset in Verbindung bringen können.
Dadurch wäre der etwas zähe Weg zur Lösung einfach gewesen.
...komme nicht mit...
Keiner behauptet, dass ein reboot des Shelly _nicht_ hilfreich wäre - den sollte man machen, zumindest, wenn man saubere "online"-Werte und die IP haben will (sonst ist es halt vorübergehend "unschön").
Nicht zwingend ist _in der Regel_ der factory reset. Das scheint ein spezielles Problem auf deinem Shelly gewesen zu sein, das sich ggf. mit der nächsten Lieferung (oder bei einem zunächst erfolgten update und dann der Aktivierung der MQTT-Option) schon nicht mehr in dieser Form stellt. Den sollte man also nur dann machen, wenn man den Menüpunkt für die MQTT-updates nicht hat. (nicht zu verwechseln mit den firmware-update-Infos).
Zitat von: isy am 14 Januar 2022, 11:37:37
Ich denke, das Reboot nach FW Update ist zwingend (gewesen).
Bislang hatte ich noch kein FW-Update, das nicht autom. mit einem Reboot endete ...
Zitat von: isy am 14 Januar 2022, 11:37:37
Im alten Reading vor dem Reset gab es die Zeilen:
sys_available_updates version 0.9.1
sys_available_updates_beta_version 0.9.2-beta2
Jetzt gibt es nur noch:
sys_available_updates_beta_version 0.9.2-beta2
Mit Reading in der ersten Zeile meinst Du vermutlich Device ... nach dem Reset hast Du wahrscheinlich nochmals das Template auf das alte Device angewendet oder ein neues Device anlegen lassen und dann das Template angewendet ... Template-Anwendung sorgt in der Regel für einen fast leeren Reading-Bereich ... anschließend sammeln sich erst langsam wieder die ersehnten Readings an ... beschleunigt durch ein neuerliches Reboot, falls nicht schon durch das Template angestossen ...
Zitat von: Beta-User am 13 Januar 2022, 17:29:12
.........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).
Das war der Hinweis, den Beta-User gestern gefunden hatte.
Alle Tests wurden nach seinen Statements mit neu angelegtem Shelly durchgeführt.
Heute morgen kam ich dann drauf, den Factory Reset manuell anzustossen. Ich kann mich nicht erinnern, ob der Reset nach dem Flash auf 0.9.1 automatisch erfolgte.
Zitat von: isy am 14 Januar 2022, 12:50:23
Ich kann mich nicht erinnern, ob der Reset nach dem Flash auf 0.9.1 automatisch erfolgte.
Ziemlich sicher: Nein. Ein firmware-Update soll in der Regel keinen factory-reset auslösen. Nur einen reboot.
Dass hier ein reset nötig war, ist die große Ausnahme! Daher schreibe ich ja die ganze Zeit, dass es FALSCH ist, das zum _muss_ zu erklären. Das ist es nämlich nur dann, wenn irgendwas schiefgeht - warum auch immer.
Wir sollten das Thema jetzt beenden, es führt zu nichts. Dein Shelly hatte einen ungewöhnlichen "Hau" - kann vorkommen, ist aber nicht verallgemeinerungsfähig. Basta.
Fazit: attrTemplate hat prinzipiell funktioniert, manche Verständnislücken wurden erläutert, update für die attrTemplate (betr. Erläuterungen) folgt, alles gut...
Danke. Hab heute 2 plus1pm in betrieb genommen. der erste auf anhieb, der 2te dann das problem wie hier beschrieben. im web interface des shelly fehlten auch z.b. sntp server, eco mode, usw.
mit dem factory reset hats dann geklappt.
Firmware version: 0.10.0
Firmware build ID: 20220308-100720/0.10.0-g4eda0ff
Web build ID: 1.5.5-154bed6
Gut so!