MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[Beta-User]

Für mich ist das ein "bug". Aber auch nur weil man es so sicher nicht gewollt hat.

Na ja, sagen wir es so: In der Vergangenheit waren vermutlich viele user sehr froh, dass es diese on/off-Sonderbehandlung gab und haben das definitiv (unbewußt) als feature genutzt!
Dass wir jetzt
a) hergehen, und ein Haufen an Infos in STATE packen, ist ein recht neues Phänomen und b) das ganze dann auch noch (ohne Perl) gesplittet schaltbar haben wollen und können ist definitiv brand new!

Also entweder bauen wir das devStateIcon mit Perl selbst (was vermutlich "schon immer" geht...), oder jemand ist so freundlich und paßt FHEMWEB auch noch so an, dass "das richtige" rauskommt (also nur schaltbare Icons auch schaltbar sind). Die Frage wird nur sein: Wie unterscheiden...? Denn die, die das Verhalten bisher als feature angesehen haben, werden es nicht missen wollen .

[87insane]

Ggf. kann man stateFormat einfach ein Attribut mitgeben?
Da das was ich bzw. wir hier gerade nutzen das neuere ist... würde ich sagen man könne vor den Dingen die nichts schalten sollen einfach was vorhängen (magic z.B. macht das um Readings einzugrenzen [i:/r: usw.]).

Beispiel:

attr NAME stateFormat:
s:reading1 (s: = Schaltbar)
reading2 (kein s: nicht Schaltbar)

Oder das ganze genau anders rum... Es ist im Zuge der Veränderung natürlich klar, dass sowas vermutlich immer mal passieren wird... Was kann ich tun um zu helfen oder aber das hinzubekommen?

Das Problem ist hier eigentlich auch nur da Alexa-fhem unbedingt on/off haben will. Ggf kann man den filter irgendwo anpassen und zusätzlich on1/off1 oder so einfügen. Dann würde alles klappen. Gehe mal davon aus, das kann hier keiner beantworten und ich muss im alexa fhem thread an Fragen?

[Beta-User]

Zeige doch den Link auf die IP einfach im Klartext und verzichte auf die Klickbarkeit (oder verzichte ganz auf die Anzeige der IP). Das ist doch nur ein "Schönheitsfehler", auf die Weboberfläche mußt du doch eh selten, oder...?

[87insane]

Kann man so sehen... Würde es aber gerne einheitlich haben und finde die Funktion gut. Im besten Fall muss man natürlich nie wieder dahin und es wäre einfach sinnloser Aufwand. Aber wer gibt schon gern auf wenn es möglich ist. Hinzu wurde das quasi nochmal entdeckt, das es so ist und hier macht es ja auch Sinn, das dieses Thema ggf. wegen einer anderen Sache wieder hoch kommt.

Gucke mal ob ich Alexa ggf. beibringen kann auf on1 / off1 zu hören. Dann würde es auch laufen...
Alternativ könnte man auch einen dummy für das Gerät anlegen. Dieser wiederum könnte dann on/off beinhalten. Das anlegen des Dummys könnte man auch über das Template? Sowas wie define GleicherName_alexa dummy und dann die entsprechenden setList hinterlegen usw. Wäre das sinnig?

[gvzdus]

Thema "ShellyBulb" (nutzt den überhaupt jemand außer mir?)

Beta-User schrieb im anderen Thread

Nur für den Fall, dass das eine Art Referenz sein soll: Das MQTT2-Device sieht aus meiner Warte sehr komisch aus und sollte nach dem aktuellen Standard (nach einem autocreate oder auch der Anwendung eines attrTemplate) anders aussehen.
Wenn Änderungsbedarf an einem attrTemplate bestehen sollte, um da was zu standardisieren, bitte um entsprechende Rückmeldung

Nee, das Device entspricht m.E. unverändert dem Template A_15_shellybulb wie ich es geschrieben hatte, und das funktioniert soweit auch unverändert in FHEMWEB. Welchen Änderungsbedarf gibt es?

[Beta-User]

Nee, das Device entspricht m.E. unverändert dem Template A_15_shellybulb wie ich es geschrieben hatte, und das funktioniert soweit auch unverändert in FHEMWEB. Welchen Änderungsbedarf gibt es?

Ich hatte in dem anderen Thread gesehen, dass da noch eine erweiterte Version des json2nameValue() genutzt wird und das Reading mit dem topic-Tree-Namen dürfte auch nicht "state of the art" sein:

Code Auswählen Erweitern

Internals:
     2019-05-02 00:27:12   shellies/shellybulb-3CC533/color/0 off
     2019-05-02 00:27:12   state           off
     2019-05-02 00:27:12   status_blue     125
     2019-05-02 00:27:12   status_brightness 51
     2019-05-02 00:27:12   status_effect   0
     2019-05-02 00:27:12   status_gain     26
     2019-05-02 00:27:12   status_green    128
     2019-05-02 00:27:12   status_ison     false
     2019-05-02 00:27:12   status_mode     white
     2019-05-02 00:27:12   status_red      128
     2019-05-02 00:27:12   status_temp     4750
     2019-05-02 00:27:12   status_white    0
   readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shellybulb-3CC533/color/0/command off
  on:noArg shellies/shellybulb-3CC533/color/0/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
  temp:colorpicker,CT,3000,10,6500 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/; "shellies/shellybulb-3CC533/color/0/set {\"ison\":true,\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2)."\"blue\":".hex($3) }
   userReadings rgb {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
   webCmd     on:off:brightness:temp:rgb
Dagegen haben die für das rgb-userreading genutzten Readings alte Zeitstempel, das ist also nur eine "Scheinaktualisierung", die du da siehst:

Code Auswählen Erweitern

2018-12-16 12:52:56   blue            0
     2018-12-16 12:52:56   brightness      10
     2018-12-16 12:52:56   effect          0
     2018-12-16 12:52:56   gain            26
     2018-12-16 12:52:56   green           0
     2018-12-16 12:52:56   ison            true
     2018-12-16 12:52:56   mode            white
     2018-12-16 12:52:56   red             128
Für das template (das ansonsten für mich ok aussieht, aber von deinem list abweicht) bzw. das dortige rgb würde ich jetzt die Verwendung eines einschränkenden Triggers vorschlagen (die werden zusammen aktualisiert, von daher reicht eines als trigger):

Code Auswählen Erweitern

userReadings rgb:red {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}

[87insane]

So, jetzt habe ich doch noch was gefunden:
FHEMWEB unterscheidet on/off-Geräte von anderen, und man kann das Schalten unterbinden, wenn man ein "noFhemwebLink" als (Schalt-) Anweisung hinter das Icon in devStateIcon schreibt.
ABER: auch der Link an sich funktioniert dann nicht mehr...

Wenn man die IP sehen will, muß man die im Klartext hinwürgen, aber der link ist dann wieder "on".

Teilerfolg sieht also so aus:

Code Auswählen Erweitern

attr sz_deckenlicht devStateIcon c.true:10px-kreis-gruen:noFhemwebLink c.false:10px-kreis-rot:noFhemwebLink on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on
attr sz_deckenlicht stateFormat <a href="http://ip" target="_blank">\c:online\</a>\
relay0\
Aktueller Verbrauch: relay_0_power W <div>Temperatur: temperature °C</div>

Damit hat man dann auch Verbrauch und Temperatur untereinander nach den Icons (ist aber auch nicht schön, dient nur zur Demo...).

Wenn man das anders haben will, müßte man also die Perl-Variante nutzen (?), oder Rudi einen Patch für FHEMWEB anbieten, der dann nur Icons explizit schaltbar macht, für die das bei mehrzeiligen angegeben ist. Das ganze gehört vermutlich in diesen Kontext: https://forum.fhem.de/index.php/topic,97586.msg908277.html#msg908277.

Leider kann ich in diesen Kontext nicht schreiben... Ggf. nur Admins? Habe gestern auch noch ein wenig rum gespielt. Am einfachsten ist es mit einem dummy. Allerdings muss man dann einen dummy+notify/doif für quasi nur ein klickbares Symbol und Alexa Sprachsteuerung anlegen. Das empfinde ich als eher zu viel Aufwand für nichts. Werde gleich mal in den Alexa-Fhem Thread schreiben ob die Kollegen ggf. was machen können. Wenn Alexa auch auf andere Dinge triggern könnte, wäre super. Ich denke das geht mit Homebridgemapping aber das verstehe ich noch nicht so ganz....

[Beta-User]

Einfacher als dummy: ReadingsProxy...

Aber: das ganze ist und bleibt - nach meiner persönlichen Meinung - ein workaround rund um die m.E. klare Entwicklerentscheidung, Geräte, die on und off kennen in FHEMWEB "anders" zu behandeln. Also macht es m.E. keinen großen Sinn, andere Entwickler mit der Frage zu behelligen. Ergo: Entweder du überzeugst Rudi, dass da Verbesserungspotential besteht, oder du schreibst einen devStatIcon-Perl-Code, der das so macht, wie du das willst oder lebst mit der "Unklickbarkeit" auf die IP (was m.E. auch nicht schlimm ist)...

Ich werde mich jedenfalls dazu nicht mehr äußern.

[rudolfkoenig]

da Beta-User sagte ich solle dir das mal erklären bzw. erzählen tue ich das mal.... Es geht hierum:
https://forum.fhem.de/index.php/topic,94060.msg935693.html#msg935693

Ich weiss immer noch nicht genau, was man will/was das Problem ist, ich habe das Gefuehl, dass die Listings der Beschreibung widersprechen.

Wenn folgender Fix:

Code Auswählen Erweitern

attr sz_deckenlicht stateFormat <a href="http://ip" target="_blank">c:online</a>\
relay0\
Aktueller Verbrauch: relay_0_power W / Temperatur: temperature °C
nicht hilft, dann brauche ich eine reduzierte/einfache Version, was das Problem zeigt, samt Beschreibung des Problems.

Btw. die "genial aufgebohrte" Version von stateFormat stammt von justme1968, eigentlich sollte er hier einspringen

[87insane]

Das ist ein Witz oder? (Also positiv!)

Wie genial ist das denn? Also es genügt den Teil <a href="http://[$name:ip]" target="_blank">[$name:online]</a> in eine Reihe zu schreiben. Im Template und auch bisher sah das so aus:

Code Auswählen Erweitern

<a href="http://[$name:ip]" target="_blank">
[$name:online]
</a>
[$name:relay0]
Aktueller Verbrauch: [$name:relay_0_power] / Temperatur: [$name:temperature] °C
(oder ähnlich ohne magic)

Sobald es in einer Reihe steht, auch ohne c: vor dem Reading geht es wie gewünscht. Habe es nun mit magic und ohne getestet und beides geht.
ABER hier wird dann das Wort true nicht mehr in den kleinen Kreis umgewandelt. Wenn ich im devStateIcon nun einfach mal .*true.* eingebe bekommt man eine komische Anzeige. Also es wäre Alexa Steuerung so möglich, das klicken auf true eröffnet auch die entsprechende IP im Browser ABER kein grünes Icon... Das ist schon sehr nah an einer Lösung.

Anbei mal ein Bild wie es aussieht mit .*true.* im devStateIcon. Wenn man nur true (ohne Platzhalter) eingibt, dann ist der grüne Punk auch nicht da aber es steht auch nur true dort anstelle dessen was man im Bild sieht.
Zusätzlich nochmal ein List -r anbei.

Code Auswählen Erweitern



define sz_deckenlicht MQTT2_DEVICE shelly1pm_B1D951
attr sz_deckenlicht IODev MQTT2_FHEM_Server
attr sz_deckenlicht alias Schlafzimmer Deckenlicht
attr sz_deckenlicht devStateIcon .*true.*:10px-kreis-gruen false:10px-kreis-rot on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on
attr sz_deckenlicht model A_10b_shelly1pm
attr sz_deckenlicht readingList shellies/shelly1pm-B1D951/relay/0:.* state\
  shellies/shelly1pm-B1D951/relay/0:.* relay0\
  shellies/shelly1pm-B1D951/input/0:.* input0\
  shellies/shelly1pm-B1D951/online:.* online\
  shellies/shelly1pm-B1D951/announce:.* { json2nameValue($EVENT) }\
  shellies/shelly1pm-B1D951/relay/0/power:.* relay_0_power\
  shellies/shelly1pm-B1D951/temperature:.* temperature\
  shellies/shelly1pm-B1D951/overtemperature:.* overtemperature\
  shellies/shelly1pm-B1D951/relay/0/energy:.* relay_0_energy\
  shellies/shelly1pm-B1D951/longpush/0:.* longpush_0\
  shellies/announce:.* { json2nameValue($EVENT) }
attr sz_deckenlicht room MQTT,Schlafzimmer
attr sz_deckenlicht setList relay0:on,off,toggle shellies/shelly1pm-B1D951/relay/0/command $EVTPART1\
  off:noArg shellies/shelly1pm-B1D951/relay/0/command off\
  on:noArg shellies/shelly1pm-B1D951/relay/0/command on
attr sz_deckenlicht stateFormat <a href="http://ip" target="_blank">online</a>\
relay0\
Aktueller Verbrauch: relay_0_power W / Temperatur: temperature °C
attr sz_deckenlicht webCmd :relay0

setstate sz_deckenlicht <a href="http://192.168.20.53" target="_blank">true</a>\
off\
Aktueller Verbrauch: 0.00 W / Temperatur: 32.04 °C
setstate sz_deckenlicht 2019-05-03 09:28:36 fw_ver 20190423-080637/v1.4.9-switch1pm-hotfix4@f8c51629
setstate sz_deckenlicht 2019-05-03 09:28:36 id shelly1pm-B1D951
setstate sz_deckenlicht 2019-05-03 09:48:24 input0 0
setstate sz_deckenlicht 2019-05-03 09:28:36 ip 192.168.20.53
setstate sz_deckenlicht 2019-05-03 06:30:39 longpush_0 1
setstate sz_deckenlicht 2019-05-03 09:28:36 mac 840D8EB1D951
setstate sz_deckenlicht 2019-05-03 09:28:36 new_fw false
setstate sz_deckenlicht 2019-05-03 09:28:36 online true
setstate sz_deckenlicht 2019-05-03 09:48:24 overtemperature 0
setstate sz_deckenlicht 2019-05-03 09:48:24 relay0 off
setstate sz_deckenlicht 2019-05-03 09:36:54 relay_0_energy 320
setstate sz_deckenlicht 2019-05-03 09:48:24 relay_0_power 0.00
setstate sz_deckenlicht 2019-05-03 09:48:24 state off
setstate sz_deckenlicht 2019-05-03 09:48:24 temperature 32.04

Problem in kurz: Sobald in setList die Readings on/off stehen, kann man den online/offline Punkt nicht mehr anklicken. Dieser schaltet dann das Gerät "on" anstelle den Browser mit der IP zu öffnen. Sobald die Befehle aus setList gelöscht werden, kann man auf den Punkt klicken und landet im Webinterface. Da aber sicherlich einige Alexa nutzen, brauch man on/off damit Alexa-Fhem automatisch erkennt, das es ein Schalter ist. Sicherlich geht es anders aber die "genial aufgebohrte" Version kann ja durchaus noch lernen Habe das die Tage "bug" genannt. Dem ist natürlich nur so, da es früher nicht dafür gedacht war. Nehmt mir das Wort nicht sooo übel bitte

Danke!

[Beta-User]

@Rudi:

Das "Problem" ist, dass das Device mit der vollständigen setList zum $hasOnOff-Device für FHEMWEB wird, was nach meinem Verständnis des codes dazu führt, dass ganz am Ende der on/off-Link ergänzt wird (L3218ff).

Ich würde darauf tippen, dass es reichen würde, zusätzlich noch abzufragen, ob ein Zeilenumbruch in stateFormat vorhanden ist (und wenn ja: behandeln wie wenn es kein $hasOnOff-Device wäre - hier kümmert sich ja offenkundig der user darum, dass er funktionale Einzelicons hat...). Da das mit dem Zeilenumbruch "erfunden" wurde, um mehrere Icons anzuzeigen, wäre das eventuell einigermaßen nebenwirkungsfrei?

[rudolfkoenig]

@Beta-User: Danke fuer die Erklaerung.

Ich bin wg. dem Beispiel von 87insane trotzdem noch verwirrt: auch wen ich das on/off Handling abschalte, funktioniert der Verweis aus seinem Beispiel nicht: das Hinzufuegen eines Icons zum <a> Tag rendert das <a> Tag wirkungslos, da Text (bzw. <a> Tag) durch das Bild ersetzt wird.

Mir widerstrebt eine Ausnahmebehandlung fuer diesen Fall einzubauen:
- die Stelle ist als _Statusanzeige_ gedacht mit Schalten, der Link zum Geraet ist ein Missbrauch
- eine mit allen Features (Bild, etc) funktionierende Ausnahme ist aufwendig, damit schlecht wartbar.
- es gibt bereits eine Loesung fuer Querdenker: devStateIcon in perl.

[87insane]

Das kann Beta-User sicher besser beschreiben.

ABER in anderen Templates ohne on/off in setList geht genau das ohne Probleme....

z.B. mal einen anderen Schalter:

Code Auswählen Erweitern

<a href="http://IPAddress" target="_blank">
LWT
</a>
1:POWER1
2:POWER2

Hier kann ich beide POWER schalten und auch mit klick auf den kleinen grünen Kreis auf das Webinterface. Aber auch hier habe ich mal zum testen on/off als Befehl in setList hinterlegt. Geht dann auch nicht mehr.

[Beta-User]

Hmmm, ist das kaputte <a>-tag mit ausgeschaltetem onoff-handling auch kaputt, wenn es mehrzeilig ist? Dass .*true.* das "auffrißt", ist noch einigermaßen nachvollziehbar...

Was "Mißbrauch" angeht: Das liegt im Auge des Betrachters. STATE darf durchaus (auch bisher) dazu genutzt werden, alle möglichen Infos darzustellen. Es ist offen gesagt etwas irritierend, wenn der Klick auf einen Temperatur-TEXT zum Schalten eines zufällig auch vorhandenen Relais führt (die negative begrifflichkeit hat wohl auch was mit deiner Abneigung gegen "mehrkanalige Devices" zu tun ).

Ergo: wenn das Abschalten der onoff-Prüfung für umgebrochene stateFormat NUR das jeweilige Icon klickbar machen würde, wäre mein Wunsch, das mal in dem Beitrag von Andre zur Diskussion zu stellen, wie das allg. im Entwicklerkreis gesehen wird. Mein Votum wäre dann dafür, diese Prüfung einzubauen, aber verstreiten würde ich mich dafür auch nicht. Denn wie ich hier auch schon geäußert hatte, gibt es auch alternativ den Perl-Weg für die, die das wollen.

[rudolfkoenig]

ABER in anderen Templates ohne on/off in setList geht genau das ohne Probleme....

Liegt an der Kombination von auf mehrere Zeilen verteiltes <a> (eigentlich nicht vorgesehen, da jede stateFormat Zeile als eine Einheit behandelt wird), und den Unsinn, was FHEM daraus in seiner Naivitaet zusammenbaut (siehe HTML Quelltext).

Wie gesagt: es richtig mit allen Features zu machen ist aufwendig, und jeder, der das unbedingt will, darf es mit der perl Version von devStateIcon selbst bauen.