FHEM Forum

FHEM - Hausautomations-Systeme => MQTT => Thema gestartet von: miggun am 03 Dezember 2018, 21:05:34

Titel: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 03 Dezember 2018, 21:05:34
Hallo,
ich habe heute meinen Shelly 2 und Shelly4 bekommen, die auch über die hauseigene Shelly-App wunderbar arbeiten, jetzt wollte ich den Shelly2 in FHEM installieren und da kommen bei mir große Fragezeichen auf.
Zuerst hatte ich MQTT Mosquitto aktiviert, habe dann aber hier gelesen, dass MQTT2 wesentlich komfortabler ist. Naja, bei mir scheitert es schon daran das Wiki zu verstehen.

So sieht gerade die RAWmeines MQTT2 aus, ab da verstehe ich nicht mehr, was das Wiki von mir möchte.
defmod MQTT2_SERVER MQTT2_SERVER 1883 global
attr MQTT2_SERVER autocreate 1

Wenn ich das richtig verstehe soll nach erfolgreicher Installation im Reading das neue Gerät erscheinen, aber wie erstelle ich das alles für einen Shelly 2?
Es wäre schön, wenn Ihr mir da unter die Arme greifen könntet.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: MadMax-FHEM am 03 Dezember 2018, 21:12:36
Bei MQTT etc. kann ich leider nicht helfen...
...aber das Shelly-Modul kennst du?

https://forum.fhem.de/index.php/topic,93251.msg858824.html#msg858824

https://wiki.fhem.de/wiki/Shelly-Aktoren

Gruß, Joachim
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 03 Dezember 2018, 21:16:26
Danke Dir Joachim.

Ja, das habe ich gelesen. Ich habe nur keine Ahnung, ob ich das für MQTT2 brauche oder nicht. Wobei es ja eigentlich nicht schaden kann. Vielleicht komme ich so ein wenig voran. Sitze wieder seit 4 Stunden hier, drehe mich im Kreis, lese immer die gleichen Beiträge und verstehe es nicht.
Wenn ich ja einmal einen Anfang habe, dann bekomme ich es irgendwie hin, wie bei der FS20 Geschihte. Aber das hier ist wieder was ganz neues.
Ich lade das Modul mal.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: MadMax-FHEM am 03 Dezember 2018, 21:22:13
Andersrum oder ganz anders (so wie ich das Wiki gelesen habe):

ENTWEDER das Modul ODER MQTT...
...Vor-/Nachteile siehe Wiki.

Einfacher sieht es mit dem Modul aus, da das nur ein "simpler" define ist und fertig...

EDIT: vielleicht solltest du nicht so viele verschiedene System mischen bzw. nicht schon gleich zu Beginn... ;)  UND: wenn du Geräte unterschiedlicher Systeme/Hersteller verbindest (geht das zwar mit fhem), gehen die Verbindungen NUR wenn fhem läuft und macht was es soll... Daher habe ich für Dinge die zusammengehören, z.B. Licht in einem Raum etc. immer gleiche Systeme die ich dann direkt miteinander verbinde... Maximal nächster Raum oder anderes Szenario wieder ein anderes System...

Gruß, Joachim
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 03 Dezember 2018, 21:27:54
Naja, Shelly war der Grund, warum ich angefangen habe mich hier einzulesen. Durch die lange Lieferzeit und die ganzen Wiki-Beiträge und Anleitungen, kam ich dann darauf, dass meine alten FS20-Kisten ja auch über FHEM funktionieren.
Aber die Shelly's waren der Auslöser.

Dein Tip hat geholfen. Ich sehe jetzt auf jeden Fall etwas.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: rudolfkoenig am 03 Dezember 2018, 21:39:36
Um die urspruengliche Frage zu beantworten:
- die MQTT2_SERVER Definition ist so vollstaendig
- in der (Shelly2) MQTT-Konfiguration muss man den Hostnamen des FHEM Servers und den Port (1883) definieren.
Keine Ahnung, ob/wie das moeglich ist.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: andies am 03 Dezember 2018, 21:44:53
Zitat von: miggun am 03 Dezember 2018, 21:05:34
Wenn ich das richtig verstehe soll nach erfolgreicher Installation im Reading das neue Gerät erscheinen, aber wie erstelle ich das alles für einen Shelly 2?
Es wäre schön, wenn Ihr mir da unter die Arme greifen könntet.
Hast du im shelly den mqtt-server (also deinen fhem-server) eingetragen? Sonst kommunizieren die nicht miteinander.


Gesendet von iPad mit Tapatalk Pro
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 03 Dezember 2018, 22:13:44
Ja, MQTT habe ich im Webfrontend von Shelly aktiviert.
Nur das mit dem kommunizieren will nicht funktionieren.

Es läuft jetzt erst mal über den Hinweis von Joachim, aber MQTT2 wäre natürlich klasse.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: andies am 03 Dezember 2018, 22:14:35
zeig mal screenshots, evtl sind das schreibfehler oder so


Gesendet von iPad mit Tapatalk Pro
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 03 Dezember 2018, 22:21:07
Das ist ein ScreenShot von der Shelly-Weboberfläche

http://prntscr.com/lqaemd (http://prntscr.com/lqaemd)

Und hier von FHEM

http://prntscr.com/lqafe6 (http://prntscr.com/lqafe6)
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: andies am 03 Dezember 2018, 22:29:37
die absicherung mit dem passwort ist nicht die ursache für das Problem?


Gesendet von iPad mit Tapatalk Pro
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: andies am 03 Dezember 2018, 22:30:35

und was sagen log bzw. event monitor?


Gesendet von iPad mit Tapatalk Pro
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 03 Dezember 2018, 22:33:31
Eventmonito bringt alle 20 Sekunden den Messwert, den ich über das Modul eingerichtet habe.
Ich lösche das Passwort mal, gute Idee.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: andies am 04 Dezember 2018, 07:18:06
lösch auch mal den usernamen. Aber wenn da was im eventmonitor erscheint, dann liest der server ein.

Ist autocreate=on?


Gesendet von iPad mit Tapatalk Pro
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 07:30:24
Autocreate ist aktiv
Der lässt mich Username und Passwort nicht löschen. Kann doch nicht sein, dass ich da jetzt nen Reset machen muss, oder?


Raspberry Pi 3 B+
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: rudolfkoenig am 04 Dezember 2018, 07:46:40
ZitatDer lässt mich Username und Passwort nicht löschen. Kann doch nicht sein, dass ich da jetzt nen Reset machen muss, oder?
Falls fuer die MQTT2_SERVER Instanz kein allowed gesetzt ist, dann ist das gesendete Benutzername/Passwort egal.
Ich wuerde "attr MQTT2_SERVER verbose 5" setzen, und das FHEM-Log ueberwachen. Damit werden alle Verbindungsversuche (auch die abgewiesenen) gemeldet.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 08:28:04
Zitat von: rudolfkoenig am 04 Dezember 2018, 07:46:40
Falls fuer die MQTT2_SERVER Instanz kein allowed gesetzt ist, dann ist das gesendete Benutzername/Passwort egal.
Ich wuerde "attr MQTT2_SERVER verbose 5" setzen, und das FHEM-Log ueberwachen. Damit werden alle Verbindungsversuche (auch die abgewiesenen) gemeldet.

Klasse, danke.

Habe FHEM neu gestartet und bekomme das hier im Log.

    2018.12.04 08:22:26 1: PERL WARNING: Use of uninitialized value $val in concatenation (.) or string at ./FHEM/36_Shelly.pm line 607.
2018.12.04 08:22:32 2: AttrTemplates: got 10 entries   


Das hat aber nichts mit MQTT2 zu tun


Raspberry Pi 3 B+
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: kabanett am 04 Dezember 2018, 08:39:37
Hallo,
ist die IP deines Fhem-Rechner tatsächlich 192.168.33.3 ?
Frage nur weil das 33er Netz im Auslieferungszustand des Shellys verwendet wird.

Gruß
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 09:37:41
Ahhhhhh, danke.....
Das war es.
Manchmal sieht man den Wald vor lauter Bäumen nicht.


Raspberry Pi 3 B+
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 12:02:44
Der Vollständigkeit halber hier das, was der Shelly 2 raus wirft.
Jetzt kommt das Problem, das gute Stück zu bedienen.
Internals:
   CFGFN     
   CID        shellyswitch_32B268
   DEF        shellyswitch_32B268
   DEVICETOPIC MQTT2_shellyswitch_32B268
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 607
   MQTT2_SERVER_TIME 2018-12-04 11:59:30
   MSGCNT     607
   NAME       Kueche_Shelly_Licht_MQTT
   NR         82
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-04 11:59:30   1               off
     2018-12-04 11:43:30   announce_id     shellyswitch-32B268
     2018-12-04 09:50:58   energy          6
     2018-12-04 09:50:58   power           44.25
     2018-12-04 11:59:30   shellies/shellyswitch-32B268/relay/0 off
Attributes:
   IODev      MQTT2_SERVER
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:.* shellies/shellyswitch-32B268/relay/0
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/1:.* 1
shellyswitch_32B268:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
   room       MQTT2_DEVICE
   verbose    3]  Internals:
   CFGFN     
   CID        shellyswitch_32B268
   DEF        shellyswitch_32B268
   DEVICETOPIC MQTT2_shellyswitch_32B268
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 607
   MQTT2_SERVER_TIME 2018-12-04 11:59:30
   MSGCNT     607
   NAME       Kueche_Shelly_Licht_MQTT
   NR         82
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-04 11:59:30   1               off
     2018-12-04 11:43:30   announce_id     shellyswitch-32B268
     2018-12-04 09:50:58   energy          6
     2018-12-04 09:50:58   power           44.25
     2018-12-04 11:59:30   shellies/shellyswitch-32B268/relay/0 off
Attributes:
   IODev      MQTT2_SERVER
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:.* shellies/shellyswitch-32B268/relay/0
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/1:.* 1
shellyswitch_32B268:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
   room       MQTT2_DEVICE
   verbose    3



Raspberry Pi 3 B+
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 04 Dezember 2018, 12:11:04
Aus http://shelly-api-docs.shelly.cloud/

Zitatshellies/shelly1-<deviceid>/relay/0/command accepts on and off and applies accordingly
Probiere es also mal mit (für die RAW-Def):
attr shellyswitch_32B268 setList \
off:noArg    shellies/shellyswitch-32B268/relay/0/command off\
on:noArg     shellies/shellyswitch-32B268/relay/0/command on
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 12:13:39
Klasse, danke.
Probiere ich.
Habe jetzt die Dante Zeit mit dem Mobiltelefon gearbeitet.
Gleich bin ich zu Hause und mache mit dem Rechner weiter.


Raspberry Pi 3 B+
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: andies am 04 Dezember 2018, 13:22:48
Und bitte list- und ähnliche Angaben in Code-Tags. Das sind die Knöpfe mit der Raute #.

Liest sich viel leichter.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 13:47:10
Ups, sollte Code sein. Hatte mich auf dem Handy verklickt.
Geändert.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 15:17:13
Mist.... nächste Problem.
Ich bekomme den echten Status nicht dargestellt. An und Aus zeigt er richtig an, solnge ich nicht extern betätige. Also nehme ich nicht den Status, denn ich geliefert bekomme. Wo bin ich jetzt wieder daneben?

defmod t_Kueche_Hauptlicht MQTT2_DEVICE
attr t_Kueche_Hauptlicht IODev MQTT2_SERVER
attr t_Kueche_Hauptlicht devStateIcon shellies/shellyswitch-32B268/relay/0 ON:li_wht_on shellies/shellyswitch-32B268/relay/0 OFF:li_wht_off
attr t_Kueche_Hauptlicht eventMap on:ON off:OFF
attr t_Kueche_Hauptlicht getList shellies/shellyswitch-32B268/relay/power power\
shellies/shellyswitch-32B268/relay/0 state
attr t_Kueche_Hauptlicht homebridgeMapping On=state,valueOff=Off,valueOn=On,cmdOff=Off,cmdOn=On
attr t_Kueche_Hauptlicht icon li_wht_off
attr t_Kueche_Hauptlicht readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:.* shellies/shellyswitch-32B268/relay/0\
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/1:.* 1\
shellyswitch_32B268:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }\
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power\
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
attr t_Kueche_Hauptlicht room 01_Küche,Homekit,MQTT2_DEVICE
attr t_Kueche_Hauptlicht setList off:noArg shellies/shellyswitch-32B268/relay/0/command off\
on:noArg shellies/shellyswitch-32B268/relay/0/command on
attr t_Kueche_Hauptlicht siriName Hauptlicht
attr t_Kueche_Hauptlicht webCmd on:off
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 04 Dezember 2018, 15:41:26
Schau dir mal die mqtt2-templates an (SuFu ;) ).

Auf den ersten Blick mal Folgendes:
Die eventMap sieht komisch aus (wieso Großschreibung), und devStateIcon enthält Leerzeichen, die m.E. teilweise durch einen Punkt ersetzt werden müßten (Beschäftige dich mit dem Punkt bzw. dessen Bedeutung in Regex...)

Ansonsten solltest du mal den Verkehr auf MQTT-Ebene mitlesen (ich nutze dazu mosquitto_sub - das funktioniert auch mit MQTT2_SERVER) und ggf. mal hier posten, was da hin- und hergeht.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 15:44:01
Ah, mach ich.
eventMap habe ich so aus dem MQTT2 wiki, bin mir aber nicht sicher.
Werde ich aber in klein machen, ist mir auch lieber.
Da werde ich direkt mal rein lesen.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 04 Dezember 2018, 15:51:46
Zum einen steht über dem wiki: needs update...
Zum anderen wäre mir neu, dass da was speziell für den shelly geschrieben wurde ;) . Merke: Es gibt keinen wirklichen Standard, wie die topics und die Messages gebaut sind, jeder Hersteller/jede firmware macht das ein klein wenig anders! Daher der Hinweis, den Verkehr mitzuschneiden.

Das wäre btw ganz sinnvoll, dann könnte dein Shelly2 dann auch als mqtt2-template (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template) Eingang in das Allgemeingut finden ;) . Vielleicht beschäftigst du dich etwas damit und lieferst dann was passendes, das Rudi nur einchecken muß. DAS wäre klasse ;D .
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 15:54:39
Gerade ich. :D :D :D
Beschäftigen ja, aber bevor ich was raus finde, das Ihr noch nicht wisst, bin ich ein ganzes Stück näher an der Rente.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 04 Dezember 2018, 16:03:05
Glaube mir, das lohnt für beide Seiten:

Du lernst was wichtiges über FHEM (wie Readings zustandekommen z.B. und die Darstellung von Devices in FHEMWEB).
Und die Allgemeinheit lernt die Schaltbefehle für einen Shelly2.

Du mußt im wesentlichen nicht viel mehr tun als den Verkehr mitzulesen. Das ist nicht schwierig (z.B. mosquitto_sub -d -h <server-hostname> -t shellies/#; MQTT.fx soll auch einfach sein) , mußt halt einen Weg finden, wie du das am einfachsten exportierst (aus der Kommandozeile ginge Kopieren z.B. mit Markieren und dann Strg+Umschalt+c).

Beim Transfer der Infos auf das Device können dann andere unterstützen, und dann daraus ein template zu machen? Mal sehen, kann auch kein Hexenwerk sein...
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 16:09:26
Das schlimme ist, ich habe den Status ja schon als Anzeige über getList, aber ich bekomme es nicht auf die devStateIcon, also das blöde Icon wechselt die Farbe nicht.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 16:13:14
readingList

attr t_Kueche_Hauptlicht readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:.* shellies/shellyswitch-32B268/relay/0\
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/1:.* 1\
shellyswitch_32B268:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }\
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power\
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy


getlist

attr t_Kueche_Hauptlicht getList shellies/shellyswitch-32B268/relay/power power\
shellies/shellyswitch-32B268/relay/0 state


Das wird auch korrekt angezeigt.
Jetzt bekomme ich es nur nicht auf das devStateIcon.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 04 Dezember 2018, 16:18:30
Lösche/Vergiß erst mal devStateIcon, das brauchst du vermutlich nicht...

Dann schau dir das tasmota-template an:
Zum einen zur eventMap, da ist die Info, die vom Device kommt (dev => ...) einer "Sonderbehandlung" unterzogen. Würde darauf tippen, dass das schon ausreicht ;) .
Sollte das 2 Kanäle haben: Es gibt auch ein template für 2 tasmota-Kanäle ;) Dann müßtest du das Device teilen/kopieren, damit jeder Kanal ein eigenes Device wird und dort dann dasselbe machen (Folge dem Beispiel und versuche zu verstehen, was das template tut!).
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 04 Dezember 2018, 22:12:02
Da shier hat in etlichen Variationen nicht geklappt. Wieder mal 5 Stunden rum. Kopfschmerzen und keinen Schritt weiter.

{ dev=>{ON=>'on',OFF=>'off'} }
funktioniert nicht. In etlichen Variationen probiert.

Event Monitor
2018-12-04 22:08:18 MQTT2_DEVICE Kueche_Hauptlicht shellies/shellyswitch-32B268/relay/0: on

Log File
2018.12.04 22:08:51 4: MQTT2_SERVER_192.168.1.18_53491 shellyswitch-32B268 PUBLISH shellies/shellyswitch-32B268/relay/0:on
2018.12.04 22:08:51 5: MQTT2_SERVER: dispatch autocreate:shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:on


List
   DEVICETOPIC Kueche_Hauptlicht
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 593
   MQTT2_SERVER_TIME 2018-12-04 22:10:51
   MSGCNT     593
   NAME       Kueche_Hauptlicht
   NR         39
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-04 22:10:51   1               on
     2018-12-04 21:19:50   announce_id     shellyswitch-32B268
     2018-12-04 22:10:51   energy          2
     2018-12-04 22:10:51   power           46.50
     2018-12-04 22:10:51   shellies/shellyswitch-32B268/relay/0 on
     2018-12-04 21:59:10   state           off
Attributes:
   IODev      MQTT2_SERVER
   devStateIcon shellies/shellyswitch-32B268/relay/0 on:li_wht_on:off shellies/shellyswitch-32B268/relay/0 off:li_wht_off:on
   eventMap   on:on off:off
   getList    shellies/shellyswitch-32B268/relay/power power
shellies/shellyswitch-32B268/relay/0 state
   icon       li_wht_off
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:.* shellies/shellyswitch-32B268/relay/0
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/1:.* 1
shellyswitch_32B268:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
   room       01_Küche,Homekit,MQTT2_DEVICE
   setList    off:noArg shellies/shellyswitch-32B268/relay/0/command off
on:noArg shellies/shellyswitch-32B268/relay/0/command on
   siriName   Hauptlicht
   webCmd     on:off


Ich weiß nicht mehr weiter. :(
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 07:58:03
Vorab: der Shelly2 hat zwei Relays, daher sollte man im Ergebnis auch 2 Devices haben (analog dem tasmota-2ch-template). Wir sehen uns erst mal nur das erste an, einverstanden?

Da du keine Mitschnitte des mqtt-Traffics lieferst: Das Teil scheint den Status des Relays schon mit on bzw. off zu senden?Dann würde ich erst mal _nur_ das hier versuchen:

readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:.* state
Wenn das klappt, schau dir bitte das tasmota-template an und gehe entsprechend für das 2. Device für den 2. Kanal vor.
Titel: Antw:MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 08:22:45
:o :o :o
Das war es schon......
Es funktioniert.......
Nur weil ich beide Kanäle abgefragt habe, gab es kein vernünftiges Ergebnis. Ich ignoriere jetzt mal, wie lange ich daran rumgefummelt habe, ohne zu einem Ergebnis zu kommen.

Vielen, vielen Dank.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 08:47:55
...du bist uns noch 3 templates schuldig :P ...

(shelly1, shelly2 und shelly4)

Liefere bitte dazu erst mal die lists von den beiden 2-er Devices, wenn du die fertig hast.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 08:49:17
Vielen Dank an Beta-User.

Hier jetzt mal die funktionierenden Auszüge von beiden Kanälen. Shelly4 und Shelly1 sind noch nicht ausgepackt. Wollte erst einen hin bekommen.

Kanal 0
Internals:
   DEVICETOPIC Kueche_Hauptlicht
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 105
   MQTT2_SERVER_TIME 2018-12-05 08:47:15
   MSGCNT     105
   NAME       Kueche_Hauptlicht
   NR         36
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-05 08:20:07   1               on
     2018-12-05 08:31:45   announce_id     shellyswitch-32B268
     2018-12-05 08:47:15   energy          3
     2018-12-05 08:47:15   power           3.51
     2018-12-05 08:19:37   shellies/shellyswitch-32B268/relay/0 off
     2018-12-05 08:47:15   state           off
Attributes:
   IODev      MQTT2_SERVER
   devStateIcon shellies/shellyswitch-32B268/relay/0 on:li_wht_on:off shellies/shellyswitch-32B268/relay/0 off:li_wht_off:on
   eventMap   on:on off:off
   getList    shellies/shellyswitch-32B268/relay/power power
shellies/shellyswitch-32B268/relay/0 state
   icon       li_wht_off
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:.* state
shellyswitch_32B268:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
   room       01_Küche,Homekit,MQTT2_DEVICE
   setList    off:noArg shellies/shellyswitch-32B268/relay/0/command off
on:noArg shellies/shellyswitch-32B268/relay/0/command on
   siriName   Hauptlicht
   webCmd     on:off


Kanal 1
Internals:
   CID        shellyswitch-32B268
   DEF        shellyswitch-32B268
   DEVICETOPIC t_Kueche_Eckbank
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 112
   MQTT2_SERVER_TIME 2018-12-05 08:48:45
   MSGCNT     112
   NAME       Kueche_Eckbank
   NR         38
   STATE      on
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-05 08:29:07   1               on
     2018-12-05 08:31:45   announce_id     shellyswitch-32B268
     2018-12-05 08:48:45   energy          3
     2018-12-05 08:48:45   power           3.49
     2018-12-04 16:29:22   shellies/shellyswitch-32B268/relay/0 off
     2018-12-05 08:48:45   state           on
Attributes:
   IODev      MQTT2_SERVER
   devStateIcon shellies/shellyswitch-32B268/relay/1 on:li_wht_on:off shellies/shellyswitch-32B268/relay/1 off:li_wht_off:on
   eventMap   on:on off:off
   getList    shellies/shellyswitch-32B268/relay/power power
shellies/shellyswitch-32B268/relay/1 state
   icon       li_wht_off
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/1:.* state
shellyswitch_32B268:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
   room       01_Küche,Homekit,MQTT2_DEVICE
   setList    off:noArg shellies/shellyswitch-32B268/relay/1/command off
on:noArg shellies/shellyswitch-32B268/relay/1/command on
   siriName   Eckbank
   webCmd     on:off
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 08:55:50
Schau mal bitte, was du da noch bereinigen kannst.
devStateIcon sollte eigentlich nicht erforderlich sein (bitte testen!), wenn du es dann wieder in Deinem Stil verschönern willst:
devStateIcon on:li_wht_on:off off:li_wht_off:on
Brauchst du state in der getList? Und die EventMap?
Gibt es Power und Energie getrennt für beide Kanäle oder ist das eine Sammelinfo, die dann nur in ein Device gehört (ggf. sogar extra?).
Was ist das mit Announce? Wofür ist das da?
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 09:38:25
evenMap raus, war nicht erforderlich, devStateIcon on:li_wht_on off:li_wht_off modifiziert.
Power und Energie ist leider Sammelinfo für beide Kanäle, Müsste ich somit eigentlich extra anlegen. Dafür müsste ich mich damit beschäftigen, wie das genau funktioniert, das auszuwerten.
Um ehrlich zu sein, habe ich keine Ahnung wofür announce ist. Das habe ich so aus der readingList. Ich probier mal, was passiert, wenn es fehlt. Announce habe ich so aus der ReadingList übernommen ohne es zu hinterfragen, aber die Übersetzung bekannt geben klang irgendwie wichtig...ist es aber nicht. Funktioniert auch ohne.
State in der getList ist auch nicht erforderlich.
Jetzt kurz die bereinigten Auszüge, noch mit Power  und Energy, weil ich mich damit jetzt noch beschäftigen muss.

Kanal 0
Internals:
   DEF       
   DEVICETOPIC Kueche_Hauptlicht
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 268
   MQTT2_SERVER_TIME 2018-12-05 09:37:39
   MSGCNT     268
   NAME       Kueche_Hauptlicht
   NR         36
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-05 08:20:07   1               on
     2018-12-05 09:14:38   announce_id     shellyswitch-32B268
     2018-12-05 09:37:39   energy          4
     2018-12-05 09:37:39   power           3.54
     2018-12-05 08:19:37   shellies/shellyswitch-32B268/relay/0 off
     2018-12-05 09:37:39   state           off
Attributes:
   IODev      MQTT2_SERVER
   devStateIcon on:li_wht_on off:li_wht_off
   getList    shellies/shellyswitch-32B268/relay/power power
   icon       li_wht_off
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/0:.* state
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
   room       01_Küche,Homekit,MQTT2_DEVICE
   setList    off:noArg shellies/shellyswitch-32B268/relay/0/command off
on:noArg shellies/shellyswitch-32B268/relay/0/command on
   siriName   Hauptlicht
   webCmd     on:off


Kanal 1
Internals:
   CID        shellyswitch-32B268
   DEF        shellyswitch-32B268
   DEVICETOPIC Kueche_Eckbank
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 263
   MQTT2_SERVER_TIME 2018-12-05 09:37:09
   MSGCNT     263
   NAME       Kueche_Eckbank
   NR         38
   STATE      on
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-05 08:29:07   1               on
     2018-12-05 09:14:38   announce_id     shellyswitch-32B268
     2018-12-05 09:37:09   energy          4
     2018-12-05 09:37:09   power           3.58
     2018-12-04 16:29:22   shellies/shellyswitch-32B268/relay/0 off
     2018-12-05 09:37:09   state           on
Attributes:
   IODev      MQTT2_SERVER
   devStateIcon on:li_wht_on  off:li_wht_off
   getList    shellies/shellyswitch-32B268/relay/power power
   icon       li_wht_off
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/1:.* state
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
   room       01_Küche,Homekit,MQTT2_DEVICE
   setList    off:noArg shellies/shellyswitch-32B268/relay/1/command off
on:noArg shellies/shellyswitch-32B268/relay/1/command on
   siriName   Eckbank
   webCmd     on:off


Edit:

So, jetzt mal Arbeit und Leistung separat.

Internals:
   CID        shellyswitch-32B268
   DEF        shellyswitch-32B268
   DEVICETOPIC Kueche_Licht_Leistung
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 1
   MQTT2_SERVER_TIME 2018-12-05 10:16:47
   MSGCNT     1
   NAME       Kueche_Licht_Leistung
   NR         42
   STATE      3.55
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-05 10:16:47   power           3.55
Attributes:
   IODev      MQTT2_SERVER
   getList    shellies/shellyswitch-32B268/relay/power power
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
   room       01_Küche,MQTT2_DEVICE


Internals:
   CID        shellyswitch-32B268
   DEF        shellyswitch-32B268
   DEVICETOPIC Kueche_Licht_Energie
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 1
   MQTT2_SERVER_TIME 2018-12-05 10:16:47
   MSGCNT     1
   NAME       Kueche_Licht_Energie
   NR         39
   STATE      4
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-05 10:16:47   energy          4
Attributes:
   IODev      MQTT2_SERVER
   getList    shellies/shellyswitch-32B268/relay/energy energy
   readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/energy:.* energy
   room       01_Küche,MQTT2_DEVICE


Jetzt kommt nur die große Frage, warum geht Power nicht auf 0, wenn das Licht aus ist. Er speichert den letzten Wert, sobald er nichts neues bekommt.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 10:59:44
Kannst du mal folgendes tun:
Die beiden Devices löschen (die Raw-Def hast du ja für Notfälle hier), save&update, dann in /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template (am Ende) einfügen (z.B. mit mcedit aus dem Paket mc ;) ):
# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
attr DEVICE setList\
  off:noArg shellies/DEVICE/relay/0/command off
  on:noArg shellies/DEVICE/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVICE/relay/1/command off
  on:noArg shellies/DEVICE/relay/1/command on
deleteattr DEVICE_CH2 getList


Anschließend FHEM neu starten, und dann mal über das Web-Interface am Shelly selbst einen Schaltvorgang auslösen (unterstellt, autocreate am MQTT2-Server ist an).

Es sollte ein MQTT2-DEVICE angelegt werden (mit Namen und der CID shellyswitch-32B268). Auf dieses dann ein set shellyswitch-32B268 attrTemplate shelly2 ausführen...

Danach sollten 2 Devices vorhanden sein, die sich bedienen lassen und dann auch die richtigen settings haben? (Natürlich noch keine Verschönerungen, aber das ist dann nicht Gegenstand des template :) .)
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 11:13:59
Jetzt ist etwas schief gelaufen. :o
Ich kann Fhem nicht mehr aufrufen.

service fhem status
● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: ena
   Active: activating (start) since Wed 2018-12-05 11:16:33 CET; 664ms ago
Main PID: 943 (code=exited, status=1/FAILURE); Control PID: 945 (perl)
   CGroup: /system.slice/fhem.service
           └─945 /usr/bin/perl fhem.pl fhem.cfg

Dez 05 11:16:33 raspberrypi systemd[1]: Starting FHEM Home Automation...
lines 1-8/8 (END)
● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
   Active: activating (start) since Wed 2018-12-05 11:16:33 CET; 664ms ago
Main PID: 943 (code=exited, status=1/FAILURE); Control PID: 945 (perl)
   CGroup: /system.slice/fhem.service
           └─945 /usr/bin/perl fhem.pl fhem.cfg

Dez 05 11:16:33 raspberrypi systemd[1]: Starting FHEM Home Automation...
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: dkreutz am 05 Dezember 2018, 11:16:28
Zitat von: miggun am 05 Dezember 2018, 09:38:25
Jetzt kommt nur die große Frage, warum geht Power nicht auf 0, wenn das Licht aus ist. Er speichert den letzten Wert, sobald er nichts neues bekommt.
Das ist meines Wissens nach ein Fehler in der Shelly2-Firmware (bei ShellyPlug funktioniert das sauber)
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 11:21:25
Zitat von: miggun am 05 Dezember 2018, 11:13:59
Jetzt ist etwas schief gelaufen. :o
Ich kann Fhem nicht mehr aufrufen.
...Nicht gut...

Dann bitte mal im FHEM-log nachsehen, was er nicht mag.
Steht da nichts nachvollziehbares, prüfe als erstes die Rechte an der template-file, ggf. müssen wir als erstes da die Änderungen rückgängig machen.

Dann sehen wir weiter, weitere Hilfestellung ggf. von hier: https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 11:28:57
ps ax | grep perl
1160 ?        Rs     0:00 /usr/bin/perl fhem.pl fhem.cfg
1162 pts/0    S+     0:00 grep --color=auto perl


1282 fhem      20   0    9492   6056   3672 R   8,9  0,6   0:00.27 perl
   99 root      20   0   12792   5280   4872 S   0,7  0,6   0:02.79 systemd-jo+
1262 pi        20   0    8512   3288   2824 R   0,7  0,3   0:00.25 top
    1 root      20   0   27044   6096   4932 S   0,3  0,6   0:05.48 systemd
    8 root      20   0       0      0      0 I   0,3  0,0   0:00.94 rcu_sched
  295 root      20   0    7380   4160   3760 S   0,3  0,4   0:00.54 systemd-lo+
  297 message+  20   0    6492   3384   3012 S   0,3  0,4   0:01.62 dbus-daemon
  322 avahi     20   0    6536   2828   2520 S   0,3  0,3   0:00.56 avahi-daem+
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kthreadd
    4 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 kworker/0:+
    6 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 mm_percpu_+
    7 root      20   0       0      0      0 S   0,0  0,0   0:00.03 ksoftirqd/0
    9 root      20   0       0      0      0 I   0,0  0,0   0:00.00 rcu_bh
   10 root      rt   0       0      0      0 S   0,0  0,0   0:00.01 migration/0
   11 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/0
   12 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/1
   13 root      rt   0       0      0      0 S   0,0  0,0   0:00.03 migration/1
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 11:34:04
Hmm, also FHEM läuft, es scheint "nur" FHEMWEB betroffen zu sein.

Steht was im FHEM-log bzw. ist da was mit starting USB-irgendwas?

Dann mal alles abstöpseln, was USB ist, warten und dann bitte "delete initialUsbCheck" (oder disable).

Ansonsten FHEM beenden und die beiden Devices nochmal löschen (bzw., wenn du noch nicht dazu gekommen sein sollte, liegt es nicht daran....)
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 11:35:31
USB habe ich nichts dran, war auch schon auf disable
service fhem status
● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: ena
   Active: activating (start) since Wed 2018-12-05 11:36:39 CET; 814ms ago
Main PID: 825 (code=exited, status=1/FAILURE); Control PID: 827 (perl)
   CGroup: /system.slice/fhem.service
           └─827 /usr/bin/perl fhem.pl fhem.cfg

Dez 05 11:36:39 raspberrypi systemd[1]: Starting FHEM Home Automation...


Wie komme ich an das FHEM-Log ohne FHEM Web
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 11:43:46
ssh...

die logs liegen in /opt/fhem/log (meine ich; jedenfalls irgendwo im FHEM-Verzeichnis)
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 11:44:21
Gefunden

perl fhem.pl -d fhem.cfg
2018.12.05 11:43:41 5: Loading ./FHEM/99_FHEMControlPush.pm
2018.12.05 11:43:41 5: Loading ./FHEM/99_SUNRISE_EL.pm
2018.12.05 11:43:41 5: Loading ./FHEM/99_Utils.pm
2018.12.05 11:43:41 5: Initializing Type Library:
2018.12.05 11:43:41 1: Including fhem.cfg
2018.12.05 11:43:41 5: Cmd: >attr global userattr cmdIcon devStateIcon devStateStyle genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock homebridgeMapping:textField-long icon siriName sortby webCmd webCmdLabel:textField-long widgetOverride<
2018.12.05 11:43:41 5: Cmd: >attr global autoload_undefined_devices 1<
2018.12.05 11:43:41 5: Cmd: >attr global autosave 0<
2018.12.05 11:43:41 5: Cmd: >attr global logfile ./log/fhem-%Y-%m.log<
2018.12.05 11:43:41 5: Cmd: >attr global modpath .<
2018.12.05 11:43:41 5: Cmd: >attr global motd SecurityCheck:
  WEB is not password protected
  MQTT2_SERVER is not password protected
  tPort is not password protected

Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none<
2018.12.05 11:43:41 5: Cmd: >attr global statefile ./log/fhem.save<
2018.12.05 11:43:41 5: Cmd: >attr global verbose 3<
2018.12.05 11:43:41 5: Cmd: >define WEB FHEMWEB 8083 global<
2018.12.05 11:43:41 5: Loading ./FHEM/01_FHEMWEB.pm
2018.12.05 11:43:42 3: WEB: port 8083 opened
2018.12.05 11:43:42 5: Cmd: >attr WEB editConfig 1<
2018.12.05 11:43:42 5: Cmd: >define Logfile FileLog ./log/fhem-%Y-%m.log fakelog<
2018.12.05 11:43:42 5: Loading ./FHEM/92_FileLog.pm
2018.12.05 11:43:42 1: define Logfile FileLog ./log/fhem-%Y-%m.log fakelog: Can't open ./log/fhem-2018-12.log: Permission denied
2018.12.05 11:43:42 5: fhem.cfg line 20 returned >Can't open ./log/fhem-2018-12.log: Permission denied<
2018.12.05 11:43:42 5: Cmd: >define autocreate autocreate<
2018.12.05 11:43:42 5: Loading ./FHEM/98_autocreate.pm
2018.12.05 11:43:42 5: Cmd: >attr autocreate filelog ./log/%NAME-%Y.log<
2018.12.05 11:43:42 5: Cmd: >define eventTypes eventTypes ./log/eventTypes.txt<
2018.12.05 11:43:42 5: Loading ./FHEM/91_eventTypes.pm
2018.12.05 11:43:42 2: eventTypes: loaded 196 events from ./log/eventTypes.txt
2018.12.05 11:43:42 5: Cmd: >define initialUsbCheck notify global:INITIALIZED usb create<
2018.12.05 11:43:42 5: Loading ./FHEM/91_notify.pm
2018.12.05 11:43:42 5: Cmd: >attr initialUsbCheck disable 1<
2018.12.05 11:43:42 5: Cmd: >define tPort telnet 7072 global<
2018.12.05 11:43:42 5: Loading ./FHEM/98_telnet.pm
2018.12.05 11:43:42 3: tPort: port 7072 opened
2018.12.05 11:43:42 5: Cmd: >define siri siri<
2018.12.05 11:43:42 5: Loading ./FHEM/39_siri.pm
2018.12.05 11:43:42 5: Cmd: >define nRestartHomebridge notify global:INITIALIZED set homebridge restart<
2018.12.05 11:43:42 5: Cmd: >define homebridge serviced homebridge<
2018.12.05 11:43:42 5: Loading ./FHEM/98_serviced.pm
2018.12.05 11:43:42 5: Cmd: >attr homebridge alias Service homebridge<
2018.12.05 11:43:42 5: Cmd: >attr homebridge cmdIcon restart:rc_REPEAT stop:rc_STOP status:rc_INFO start:rc_PLAY<
2018.12.05 11:43:42 5: Cmd: >attr homebridge devStateIcon Initialized|status:light_question error|failed:light_exclamation running:audio_play:stop stopped:audio_stop:start stopping:audio_stop .*starting:audio_repeat<
2018.12.05 11:43:42 5: Cmd: >attr homebridge genericDeviceType switch<
2018.12.05 11:43:42 5: Cmd: >attr homebridge homebridgeMapping On=state,valueOff=/stopped|failed/,cmdOff=stop,cmdOn=start
StatusJammed=state,values=/error|failed/:JAMMED;/.*/:NOT_JAMMED<
2018.12.05 11:43:42 5: Cmd: >attr homebridge icon hue_room_garage<
2018.12.05 11:43:42 5: Cmd: >attr homebridge room Services<
2018.12.05 11:43:42 5: Cmd: >attr homebridge webCmd start:restart:stop:status<
2018.12.05 11:43:42 5: Cmd: >define MapleCUN1 CUL 192.168.1.8:2323 0000<
2018.12.05 11:43:42 5: Loading ./FHEM/00_CUL.pm
2018.12.05 11:43:42 3: Opening MapleCUN1 device 192.168.1.8:2323
2018.12.05 11:43:43 5: SW: V
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) MapleCUNx4_8F (F-Band: 868MHz)

2018.12.05 11:43:43 5: SW: ?
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *

2018.12.05 11:43:43 3: MapleCUN1: Possible commands: BbCFiAZNEkGMKLUYRTVWXeflptxz*
2018.12.05 11:43:43 5: SW: X21
2018.12.05 11:43:43 5: SW: T01
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): 0000

2018.12.05 11:43:43 5: GOT CUL fhtid: 0000
2018.12.05 11:43:43 3: MapleCUN1 device opened
2018.12.05 11:43:43 5: Cmd: >attr MapleCUN1 rfmode SlowRF<
2018.12.05 11:43:43 5: Cmd: >define MapleCUN2 STACKABLE_CC MapleCUN1<
2018.12.05 11:43:43 5: Loading ./FHEM/16_STACKABLE_CC.pm
2018.12.05 11:43:43 5: SW: *V
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): *V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) MapleCUNx4_8F (F-Band: 433MHz)

2018.12.05 11:43:43 5: SW: *?
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): *? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f x z *

2018.12.05 11:43:43 3: MapleCUN2: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.12.05 11:43:43 5: SW: *X21
2018.12.05 11:43:43 5: Cmd: >define MapleCUN3 STACKABLE_CC MapleCUN2<
2018.12.05 11:43:43 5: SW: **V
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): **V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) MapleCUNx4_8F (F-Band: 868MHz)

2018.12.05 11:43:43 5: SW: **?
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): **? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f x z *

2018.12.05 11:43:43 3: MapleCUN3: Possible commands: bCFiAZNEGMKLUYRTVWXfxz*
2018.12.05 11:43:43 5: SW: **X21
2018.12.05 11:43:43 5: Cmd: >define MapleCUN4 STACKABLE_CC MapleCUN3<
2018.12.05 11:43:43 5: SW: ***V
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): ***V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) MapleCUNx4_8F (F-Band: 868MHz)

2018.12.05 11:43:43 5: SW: ***?
2018.12.05 11:43:43 5: CUL/RAW (ReadAnswer): ***? (? is unknown) Use one of C A Z N E L Y V X f z

2018.12.05 11:43:43 3: MapleCUN4: Possible commands: CAZNELYVXfz
2018.12.05 11:43:43 5: SW: ***X21
2018.12.05 11:43:43 5: Cmd: >define au_Hallentor FS20 1111 01<
2018.12.05 11:43:43 5: Loading ./FHEM/10_FS20.pm
2018.12.05 11:43:43 5: Cmd: >attr au_Hallentor IODev MapleCUN1<
2018.12.05 11:43:43 5: Cmd: >attr au_Hallentor devStateIcon on:fts_garage_door_10@red off:fts_garage_door_100@green<
2018.12.05 11:43:43 5: Cmd: >attr au_Hallentor genericDeviceType GarageDoorOpener<
2018.12.05 11:43:43 5: Cmd: >attr au_Hallentor icon fts_garage<
2018.12.05 11:43:43 5: Cmd: >attr au_Hallentor room FS20<
2018.12.05 11:43:43 5: Cmd: >define FileLog_au_Hallentor FileLog ./log/au_Hallentor-%Y.log au_Hallentor<
2018.12.05 11:43:43 1: define FileLog_au_Hallentor FileLog ./log/au_Hallentor-%Y.log au_Hallentor: Can't open ./log/au_Hallentor-2018.log: Permission denied
2018.12.05 11:43:43 5: fhem.cfg line 54 returned >Can't open ./log/au_Hallentor-2018.log: Permission denied<
2018.12.05 11:43:43 5: Cmd: >attr FileLog_au_Hallentor logtype text<
2018.12.05 11:43:43 5: Cmd: >attr FileLog_au_Hallentor room FS20<
2018.12.05 11:43:43 5: Cmd: >define au_Garagentor FS20 1111 b1<
2018.12.05 11:43:43 5: Cmd: >attr au_Garagentor IODev MapleCUN1<
2018.12.05 11:43:43 5: Cmd: >attr au_Garagentor eventMap /on-for-timer 1:Taster/<
2018.12.05 11:43:43 5: Cmd: >attr au_Garagentor icon fts_garage<
2018.12.05 11:43:43 5: Cmd: >attr au_Garagentor room FS20<
2018.12.05 11:43:43 5: Cmd: >attr au_Garagentor siriName Garagentor<
2018.12.05 11:43:43 5: Cmd: >attr au_Garagentor webCmd Taster<
2018.12.05 11:43:43 5: Cmd: >define FileLog_au_Garagentor FileLog ./log/au_Garagentor-%Y.log au_Garagentor<
2018.12.05 11:43:43 1: define FileLog_au_Garagentor FileLog ./log/au_Garagentor-%Y.log au_Garagentor: Can't open ./log/au_Garagentor-2018.log: Permission denied
2018.12.05 11:43:43 5: fhem.cfg line 64 returned >Can't open ./log/au_Garagentor-2018.log: Permission denied<
2018.12.05 11:43:43 5: Cmd: >attr FileLog_au_Garagentor logtype text<
2018.12.05 11:43:43 5: Cmd: >attr FileLog_au_Garagentor room FS20<
2018.12.05 11:43:43 5: Cmd: >define Hallentor dummy<
2018.12.05 11:43:43 5: Loading ./FHEM/98_dummy.pm
2018.12.05 11:43:43 5: Cmd: >attr Hallentor genericDeviceType switch<
2018.12.05 11:43:43 5: Cmd: >attr Hallentor homebridgeMapping On=state,valueOff=off,valueOn=on,cmdOff=off,cmdOn=on<
2018.12.05 11:43:43 5: Cmd: >attr Hallentor icon fts_garage<
2018.12.05 11:43:43 5: Cmd: >attr Hallentor room Homekit<
2018.12.05 11:43:43 5: Cmd: >attr Hallentor webCmd on:off<
2018.12.05 11:43:43 5: Cmd: >define n_Hallentor_a notify Hallentor:on set au_Hallentor on<
2018.12.05 11:43:43 5: Cmd: >define n_Hallentor_z notify Hallentor:off set au_Hallentor off<
2018.12.05 11:43:43 5: Cmd: >define CUL_WS_8 CUL_WS 8<
2018.12.05 11:43:43 5: Loading ./FHEM/14_CUL_WS.pm
2018.12.05 11:43:43 5: Cmd: >attr CUL_WS_8 room CUL_WS<
2018.12.05 11:43:43 5: Cmd: >define FileLog_CUL_WS_8 FileLog ./log/CUL_WS_8-%Y.log CUL_WS_8:T:.*<
2018.12.05 11:43:43 1: define FileLog_CUL_WS_8 FileLog ./log/CUL_WS_8-%Y.log CUL_WS_8:T:.*: Can't open ./log/CUL_WS_8-2018.log: Permission denied
2018.12.05 11:43:43 5: fhem.cfg line 77 returned >Can't open ./log/CUL_WS_8-2018.log: Permission denied<
2018.12.05 11:43:43 5: Cmd: >attr FileLog_CUL_WS_8 logtype temp4hum6:Temp/Hum,text<
2018.12.05 11:43:43 5: Cmd: >attr FileLog_CUL_WS_8 room CUL_WS<
2018.12.05 11:43:43 5: Cmd: >define SVG_CUL_WS_8 SVG FileLog_CUL_WS_8:SVG_CUL_WS_8:CURRENT<
2018.12.05 11:43:43 5: Loading ./FHEM/98_SVG.pm
2018.12.05 11:43:43 5: Cmd: >attr SVG_CUL_WS_8 label "CUL_WS_8 Min $data{min1}, Max $data{max1}, Last $data{currval1}"<
2018.12.05 11:43:43 5: Cmd: >attr SVG_CUL_WS_8 room Plots<
2018.12.05 11:43:43 5: Cmd: >define Garagentor dummy<
2018.12.05 11:43:43 5: Cmd: >attr Garagentor genericDeviceType GarageDoorOpener<
2018.12.05 11:43:43 5: Cmd: >attr Garagentor homebridgeMapping CurrentDoorState=state,values=closed:CLOSED;open:OPEN;closing:CLOSING;opening:OPENING
attr Garagentor icon fts_garage<
2018.12.05 11:43:43 5: Cmd: >attr Garagentor room Unsorted<
2018.12.05 11:43:43 5: Cmd: >attr Garagentor setList open stop closed<
2018.12.05 11:43:43 5: Cmd: >attr Garagentor webCmd Auf:Stop:Zu<
2018.12.05 11:43:43 5: Cmd: >define Carport dummy<
2018.12.05 11:43:43 5: Cmd: >attr Carport devStateIcon auf:fts_garage_door_10@red zu:fts_garage_door_100@green<
2018.12.05 11:43:43 5: Cmd: >attr Carport event-on-change-reading .*<
2018.12.05 11:43:43 5: Cmd: >attr Carport genericDeviceType GarageDoorOpener<
2018.12.05 11:43:43 5: Cmd: >attr Carport homebridgeMapping CurrentDoorState=state,values=closed:CLOSED;open:OPEN;opening:OPENING;closing:CLOSING\ TargetDoorState=state,cmds=OPEN:auf;CLOSED:zu,values=zu:CLOSED;auf:OPEN<
2018.12.05 11:43:43 5: Cmd: >attr Carport room Homekit<
2018.12.05 11:43:43 5: Cmd: >attr Carport setList auf zu<
2018.12.05 11:43:43 5: Cmd: >attr Carport siriName Carport<
2018.12.05 11:43:43 5: Cmd: >attr Carport webCmd auf:zu<
2018.12.05 11:43:43 5: Cmd: >define MQTT2_SERVER MQTT2_SERVER 1883 global<
2018.12.05 11:43:43 5: Loading ./FHEM/00_MQTT2_SERVER.pm
2018.12.05 11:43:43 1: MQTT2_SERVER: Can't open server port at 1883: Address already in use. Exiting.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 11:48:15
Interessant ist nur die letzte Meldung.
Ist der Mosquitto runter oder läuft der noch (dann bitte Deinstallieren)? Gibt es mehrere MQTT2-Server-Definitionen in der cfg?
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 11:49:32
Ist noch drauf, hatte ich aber gestoppt.
Habe jetzt Mosquitto gestoppt.

Ui, das war das Problem. :o
Jetzt muss ich erst mal lesen, wie ich Mosquitto sauber lösche....das ist sonst Mist.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 11:57:53
Zitat von: Beta-User am 05 Dezember 2018, 10:59:44
Kannst du mal folgendes tun:
Die beiden Devices löschen (die Raw-Def hast du ja für Notfälle hier), save&update, dann in /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template (am Ende) einfügen (z.B. mit mcedit aus dem Paket mc ;) ):
# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
attr DEVICE setList\
  off:noArg shellies/DEVICE/relay/0/command off
  on:noArg shellies/DEVICE/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVICE/relay/1/command off
  on:noArg shellies/DEVICE/relay/1/command on
deleteattr DEVICE_CH2 getList


Anschließend FHEM neu starten, und dann mal über das Web-Interface am Shelly selbst einen Schaltvorgang auslösen (unterstellt, autocreate am MQTT2-Server ist an).

Es sollte ein MQTT2-DEVICE angelegt werden (mit Namen und der CID shellyswitch-32B268). Auf dieses dann ein set shellyswitch-32B268 attrTemplate shelly2 ausführen...

Danach sollten 2 Devices vorhanden sein, die sich bedienen lassen und dann auch die richtigen settings haben? (Natürlich noch keine Verschönerungen, aber das ist dann nicht Gegenstand des template :) .)

In der DropDown Liste fehlt der Shelly2.

Unknown template_entry_name shelly2
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 12:03:52
Zitat von: miggun am 05 Dezember 2018, 11:49:32
Jetzt muss ich erst mal lesen, wie ich Mosquitto sauber lösche....das ist sonst Mist.
apt-get uninstall mosquitto sollte mit den richtigen Rechten helfen; schön, dass wir das bei der Gelegenheit gemerkt haben.

Zitat von: miggun am 05 Dezember 2018, 11:57:53
In der DropDown Liste fehlt der Shelly2.
Die Datei hattest du editiert wie beschrieben? (Rechte passen noch?)
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 12:59:47
Jetzt wieder von der Arbeit mit dem Handy
Die Datei habe ich editiert.
Aber der Sonoff Eintrag, der vorher steht fehlt bei mir auch.
Also ein Rechte-Problem?


Raspberry Pi 3 B+
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 13:08:10
...wenn im svn "mehr" steht als in deinem FHEM, ist was mit dem update schief gegangen, an ein Rechte-Thema glaube ich in dem Fall nicht (du faßt das ja offensichtlich zum ersten Mal an, und das Editieren macht m.E. erst dann Sinn, wenn sonst alles da ist, andernfalls wird ggf. was überschrieben)...

Das sollte bitte zuerst reibungslos durchlaufen, sonst ist das Risiko groß, dass die Dinge nicht zueinander passen. Laß dir Zeit, die Zusammenhänge zu verstehen ;) . Ist sehr wichtig, sonst stehst du beim nächsten Mal ohne Helfer im Regen.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 13:10:21
Mach ich.
Ich fang jetzt erst mal mit Mosquitto an, damit beim nächsten mal kein böses Erwachen hab. Dann weiter mit Updates.


Raspberry Pi 3 B+
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 13:50:20
So Mosquitto erstmal mit

sudo apt-get remove --auto-remove mosquitto

deinstalliert
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 13:59:52
Zitat von: dkreutz am 05 Dezember 2018, 11:16:28
Das ist meines Wissens nach ein Fehler in der Shelly2-Firmware (bei ShellyPlug funktioniert das sauber)

So, jetzt wo alles wieder läuft....
Danke Dir. Gibt es nicht eine Möglichkeit, dass ich sage:
guck auf den Messwertwenn wenn der Status vom relay0 oder relay1 on ist, sobald der Status vom relay0 und relay1 off ist setze den Meßwert auf 0
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 14:07:01
notify auf beide Devices ansetzen (Klammer um beide Devicenamen und | dazwischen), dann prüfen, ob beide Value() der Devices auf "off" sind und wenn ja: Readings setzen ;) .

Beispiel für kombiniertes Event:
define n_Button_3_Weihnachtsbaum notify (Schalter_Spuele_Btn_03|Schalter_WZ1_Btn_02):Short.* set Weihnachtsbaum toggle
Hinweise zur Auswertung mehrerer Devices: https://wiki.fhem.de/wiki/Notify#Einfache_UND_Funktion
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 15:40:50
Dann werde ich den hier mal probieren oder muss ich etwas für Else angeben?

define n_Kueche_Leistung  notify (Kueche_Eckbank|Kueche_Hauptlicht) { my $r1 = Value("Kueche_Eckbank");; my $r2 = Value("Kueche_Hauptlicht");; if ($r1 eq "off" && $r2 eq "off") { fhem("set Kueche_Licht_Leistung 0");; } }
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 15:55:47
Müßte/könnte eher so aussehen (bitte im Event-Monitor das Event abgreifen!; evtl. fehlt ein Punkt nach dem Doppelpunkt):
define n_Kueche_Leistung  notify Kueche_(Eckbank|Hauptlicht):off { my $r1 = Value("Kueche_Eckbank");; my $r2 = Value("Kueche_Hauptlicht");; if ($r1 eq "off" && $r2 eq "off") { fhem("set Kueche_Licht_Leistung 0");; } }

Else ist nicht erforderlich, aber ich würde nicht einen Dummy (?) auf "0" setzen, sondern das Reading an dem "richtigen" Device (hier: Kueche_Eckbank?); imo wird viel zu viel mit Dummys rumgekaspert um irgendwelche Werte zu speichern; das ist völlig unübersichtlich und unnötig).
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 16:12:26
Ich habe so wie Du es angedeutet hast, aus der Leistung ein eigenes Device gemacht und wollte da direkt den Wert setzen. Ich wollte versuchen, so wie es oft empfohlen wird, ohne Dummys auszukommen.

Kueche_Licht_Leistung ist also ein eigenes Device.
Titel: [Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 17:18:21
Funktioniert nicht.

ich müsste mal per Hand probieren, wie ich den Wert auf 0 setzen kann. 2x off registriert er, setzt aber keinen Wert. ImEvent LogFile kommt:

    2018.12.05 17:17:25 3: n_Kueche_Leistung return value: Unknown argument 0, choose one of attrTemplate:tasmota_1channel,tasmota_2channel,tasmota_basic,zigbee2mqtt_bridge,zigbee2mqtt_bulb,zigbee2mqtt_colorbulb,
zigbee2mqtt_colorbulbWithoutColorTemp,zigbee2mqtt_hueMotionSensor,zigbee2mqtt_smart+plug,zigbee2mqtt_smokeDetector
Titel: [Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 17:46:42
So, das ganze funktioniert jetzt auch.
Vielen Dank für die großartige Hilfe.

Mit setSTATE konnte ich das ganze manuell auf 0 setzen, somit habe ich das in den Code eingesetzt und es funktioniert.
Hier der funktionierende Auszug.

Internals:
   CFGFN     
   DEF        Kueche_(Eckbank|Hauptlicht):off { my $r1 = Value("Kueche_Eckbank"); my $r2 = Value("Kueche_Hauptlicht"); if ($r1 eq "off" && $r2 eq "off") { fhem("setSTATE Kueche_Licht_Leistung 0"); } }
   NAME       n_Kueche_Leistung
   NR         542
   NTFY_ORDER 50-n_Kueche_Leistung
   REGEXP     Kueche_(Eckbank|Hauptlicht):off
   STATE      2018-12-05 17:48:25
   TRIGGERTIME 1544028505.96072
   TYPE       notify
   READINGS:
     2018-12-05 17:30:31   state           active
Attributes:
Titel: [Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 17:58:22
Da der Wert sich so nicht von selbst aktualisiert, das ganze mit setReading probiert, jetzt ist es perfekt.
Internals:
   CFGFN     
   DEF        Kueche_(Eckbank|Hauptlicht):off { my $r1 = Value("Kueche_Eckbank"); my $r2 = Value("Kueche_Hauptlicht"); if ($r1 eq "off" && $r2 eq "off") { fhem("setReading Kueche_Licht_Leistung power 0"); } }
   NAME       n_Kueche_Leistung
   NR         542
   NTFY_ORDER 50-n_Kueche_Leistung
   REGEXP     Kueche_(Eckbank|Hauptlicht):off
   STATE      2018-12-05 17:59:56
   TRIGGERTIME 1544029196.0451
   TYPE       notify
   READINGS:
     2018-12-05 17:56:44   state           active
Attributes:
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 05 Dezember 2018, 18:55:37
Danke für's Feedback!

Bekommt der shelly so dann auch die Anweisung, sich zurückzusetzen, oder kommt dann wieder ein Summenwert zurück?

Konntest du das mit dem template mal testen (sollte auch für den shelly4 bzw. die ersten beiden Relays dort) passen...)? Braucht es noch einen setList-Eintrag für power zum Zurücksetzen?
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 19:06:58
Das mit dem Template muss ich mir zu Hause angucken, habe jetzt alles mit dem Mobiltelefon eingestellt. Aber ist mit dem Handy echt üble fummelei.
Noch sehe ich das Template nicht in Fhem, ich muss jetzt also gucken, warum nicht. Den Sonoff, der davor steht seh ich auch nicht.

Ja, die Anweisung wieder einen Messwert zu setzen funktioniert perfekt. Sobald ein Lichtkreis eingeht, habe ich wieder den Messwert drin. Echt super.

Vielen, vielen Dank. Ohne Deine Hilfe hätte ich es nicht hin bekommen.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 05 Dezember 2018, 22:19:42
Shelly4Pro und Shelly1 sind jetzt auch da.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 06 Dezember 2018, 11:39:37
So Shelly4Pro angeschlossen.
Negativ:
Das Teil ist zum Einbau in eine Verteilung, kann aber nicht auf Rollladenbetrieb umgestellt werden.
Es hängt in einer Verteilung, aber man kann alle 4 Kontakte nur einem Raum zuweisen
Das betrifft natürlich nur die Shelly-App oder deren Web-Zugang. Über FHEM interessiert das ja nicht.

Auslesen der Messwerte je Ausgang unterscheidet sich leicht vom Shelly 2, da man beim Shelly4Pro alle 4 Ausgänge einzelnd auslesen kann. Sonst alles wie beim Shelly2

Leistung (hier setzt die sich, anders als beim Shelly2, auch von allein auf 0):

Internals:
   CFGFN     
   CID        shelly4pro-062065
   DEF        shelly4pro-062065
   DEVICETOPIC Flur_Licht_Leistung
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 13
   MQTT2_SERVER_TIME 2018-12-06 06:52:17
   MSGCNT     13
   NAME       Flur_Licht_Leistung
   NR         968
   STATE      0.00
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-06 06:52:17   power           0.00
Attributes:
   IODev      MQTT2_SERVER
   getList    shellies/shelly4pro-062065/relay/0/power power
   readingList shelly4pro_062065:shellies/shelly4pro-062065/relay/0/power:.* power
   room       02_Flur,MQTT2_DEVICE,Messwerte
   stateFormat power



Arbeit:

Internals:
   CFGFN     
   CID        shelly4pro-062065
   DEF        shelly4pro-062065
   DEVICETOPIC Flur_Licht_Energie
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 4
   MQTT2_SERVER_TIME 2018-12-05 22:47:24
   MSGCNT     4
   NAME       Flur_Licht_Energie
   NR         982
   STATE      1
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-05 22:47:24   energy          1
Attributes:
   IODev      MQTT2_SERVER
   getList    shelly4pro_062065:shellies/shelly4pro-062065/relay/0/energy energy
   readingList shelly4pro_062065:shellies/shelly4pro-062065/relay/0/energy:.* energy
   room       Messwerte,02_Flur,MQTT2_DEVICE
   stateFormat energy
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 06 Dezember 2018, 11:46:48
Zu den MQTT2 Templates, ich weiß nicht wirklich, warum ich die anderen nicht sehe.

(https://uploads.tapatalk-cdn.com/20181206/ab3470a5fbbe483aab9c9514d76d13d3.jpg)


Raspberry Pi 3 B+
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 06 Dezember 2018, 11:50:08
Es steht jetzt (sortiert) drin, was im standard-template steht. Sieht für mich "normal" aus...

Hattest du die Zeilen aus meinem Post dort eingefügt und (weiß nicht, ob das erforderlich ist) danach FHEM neu gestartet? (update hätte es evtl. wieder gelöscht!)
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 06 Dezember 2018, 11:58:14
Ähm, ja..ich habe ein Fhem Update und RasPi Update gemacht. Das würde es erklären.
Jetzt guck ich aber mal, ob das noch drin steht.


War wirklich weg. :O

Jetzt wieder drin und siehe da, der Shelly2 ist in der DropDown-Liste.
Klasse, vielen Dank.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 06 Dezember 2018, 12:09:51
...was mich jetzt eigentlich und vor allem interessieren würde:
Funktioniert das so wie gedacht oder nicht?!?

Kannst ja ggf. den 4-er-Shelly zum Testen nehmen. Dass da dann was fehlt mit power usw. ist klar, geht v.a. um's grundlegende - wenn das steht, darfst du dir überlegen, wie dann das Gesamtpaket für deine 4 Shelly-Typen aussehen müßte ;) .


Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: rudolfkoenig am 06 Dezember 2018, 12:51:07
Wenn ich den shelly2 AttrTemplate Vorschlag richtig verstehe, muss man vorher die automatisch angelegte MQTT2_DEVICE Instanz passend zum Shelly2-MQTT-Namen umbenannt haben.
Lieber waere mir das Setzen dieses Wertes aus dem (hoffentlich) automatisch angelegten readingList per AttrTemplate Parameter:name:shelly2
filter:TYPE=MQTT2_DEVICE
par:SHELLY2;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/SHELLY2/relay/0/command off
  on:noArg shellies/SHELLY2/relay/0/command on
...
Weiterhin wuerde ich readingList automatisch anlegen lassen, und nicht explizit spezifizieren (und damit das vorher automatisch Angelegte entfernen)

Die AttrTemplate Dateien kann man auch ohne Neustart einlesen mit
{ AttrTemplate_Initialize() }

Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 06 Dezember 2018, 13:00:58
@Rudi
Danke für den Schubser, ist natürlich sinnvoll :) !
Da du mitliest, brauchen wir auch keinen neuen Thread, wenn wir denn endlich mal soweit sind...

@miggun
Kannst du den Thread bitte verschieben nach MQTT?
(Beim ersten Beitrag ist ein Knopf dafür)
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 06 Dezember 2018, 18:08:16
Noch mal ein paar Info's von der Website des Herstellers:


Shelly2
http://shelly-api-docs.shelly.cloud/#shelly2-mqtt (http://shelly-api-docs.shelly.cloud/#shelly2-mqtt)
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 06 Dezember 2018, 19:19:19
Zitat von: miggun am 06 Dezember 2018, 18:08:16
Noch mal ein paar Info's von der Website des Herstellers:


Shelly2
http://shelly-api-docs.shelly.cloud/#shelly2-mqtt (http://shelly-api-docs.shelly.cloud/#shelly2-mqtt)
Damit bist du uns jetzt geprüfte templates schuldig für shelly1, shelly2 im "normalen" mode, shelly2 im "roller" mode und shelly4pro :P
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 06 Dezember 2018, 19:27:22
Ähh, wer, ich???
Ich habe doch keine Ahnung.

Für die Rolladen werde ich den Shelly4Pro verwenden, weil der in der Verteilung hängt. Da wird der eine Theben DCF-Zeitschaltuhr abgelöst.
Steuern werde ich das ganze dann über sunset und sunrise plus Offset lösen. Hoffentlich bekomme ich das diesmal ohne Hilfe hin.
Werde das ganze natürlich mit Euch teilen, wenn es funktioniert.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 06 Dezember 2018, 19:34:58
Zitat von: miggun am 06 Dezember 2018, 19:27:22
Ähh, wer, ich???
Ich habe doch keine Ahnung.
Ja wer denn sonst?!?

Ich habe keinen der shelly daliegen, und selbst wenn Rudi alles hätte, könntest du ihm (und allen shelly-mqtt-Interessierten gleich mit) helfen!

Also erst mal das vorhandene template für shelly2 nehmen, die Anregung von Rudi aufgreifen, reload durchführen und dann (nach einem Backup der bestehenden Konfiguration) das template anwenden, berichten und den fertigen Code posten.

Dann versuchst du es mit dem shelly1 nach ganz genau demselben Muster vorzugehen...

Dann den shelly4pro (im Normalbetrieb). Da muß nur das deleteattr raus und das entsprechende attr aus dem 1. 2-er geändert werden + das ganze dann erweitert auf 4 Kanäle.

Zum Schluß wird dir dann der roller-Modus leicht fallen!

Just do it!
Have fun...
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 06 Dezember 2018, 21:50:58
Passt das so für mqtt2.template?

# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
par:SHELLY2;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/SHELLY2/relay/0/command off
  on:noArg shellies/SHELLY2/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVICE/relay/1/command off
  on:noArg shellies/DEVICE/relay/1/command on
deleteattr DEVICE_CH2 getList


# shelly4pro using original firmware
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:SHELLY4PRO;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/SHELLY4PRO/relay/0/command off
  on:noArg shellies/SHELLY4PRO/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/0/power power \
  shellies/DEVICE/relay/0/energy energy
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/SHELLY4PRO/relay/1/command off
  on:noArg shellies/SHELLY4PRO/relay/1/command on
attr DEVICE getList shellies/DEVICE/relay/1/power power \
  shellies/DEVICE/relay/1/energy energy
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH3
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVICE/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/SHELLY4PRO/relay/2/command off
  on:noArg shellies/SHELLY4PRO/relay/2/command on
attr DEVICE getList shellies/DEVICE/relay/2/power power \
  shellies/DEVICE/relay/2/energy energy
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVICE/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/SHELLY4PRO/relay/3/command off
  on:noArg shellies/SHELLY4PRO/relay/3/command on
attr DEVICE getList shellies/DEVICE/relay/3/power power \
  shellies/DEVICE/relay/3/energy energy
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 06 Dezember 2018, 23:34:05
So, das habe ich mal gebastelt um die Zeitschaltuhr meiner Rollladen zu ersetzen. Leider schon zu spät um es zu testen, aber die Hoffnung ist gerade groß, dass es funktioniert.

Timer um eine Stunde nach Sonnenaufgang die Rollladen zu öfnen.
Internals:
   CFGFN     
   COMMAND    set Rollladen_auf on-for-timer 60
   DEF        *{sunrise(3600,"5:00","11:00")} set Rollladen_auf on-for-timer 60
   setstate Rollladen_Status on
   NAME       ti_Rollladen_auf
   NR         226
   NTM        08:42:44
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 15:00:00
   TIMESPEC   {sunrise(3600,"5:00","11:00")}
   TRIGGERTIME 1544168564
   TRIGGERTIME_FMT 2018-12-07 08:42:44
   TYPE       at
   READINGS:
     2018-12-06 23:06:55   state           Next: 08:42:44
Attributes:

Internals:
   CFGFN     
   CID        shelly4pro_062065
   DEF        shelly4pro_062065
   DEVICETOPIC Rollladen_auf
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 4
   MQTT2_SERVER_TIME 2018-12-06 23:18:34
   MSGCNT     4
   NAME       Rollladen_auf
   NR         197
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-06 23:18:34   state           off
Attributes:
   IODev      MQTT2_SERVER
   getList    shellies/shelly4pro-062065/relay/1:.* state
   readingList shelly4pro_062065:shellies/shelly4pro-062065/relay/1:.* state
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shelly4pro-062065/relay/1/command off
on:noArg shellies/shelly4pro-062065/relay/1/command on


Timer um eine Stunde vor Sonnenuntergang die Rollladen zu schließen:
Internals:
   CFGFN     
   COMMAND    set Rollladen_zu on-for-timer 60
   DEF        *{sunset(-3601,"15:00","23:59")} set Rollladen_zu on-for-timer 60
   setstate Rollladen_Status off
   NAME       ti_Rollladen_zu
   NR         260
   NTM        16:08:09
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 16:08:10
   TIMESPEC   {sunset(-3601,"15:00","23:59")}
   TRIGGERTIME 1544195289
   TRIGGERTIME_FMT 2018-12-07 16:08:09
   TYPE       at
   READINGS:
     2018-12-06 23:29:11   state           Next: 16:08:09
Attributes:

Internals:
   CFGFN     
   CID        shelly4pro_062065
   DEF        shelly4pro_062065
   DEVICETOPIC Rollladen_zu
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 4
   MQTT2_SERVER_TIME 2018-12-06 23:23:50
   MSGCNT     4
   NAME       Rollladen_zu
   NR         255
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-06 23:23:50   state           off
Attributes:
   IODev      MQTT2_SERVER
   getList    shellies/shelly4pro-062065/relay/2:.* state
   readingList shelly4pro_062065:shellies/shelly4pro-062065/relay/2:.* state
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shelly4pro-062065/relay/2/command off
on:noArg shellies/shelly4pro-062065/relay/2/command on


Status Dummy:
Internals:
   CFGFN     
   DEF       
   NAME       Rollladen_Status
   NR         294
   STATE      off
   TYPE       dummy
   READINGS:
     2018-12-07 01:08:39   state           off
Attributes:
   devStateIcon on:fts_shutter_10@red off:fts_shutter_100@green
   room       00_Allgemein,01_Küche,02_Flur
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 07 Dezember 2018, 07:29:17
Zitat von: miggun am 06 Dezember 2018, 21:50:58
Passt das so für mqtt2.template?
Sieht für mich plausibel aus. Die Aufgabe an dich war auch, das in der Praxis zu testen, oder?

Wie ist deine Antwort auf die Frage, ob nach einem "set <device> attrTemplate <dein templatename>" was sinnvolles rauskommt....!

Dann wären da noch 2 weitere templates offen und eines für den 4-er "all-in-one" (s.u.).

Da du planst, den 4-er als Rolladenaktor zu nutzen:
a) WiFi ist m.E. ganz allgemein gesagt keine geeignete Technologie für sowas (mußt du selbst wissen, für mich kommt das gleich nach 433MHz-Baumarksteckdosen).
b) Mach noch ein template, mit dem der gesamte Aktor gesteuert werden kann. Für den Rollladeneinsatz brauchst du eigentlich den Aktor nur im Hintergrund, da darf ruhig "all-in-one" sein (s.u.).

Was den Rest angeht:
a) Neues Thema => neuer Thread (das mit dem at ist für den Einstieg ok, später wäre evtl. AutoShuttersControl was, das du ansehen solltest (mit ROLLO als Zwischenschicht)
b) Rolladensteuerung mit 2 Relays => schau mal nach ROLLO
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 07 Dezember 2018, 17:51:04
Bin gerade dabei es zu testen.
Ich vergleiche gerade den Shelly2 mit dem Tasmota.
Wäre es nicht sinnvoll, wenn man in der DropDown-Liste direkt auswählen kann, ob man Kanal 1 oder Kanal 2 einrichten möchte.

Internals:
   CFGFN     
   CID        shelly2
   DEF        shelly2
   DEVICETOPIC shelly2_test
   IODev      MQTT2_SERVER
   NAME       shelly2_test
   NR         532
   STATE      ???
   TYPE       MQTT2_DEVICE
Attributes:
   IODev      MQTT2_SERVER
   comment    Channel 1 for shelly2_test, see also shelly2_test_CH2
   getList    shellies/shelly2_test/relay/power power
   readingList shellies/shelly2_test/relay/0:.* state
   setList    off:noArg shellies/shelly2_test/relay/0/command off


Das dann auch beim Shelly4Pro, das ich direkt Kanal1, 2, 3 oder 4 auswählen kann.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: rudolfkoenig am 07 Dezember 2018, 17:57:00
ZitatWäre es nicht sinnvoll, wenn man in der DropDown-Liste direkt auswählen kann, ob man Kanal 1 oder Kanal 2 einrichten möchte.
Ich finde nicht, weil dann fuer Kanal 2 du ein MQTT2_DEVICE vorher manuell anlegen musst.
Es ist einfacher, Kanal 2 (oder 1) nachher zu entfernen.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 07 Dezember 2018, 18:16:19
Ich bin ja bekanntlich noch ganz neu und habe 0 Ahnung. Aber ich bin bemüht das gut zu machen.
Trotzdem lassen sich dumme fragen nicht vermeiden.
Ich habe für den Test den Namen shelly2_test vergeben. Das funktioniert so nicht, ich muss, um den Shelly richtig zu definieren, den korrekten Gerätenamen verwenden. In meinem Fall wäre das, shellyswitch_32B268, da Minus als Zeichen nicht erlaubt ist.
Der Name wird dann ja später für readingList, getList usw. verwendet. Jetzt das Problem, dort müsste folgendes stehen.

shellies/shellyswitch-32B268/relay/

Das kann ich aber als Name nicht vergeben.
Oder mache ich ein Problem auf, wo keins ist?

Gibt es nicht die Möglichkeit in dem Template den vergebenen Namen für DEVICE zu verändern?
Die Länge vor dem Unterstrich ist immer gleich beim shelly2. Somit irgendwie nimm shellyswitch_32B268 mache daraus shellyswitch-32B268 und setze das als DEVICE.
Also alles vor und hinter dem Unterstrich unverändert lassen.


Er meckert an, das er on nicht kennt. Könnte das Problem ein fehlender Backslash sein? Würde es so funktionieren?


# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
attr DEVICE setList\
  off:noArg shellies/DEVICE/relay/0/command off \
  on:noArg shellies/DEVICE/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVICE/relay/1/command off \
  on:noArg shellies/DEVICE/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVICE/relay/1/command off \
  on:noArg shellies/DEVICE/relay/1/command on
deleteattr DEVICE_CH2 getList
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 08 Dezember 2018, 07:35:43
...bin auch nicht der Perl-Held und mag auch nicht behaupten, dass ich bis ins letzte durchgestiegen bin, wie das im Detail funktioniert, aber versuch mal folgendes bitte:
Füge mal
par:IDENTIFIER;default preset followed by serial number of this ESP chip;{ AttrVal("DEVICE","readingList","") =~ m,shellies/.*_(.*)[/]?:, ? shellyswitch-$1 : undef }

in den template-code für den shelly2 ein (dort oben, wie z.B. in den tasmota-Beispielen) und ersetze dann im eigentlichen attr-code der setList DEVICE durch IDENTIFIER (da wo es jeweils um den Topic geht).

(Ich hoffe, das ist wenigstens nachvollziehbar erklärt). Das müßtest du dann ggf. für die anderen anpassen, die dann was anderes verwenden als den preset "shellyswitch".

Generell noch die Bitte, die Geräte erst noch nicht weiter zu konfigurieren, was die MQTT-Topicstruktur usw. angeht. Das template sollte mit den jeweiligen defaults laufen ;) .
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Prof. Dr. Peter Henning am 08 Dezember 2018, 09:14:51
Nach meinen Informationen wird sich an der Topic-Struktur im Shelly 2 noch etwas ändern, wenn die neue Firmware endgültig im Release ist.

LG

pah
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 08 Dezember 2018, 09:27:23
Danke für die Info.

Wann ist das zu erwarten? Wird das größere Änderungen ergeben, soweit die verschiedenen Beta-Versionen das erkennen lassen?

Aber an sich spräche doch wenig dagegen, das mit dem heutigen Stand fertig zu machen und dann nach den Änderungen eben nachzupflegen, und die derzeitigen Fassungen ggf. mit einem "_old_firmware"-Zusatz eine Zeitlang noch im template drin zu lassen...
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: rudolfkoenig am 08 Dezember 2018, 14:55:15
ZitatDer Name wird dann ja später für readingList, getList usw. verwendet.
Das ist aber nicht notwendig, ich wuerde stattdessen (wie Beta-User das vorgeschlagen hat) ein Parameter definieren.
Das kann man entweder vorbelegen (siehe Beispiel von Beta-User), oder wenn das nicht klappt, dann muss der Benutzer das in einem Dialog eingeben.

Apropos Beispiel:
shellyswitch-$1 in der par: Zeile wird einen Fehler verursachen: der Interpreter wird versuchen eine Funktion shellyswitch aufzurufen.
Ich wuerde nur $1 zurueckliefern, und in setList/getList shellyswitch-IDENTIFIER reinschreiben (da ist kein Perl mehr, sondern einfache Text-Ersetzung).
Statt IDENTIFIER kann man beliebige andere Namen verwenden
readingList zu aendern sollte unnoetig sein, oder ich habe was nicht verstanden.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 08 Dezember 2018, 17:44:54
@miggunHabe mal versucht, das umzusetzen, was Rudi geschrieben hat (und den Backslash ergänzt ;) ). Kannst du das mal versuchen?

# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
par:CHIPID;serial number of this ESP chip;{ AttrVal("DEVICE","readingList","") =~ m,shellies/.*_(.*)[/]?:, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/shellyswitch-CHIPID/relay/0/command off\
  on:noArg shellies/shellyswitch-CHIPID/relay/0/command on
attr DEVICE readingList shellies/shellyswitch-CHIPID/relay/0:.* state
attr DEVICE getList shellies/shellyswitch-CHIPID/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/shellyswitch-CHIPID/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList\
  off:noArg shellies/shellyswitch-CHIPID/relay/1/command off\
  on:noArg shellies/shellyswitch-CHIPID/relay/1/command on
deleteattr DEVICE_CH2 getList
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 08 Dezember 2018, 21:02:27
Funktioniert....und wie genial das funktioniert. Besonders schön, die Abfrage nach der Seriennummer.
Top.
Werde ich direkt mal für den 4er umbauen.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 08 Dezember 2018, 21:23:42
Werde das jetzt so mal für den 4er eingeben und hoffe, dass ich mich nicht vertan habe.

Edit: 21:44 getestet und alle 4 Kanäle funktionieren. Somit Shelly2 und Shelly4Pro in Ordnung. Shelly1 muss ich noch verbauen, dürfte aber ähnlich sein...außer das Shelly1 keine Messwerte erfasst.
Edit: 09.12.2018 06:59: Bei den Ausgaben von power und energy noch nen Fehler entdeckt. Die muss man durch nummerieren. Teste ich noch, bin im Moment etwas zu müde, nach der Nachtschicht.

# shelly4pro using original firmware.
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:CHIPID;serial number of this ESP chip;{ AttrVal("DEVICE","readingList","") =~ m,shellies/.*_(.*)[/]?:, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/shelly4pro-CHIPID/relay/0/command off\
  on:noArg shellies/shelly4pro-CHIPID/relay/0/command on
attr DEVICE readingList shellies/shellyswitch-CHIPID/relay/0:.* state
attr DEVICE getList shellies/shelly4pro-CHIPID/relay/0/power power1\
  shellies/shelly4pro-CHIPID/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/shelly4pro-CHIPID/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList\
  off:noArg shellies/shelly4pro-CHIPID/relay/1/command off\
  on:noArg shellies/shelly4pro-CHIPID/relay/1/command on
attr DEVICE_CH2 readingList shellies/shellyswitch-CHIPID/relay/1:.* state
attr DEVICE_CH2 getList shellies/shelly4pro-CHIPID/relay/1/power power2\
  shellies/shelly4pro-CHIPID/relay/1/energy energy2
attr DEVICE_CH2 comment Channel 2 for DEVICE, see also DEVICE, DEVICE_CH3 and DEVICE_CH4
copy DEVICE_CH2 DEVICE_CH3
attr DEVICE_CH3 readingList shellies/shelly4pro-CHIPID/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList\
  off:noArg shellies/shelly4pro-CHIPID/relay/2/command off\
  on:noArg shellies/shelly4pro-CHIPID/relay/2/command on
attr DEVICE_CH3 readingList shellies/shellyswitch-CHIPID/relay/2:.* state
attr DEVICE_CH3 getList shellies/shelly4pro-CHIPID/relay/2/power power3\
  shellies/shelly4pro-CHIPID/relay/2/energy energy3
attr DEVICE_CH3 comment Channel 3 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH4
copy DEVICE_CH3 DEVICE_CH4
attr DEVICE_CH4 readingList shellies/shelly4pro-CHIPID/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList\
  off:noArg shellies/shelly4pro-CHIPID/relay/3/command off\
  on:noArg shellies/shelly4pro-CHIPID/relay/3/command on
attr DEVICE_CH4 readingList shellies/shellyswitch-CHIPID/relay/3:.* state
attr DEVICE_CH4 getList shellies/shelly4pro-CHIPID/relay/3/power power4\
  shellies/shelly4pro-CHIPID/relay/3/energy energy4
attr DEVICE_CH4 comment Channel 4 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH3
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 09 Dezember 2018, 09:56:48
 :)
Danke für die Rückmeldung!
Hoffe, du findest meine eingangs mal gemachte These bestätigt, dass du dabei auch was wichtiges lernen wirst :P :-* ...

Dass hier habe ich evtl. überlesen/bisher ignoriert:
Zitat von: rudolfkoenig am 06 Dezember 2018, 12:51:07
Weiterhin wuerde ich readingList automatisch anlegen lassen, und nicht explizit spezifizieren (und damit das vorher automatisch Angelegte entfernen)
Mir ist zwar im Moment noch nicht so klar, wie dann erkannt wird, welcher Wert zu welchem Device gehört, aber wenn Rudi das so schreibt, lasse ich mich gerne überraschen.

Versuchst du dich dann noch an einem 4-er "unified"-template? Das wäre m.E. einfacher zu handhaben für den von dir beabsichtigten Zweck, zwei Rolläden damit zu steuern ;) . Da solltest du die readingList in jedem Fall weglassen. Und dann schau dir ROLLO an, ich bin mir ziemlich sicher, dass dir das ziemlich viel von dem abnimmt, was du bisher noch gar nicht "auf dem Schirm" hast.

Dann noch den 2-er im roller-Modus?

Wäre echt klasse!
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: rudolfkoenig am 09 Dezember 2018, 11:49:39
Habe shelly4pro in mqtt2.template eingebaut und eingecheckt.
ZitatMir ist zwar im Moment noch nicht so klar, wie dann erkannt wird, welcher Wert zu welchem Device gehört
Das wird nicht erkannt, und alle Readings landen damit in allen kopierten FHEM-Instanzen, nur fuer die Anzeige (und Steuerung) wird der passende Wert verwendet. Aber ich sehe es ein, dass das explizit spezifizierte readingList weniger verwirrend sein kann.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 09 Dezember 2018, 13:35:38
Ich lerne durch die Aktion hier unheimlich viel, auch wen ich für jede Kleinigkeit etliche Stunden brauche, geht es Stück für Stück voran.
Shelly2 muss ich noch einen bestellen, da der eine in der Küche für die Beleuchtung verbaut ist. Den Rollo-Mode kann ich nicht nutzen, da ich damit wirklich nur verriegelungs-Relais ansteure, somit nur on-for-timer. Läuft aber jetzt auch schon perfekt mit sunrise und sunset.
Shelly 2 bestell ich noch und Shelly1 verbau ich noch.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Christian Uhlmann am 09 Dezember 2018, 14:47:36
Hallo zusammen,

ich bin sehr angetan von den MQTT2.* Modulen und möchte nach und nach umsteigen.
Auch benötige ich bei einigen geplanten einsatzorten der Shelly sofort eine Info, wenn geschaltet wurde, daher kommt das Shelly Modul nicht überall in Frage.

Leider bekomme ich meinen Shelly 2 trotz diesem Template
Zitat von: Beta-User am 08 Dezember 2018, 17:44:54
@miggunHabe mal versucht, das umzusetzen, was Rudi geschrieben hat (und den Backslash ergänzt ;) ). Kannst du das mal versuchen?

# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
par:CHIPID;serial number of this ESP chip;{ AttrVal("DEVICE","readingList","") =~ m,shellies/.*_(.*)[/]?:, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/shellyswitch-CHIPID/relay/0/command off\
  on:noArg shellies/shellyswitch-CHIPID/relay/0/command on
attr DEVICE readingList shellies/shellyswitch-CHIPID/relay/0:.* state
attr DEVICE getList shellies/shellyswitch-CHIPID/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/shellyswitch-CHIPID/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList\
  off:noArg shellies/shellyswitch-CHIPID/relay/1/command off\
  on:noArg shellies/shellyswitch-CHIPID/relay/1/command on
deleteattr DEVICE_CH2 getList

nicht richtig zum laufen.

Es werden 2 devices erzeugt (ich habe diese mal umbenannt, aber auch mit den default device namen ist das verhalten gleich:
Device Kanal 1:

defmod shelly2.ch01 MQTT2_DEVICE shellyswitch_32B11E
attr shelly2.ch01 IODev MQTT2_SERVER
attr shelly2.ch01 comment Channel 1 for MQTT2_shellyswitch_32_11_, see also MQTT2_shellyswitch_32_11__CH2
attr shelly2.ch01 getList shellies/shellyswitch-32B11E/relay/power power
attr shelly2.ch01 readingList shellies/shellyswitch-32B11E/relay/0:.* state\
shellyswitch_32B11E:shellies/shellyswitch-32B11E/relay/power:.* power\
shellyswitch_32B11E:shellies/shellyswitch-32B11E/relay/energy:.* energy
attr shelly2.ch01 room MQTT2_DEVICE
attr shelly2.ch01 setList off:noArg shellies/shellyswitch-32B11E/relay/0/command off\
  on:noArg shellies/shellyswitch-32B11E/relay/0/command on

setstate shelly2.ch01 on
setstate shelly2.ch01 2018-12-09 14:30:01 1 on
setstate shelly2.ch01 2018-12-09 14:27:09 announce_fw_ver 20181207-155525/v1.4.1@1142a57b
setstate shelly2.ch01 2018-12-09 14:27:09 announce_id shellyswitch-32B11E
setstate shelly2.ch01 2018-12-09 14:27:09 announce_ip 192.168.127.124
setstate shelly2.ch01 2018-12-09 14:27:09 announce_mac 86F3EB32B11E
setstate shelly2.ch01 2018-12-09 14:27:09 announce_new_fw false
setstate shelly2.ch01 2018-12-09 14:27:09 announce_online true
setstate shelly2.ch01 2018-12-09 14:43:29 energy 1
setstate shelly2.ch01 2018-12-09 14:43:29 power 42.91
setstate shelly2.ch01 2018-12-09 14:30:01 shellies/shellyswitch-32B11E/relay/0 on
setstate shelly2.ch01 2018-12-09 14:43:29 state on


Device Kanal 2:

defmod shelly2.ch02 MQTT2_DEVICE shellyswitch_32B11E
attr shelly2.ch02 IODev MQTT2_SERVER
attr shelly2.ch02 comment Channel 2 for MQTT2_shellyswitch_32_11_
attr shelly2.ch02 readingList shellies/shellyswitch-32B11E/relay/1:.* state\
shellyswitch_32B11E:shellies/shellyswitch-32B11E/relay/power:.* power\
shellyswitch_32B11E:shellies/shellyswitch-32B11E/relay/energy:.* energy
attr shelly2.ch02 room MQTT2_DEVICE
attr shelly2.ch02 setList off:noArg shellies/shellyswitch-32B11E/relay/1/command off\
  on:noArg shellies/shellyswitch-32B11E/relay/1/command on

setstate shelly2.ch02 on
setstate shelly2.ch02 2018-12-09 14:44:29 energy 1
setstate shelly2.ch02 2018-12-09 14:44:29 power 42.84
setstate shelly2.ch02 2018-12-09 14:44:29 state on


Kanal 2 läßt sich schalten, bei Kanal 1 kommen Daten aber das Schalten klappt nicht.
Auch der Status ist irgendwie falsch, wenn ich den Shelly 2 Kanal 1 manuell ausschalte, bleibt das reading "shellies/shellyswitch-32B11E/relay/0" auf on obwohl ich es auf off geschaltet habe.

Zitat von: miggun am 08 Dezember 2018, 21:02:27
Funktioniert....und wie genial das funktioniert. Besonders schön, die Abfrage nach der Seriennummer.
Top.
Funktioniert der Kanal 1 wirklich Schaltbar bei dir? Erkennst du einen Unterschied zu meinen Devices?

Ich hoffe hier kann mir jemand auf die Sprünge helfen.


Danke und Grüße

Christian


P.S.: Gibt es für Shelly 1 auch schon templates?
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 09 Dezember 2018, 15:00:45
Das Problem bei Dir, bei Kanal 1 ist, dass bei Kanal 1 die /0/ hinter Relay fehlt.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 09 Dezember 2018, 19:03:39
Zitat von: miggun am 09 Dezember 2018, 15:00:45
Das Problem bei Dir, bei Kanal 1 ist, dass bei Kanal 1 die /0/ hinter Relay fehlt.
Kannst du (oder Christian Uhlmann) das template für den shelly2 dann kurz in einer Version liefern, von der du annimmst, dass alles paßt, oder ist das kein Problem des templates? (Am besten als diff einschließlich eines netten "headers" für den shelly-Abschnitt ;) ). Dann könnte Rudi das auch mit einchecken...

Danke!
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 09 Dezember 2018, 20:23:10
Bin jetzt zu Hause, auf dem Handy war das nur schwer zu analysieren, gucke jetzt mal, wieso gerade Kanal 1 nicht geht. Das ist ja eigentlich der Kanal, aus dem Kanal2 abgeleitet wird.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 09 Dezember 2018, 20:37:18
Probier den Kanal 1 mal so. erst mal nur gucken, ob es funktioniert:

defmod shelly2.ch01 MQTT2_DEVICE shellyswitch-32B11E
attr shelly2.ch01 IODev MQTT2_SERVER
shellies/shellyswitch-32B11E/relay/0:.* state
attr shelly2.ch01 readingList shellies/shellyswitch-32B11E/relay/0:.* state\
attr shelly2.ch01 room MQTT2_DEVICE
attr shelly2.ch01 setList off:noArg shellies/shellyswitch-32B11E/relay/0/command off\
on:noArg shellies/shellyswitch-32B11E/relay/0/command on



Ich habe bei mir eigentlich beim Shelly2 drei Devices angelegt. Kanal1, Kanal2 und da der Shelly nur die Messwärte summiert raus gibt, einen dritten für die Messwerte, weil ich die keinem Kanal eindeutig zuweisen kann.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Christian Uhlmann am 09 Dezember 2018, 21:58:08
Hi,

bin gerade mal dazu gekommen einiges auszuprobieren. Leider bisher kein Erfolg.

Zitat von: miggun am 09 Dezember 2018, 15:00:45
Das Problem bei Dir, bei Kanal 1 ist, dass bei Kanal 1 die /0/ hinter Relay fehlt.
Das sehe ich nicht, in beiden Devices ist sowohl im readingsList als auch im setList beides exakt gleich außer dass hier die 0 bzw. 1 steht.
Seltsam finde ich auch, dass im Device 1 im reading state immer der tatsächliche state angezeigt wird.

Zitat von: miggun am 09 Dezember 2018, 20:37:18
Probier den Kanal 1 mal so. erst mal nur gucken, ob es funktioniert:

defmod shelly2.ch01 MQTT2_DEVICE shellyswitch-32B11E
attr shelly2.ch01 IODev MQTT2_SERVER
shellies/shellyswitch-32B11E/relay/0:.* state
attr shelly2.ch01 readingList shellies/shellyswitch-32B11E/relay/0:.* state\
attr shelly2.ch01 room MQTT2_DEVICE
attr shelly2.ch01 setList off:noArg shellies/shellyswitch-32B11E/relay/0/command off\
on:noArg shellies/shellyswitch-32B11E/relay/0/command on

Zeile 3 ist leider nicht valid, soll dies das attribute getList sein?
Selbst ohne Zeile 3, also nur readingsList und setList übernommen, klappt es nicht.

Zitat von: miggun am 09 Dezember 2018, 20:37:18
Ich habe bei mir eigentlich beim Shelly2 drei Devices angelegt. Kanal1, Kanal2 und da der Shelly nur die Messwärte summiert raus gibt, einen dritten für die Messwerte, weil ich die keinem Kanal eindeutig zuweisen kann.
Wenn das hilft sollte es mir recht sein, ein Device als Sensor Device und 2 weitere, je eins, für jedes Relais.
Das teste ich gleich mal, aber ich denke nicht das es was damit zu tun hat, das mein relay 0 nicht reagiert.

Zitat von: Beta-User am 09 Dezember 2018, 19:03:39
Kannst du (oder Christian Uhlmann) das template für den shelly2 dann kurz in einer Version liefern, von der du annimmst, dass alles paßt, oder ist das kein Problem des templates? (Am besten als diff einschließlich eines netten "headers" für den shelly-Abschnitt ;) ). Dann könnte Rudi das auch mit einchecken...
Wenn es denn läuft werde ich mich an einem patch versuchen ;) sollte aber klappen, habe irgendwann schon mal einen gemacht :)


Grüße Christian
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 09 Dezember 2018, 22:01:14
Ups, da habe ich etwas vergessen, in den Code rein zu schreiben.

defmod shelly2.ch01 MQTT2_DEVICE shellyswitch-32B11E
attr shelly2.ch01 IODev MQTT2_SERVER
attr shelly2.ch01 getList  shellies/shellyswitch-32B11E/relay/0:.* state
attr shelly2.ch01 readingList shellies/shellyswitch-32B11E/relay/0:.* state\
attr shelly2.ch01 room MQTT2_DEVICE
attr shelly2.ch01 setList off:noArg shellies/shellyswitch-32B11E/relay/0/command off\
on:noArg shellies/shellyswitch-32B11E/relay/0/command on



Das mit der 0 war ein Fehler von mir. Über das Handy war das alles nicht so gut zu lesen. Warum das bei Dir nicht geht, verstehe ich gerade nicht.

Aber was richtig komisch ist, dass CH2 läuft und ausgerechnet der 1 nicht, der ja Basis für 2 ist und gleich aufgebaut ist.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: miggun am 10 Dezember 2018, 08:39:05
Christian Uhlmann konntest Du Kanal 1 noch einmal testen?

Mir ist noch ein kleines Problem bei Shelly4Pro aufgefallen. Wenn das gute Stück nichts schaltet, sendet es auch nicht mehr viel an Messwerten. Der Shelly 2 macht das, obwohl alles aus, gibt es vom Shelly2 regelmäßig Meßwerte für Leistung und Arbeit, als Lebenszeichen.
Vom Shelly4Pro gibt es nur:
shelly4pro-062065 PINGREQ
Wenn man jetzt aus den Werten einen Plot erzeugt, ist es optisch doof, wenn der Messwert nicht 0 ist, sondern einfach nicht da. Ergibt ein Sägebild im Plot.
Jetzt suche ich etwas, um aus dem PINGREQ einen Messwert zu erzeugen. Also PINGREQ kommt setReading power1 0 bis setReading power4 0 so könnte man das Senden des Messwertes künstlich erzeugen. Die Frage ist halt, ob das ins Template rein müsste, weil es ja sehr wahrscheinlich ist, dass man aus einem gegebenen Messwert auch einen Plot erzeugt.
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: gvzdus am 10 Dezember 2018, 08:44:44
Moin, dann nehme ich mal die Mütze für den Shellybulb auf.

Die Doku ist hier: http://shelly-api-docs.shelly.cloud/#bulb-mqtt (http://shelly-api-docs.shelly.cloud/#bulb-mqtt)

Mit der 8-Uhr-Version von FHEM funktioniert Publish prima! Danke für die Tipps hier im Thread bzgl. "attr verbose 5" und "Howto edit & re-apply a template"!

Folgendes Template ist mein ganz basaler Wurf:

# shellybulb using original firmware.
name:shellybulb
filter:TYPE=MQTT2_DEVICE
par:CHIPID;serial number of this ESP chip;{ AttrVal("DEVICE","readingList","") =~ m,shellies/.*_(.*)[/]?:, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/shellybulb-CHIPID/color/0/command off\
  on:noArg shellies/shellybulb-CHIPID/color/0/command on
attr DEVICE readingList shellies/shellybulb-CHIPID/color/0/set:.* state
attr DEVICE genericDeviceType light
attr DEVICE icon light_control


Nach dem Löschen und Restart wird das Device automatisch angelegt.
Ich muss noch händisch das Template auswählen, und dann in einem Prompt die Chip-ID angeben.

Bleiben für mich folgende Fragen für's "Wie Weiter?"

a) Kann man das nicht elektrifizieren? Beim initialen Connect ließe sich doch das Gerät ausweislich des in die Welt gesetzten eindeutigen Status schon komplett zuordnen und Plug-N-Play-mäßig einbinden? Beispiel:
shellies/shellybulb-3CC533/color/0/status:{"ison":true,"mode":"color","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}

b) An / Aus ist ja mager. Wo klaue ich am besten für das Template, um - um es mit dem Mitbewerber zu sagen: "Die Möglischkeiten zu entdecken?"
Titel: Antw:[Gelöst) MQTT2 Shelly2 Probleme erste Installation
Beitrag von: Beta-User am 10 Dezember 2018, 09:15:55
Zitat von: gvzdus am 10 Dezember 2018, 08:44:44
Moin, dann nehme ich mal die Mütze für den Shellybulb auf.
Danke für die schnelle Initiative!

ZitatNach dem Löschen und Restart wird das Device automatisch angelegt.
Das geht auch mit einem simplen reload: { AttrTemplate_Initialize() }

ZitatIch muss noch händisch das Template auswählen, und dann in einem Prompt die Chip-ID angeben.
par:CHIPID;serial number of this ESP chip;{ AttrVal("DEVICE","readingList","") =~ m,shellies/.*-(.*)[/]?:, ? $1 : undef }
...einfach in der Regex den Unterstrich durch Bindestrich ersetzen...
Scheint evtl. schon die neue Form zu sein; damit könnte man auch den ganzen String samt "shellybulb-" verwenden (weiter oben in diesem Thread).
ZitatBleiben für mich folgende Fragen für's "Wie Weiter?"
a) Kann man das nicht elektrifizieren? Beim initialen Connect ließe sich doch das Gerät ausweislich des in die Welt gesetzten eindeutigen Status schon komplett zuordnen und Plug-N-Play-mäßig einbinden? Beispiel:
shellies/shellybulb-3CC533/color/0/status:{"ison":true,"mode":"color","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}

Ginge vielleicht, aber zwei Gedanken dazu:
a) "Attribute gehören dem user!" ist einer der Grundsätze hier. Sollten also eigentlich nur gesetzt werden, wenn der user das will (bzw. wenn erforderlich, dann erst mal nur im Minimal-Umfang).
b) Es kann durchaus Fälle geben, in denen mehrere templates passen könnten (ein "unified shelly4pro" fehlt z.B. noch). Wer entscheidet dann?
M.E. ist das hier schon eine Luxus-Variante mit dem set ... attrTemplate xy :) .
Zitatb) An / Aus ist ja mager. Wo klaue ich am besten für das Template, um - um es mit dem Mitbewerber zu sagen: "Die Möglischkeiten zu entdecken?"
Mager? Ein Anfang ;) . Schau dir mal die zigbee-templates an und den Beispielcode im Wiki zu den MiLights.
In der mqtt2.template ist irgendwo sogar ein Beispiel, wie Perl-Code aufgerufen wird (das topic ist da mit in den {...}).

@miggun:
Da der Thread jetzt irgendwie einen anderen Schwerpunkt hat: vielleicht nochmal umbenennen?
Vorschlag: MQTT2+Shelly: erste Konfiguration und template-Entwicklung?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 10 Dezember 2018, 10:10:16
Ich weiß nicht: Ich hab' eigentlich schon goutiert, wenn - wie bei MAX, Hue oder HM - gleich alles an Attributen da war...
Und solange die Regeln a la "shellies/shellybulb_.*" eindeutig sind, also nur auf ein Template passen.

Hier noch ein 2. Wurf:

# shellybulb using original firmware.
name:shellybulb
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/color/0/command off\
  on:noArg shellies/DEVNAME/color/0/command on\
  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
attr DEVICE webCmd toggle:on:off:brightness
attr DEVICE genericDeviceType light
attr DEVICE icon light_control


Damit lässt sich auch die Helligkeit regeln. Unschön: Der Slider springt aber immer wieder auf "0" zurück, während die Lampe das Kommando übernimmt. Liegt das vielleicht daran, dass das Reading "status_brightness" heisst, und nicht "brightness"? Kann ich da das Default überbügeln? Muss jetzt aber forumsmäßig offline gehen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 10 Dezember 2018, 10:32:23
ZitatLiegt das vielleicht daran, dass das Reading "status_brightness" heisst, und nicht "brightness"?
Ja.
ZitatKann ich da das Default überbügeln?
Befehl und Reading sollten gleich sein, das kann man z.Bsp. mit einem userReading erreichen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 Dezember 2018, 10:35:15
Na ja, laß uns nicht lange über Automatismen diskutieren, das müßte eh' jemand einbauen, der Perl wirklich kann... :)

Zum 2. Wurf:
- "status_brightness" userReadings ginge natürlich, aber könnte man das reading nicht auch anders vom Namen her umbiegen? Kann aber nicht sagen, ob das mit einer EventMap ginge (ähnlich Tasmota, z.B. Zeile 100 v. mqtt2.template). Dann könnte man nämlich auch ohne Umwege zigbee2mqtt_devStateIcon255() nutzen... (mit einem klickbaren icon).
- Es sollte nur drinstehen, was man wirklich per default benötigt (braucht man "attr DEVICE genericDeviceType light"?)
Vielleicht kannst du auch mal ein list von der Bulb liefern (möglichst nach einigen verschiedenen Schaltvorgängen im Webinterface+dem, was der Event-Monitor liefert, wenn der MQTT2-SERVER auf rawEvent .* steht), damit wir da eine bessere Vorstellung von dem bekommen, was da datenmäßig abläuft?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 10 Dezember 2018, 11:04:46
So, bevor ich nun wirklich los muss, hier der Trace. Ist aber echt einfach: Bei jeder Änderung, ob über MQTT (hier: Kommando ein) oder über das Webfrontend vom Device wird einfach ein Komplettstatus in JSON gepublisht. Kniffeliger ist, wie komplett beim Setzen der JSON-String sein muss.

2018.12.10 10:47:23 4: Connection accepted from MQTT2_FHEM_Server_192.168.0.31_12787
2018.12.10 10:47:23 5: CONNECT: (0)(4)MQTT(4)(2)(0)<(0)(17)shellybulb-3CC533
2018.12.10 10:47:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 CONNECT V:4 keepAlive:60
2018.12.10 10:47:23 5: PUBLISH: (0))shellies/shellybulb-3CC533/color/0/status{"ison":false,"mode":"white","re
d":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}
2018.12.10 10:47:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC
533/color/0/status:{"ison":false,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":
6395,"brightness":100,"effect":0}
2018.12.10 10:47:23 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/co
lor/0/status:{"ison":false,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"
brightness":100,"effect":0}
2018.12.10 10:47:23 5: SUBSCRIBE: (0)(133)(0)&shellies/shellybulb-3CC533/color/0/set(0)
2018.12.10 10:47:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 SUBSCRIBE
2018.12.10 10:47:23 4:   topic:shellies/shellybulb-3CC533/color/0/set qos:0
2018.12.10 10:47:23 5: SUBSCRIBE: (0)(134)(0)*shellies/shellybulb-3CC533/color/0/command(0)
2018.12.10 10:47:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 SUBSCRIBE
2018.12.10 10:47:23 4:   topic:shellies/shellybulb-3CC533/color/0/command qos:0

2018.12.10 10:48:23 5: PINGREQ:
2018.12.10 10:48:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PINGREQ

2018.12.10 10:48:48 5: MQTT2_FHEM_Server: PUBLISH shellies/shellybulb-3CC533/color/0/command on
2018.12.10 10:48:48 5: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 => shellies/shellybulb-3CC533/color/0/command:on
2018.12.10 10:48:48 5: PUBLISH: (0)"shellies/shellybulb-3CC533/color/0on
2018.12.10 10:48:48 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC533/color/0:on
2018.12.10 10:48:48 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:on
2018.12.10 10:48:48 5: PUBLISH: (0))shellies/shellybulb-3CC533/color/0/status{"ison":true,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}
2018.12.10 10:48:48 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC533/color/0/status:{"ison":true,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}
2018.12.10 10:48:48 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:{"ison":true,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}

2018.12.10 10:53:25 5: PUBLISH: (0)"shellies/shellybulb-3CC533/color/0on
2018.12.10 10:53:25 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC
533/color/0:on
2018.12.10 10:53:25 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/co
lor/0:on
2018.12.10 10:53:25 5: PUBLISH: (0))shellies/shellybulb-3CC533/color/0/status{"ison":true,"mode":"color","red
":119,"green":99,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":32,"effect":0}
2018.12.10 10:53:25 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC
533/color/0/status:{"ison":true,"mode":"color","red":119,"green":99,"blue":255,"white":0,"gain":100,"temp":63
95,"brightness":32,"effect":0}
2018.12.10 10:53:25 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/co
lor/0/status:{"ison":true,"mode":"color","red":119,"green":99,"blue":255,"white":0,"gain":100,"temp":6395,"br
ightness":32,"effect":0}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 Dezember 2018, 11:26:41
Kannst du mal nur  "{ json2nameValue($EVENT) }" in der readingList verwenden? Das Problem scheint ja "nur" das prefix zu sein...

(muß ich evtl. in der zigbee2mqtt-bridge auch noch gradeziehen, da ist das "log_" auch nicht sooo toll).

Generell: ein list wäre hilfreich ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 10 Dezember 2018, 11:58:32
Funzt so. Aber ich hatte halt kein readingList im Template, weil schon so vom Auto-Create zwei angelegt werden. Also, Zustand nach Auto-Create:

attr MQTT2_shellybulb_3CC533 readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }\
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0


Attribut readingList gelöscht, neu eingegeben:

shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT) }

Ergebnis: Brightness-Slider ist stabil, prima! Und die Werte sind auch alle da. Aber sobald das nächste Event reinkommt, schlägt Auto-Create wieder zu und baut ein:

shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT) }
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0


daraus.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 Dezember 2018, 12:06:07
Na ja, wenn die Werte mit dem 2-zeiligen Ergebniscode sauber reinkommen (und raus), ist ja alles gut.
Dann kann man zur Vermeidung von Verwirrung ggf. beide Zeilen in das template aufnehmen, oder?
Oder gibt das irgendwie einen Kuddelmuddel?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 10 Dezember 2018, 12:55:37
Naja, hübsch ist halt anders. Erstens sind alle Werte doppelt aufgeführt, zweitens klappte es erst beim 2. Reload des Templates und Hin- und Herschalten.
Ich vermute, für zigbee2bridge ist nötig, dass AutoCreate auch für neue Topics, die schon zur Anlage von Geräten geführt haben, die Geräte weiter bei einem neuen Event bearbeitet? Sonst hilft ja nur, AutoCreate wieder abzuschalten, wenn man die readings ohne Redundanz übersichtlich haben will.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 10 Dezember 2018, 12:59:09
also ich würde es auch sehr begrüßen wenn

{ json2nameValue($EVENT, 'status_') }

zumindest optional wieder auf

{ json2nameValue($EVENT) }

angelegt würde, so wie es vor kurzem war.

Man könnte ja neben dem autocreate noch einen Zusatzschalter definieren ob bei autocreate gepräfixed werden soll oder nicht.

Also z. B. mqttautoprefix 0 oder 1 in der Konfiguration.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 Dezember 2018, 13:47:39
Zitat von: gvzdus am 10 Dezember 2018, 12:55:37
Naja, hübsch ist halt anders. Erstens sind alle Werte doppelt aufgeführt, zweitens klappte es erst beim 2. Reload des Templates und Hin- und Herschalten.
Ich vermute, für zigbee2bridge ist nötig, dass AutoCreate auch für neue Topics, die schon zur Anlage von Geräten geführt haben, die Geräte weiter bei einem neuen Event bearbeitet? Sonst hilft ja nur, AutoCreate wieder abzuschalten, wenn man die readings ohne Redundanz übersichtlich haben will.
Hattest du zwischendurch mal alle Readings (oder das ganze Device) gelöscht? Nicht, dass wir hier "Altlasten" diskutieren, die bei neuen Devices mit "richtigem" attrTemplate gar nicht mehr auftreten. (Man könnte in das template auch einen entsprechenden Löschbefehl ziemlich zu Beginn reinschreiben: "deletereading DEVICE .*".

Zitat von: osr am 10 Dezember 2018, 12:59:09
also ich würde es auch sehr begrüßen wenn
Kannst du das bitte in dem Bugs-Thread thematisieren? Wir versuchen hier nur Zuarbeit zu machen; jetzt im wesentlichen auf Basis des "as is" Zustands der Module.
Zur Erläuterung, warum ich meine, dass das hier falsch ist: Es sieht zwar auf die Schnelle danach aus, als würde hier was doppelt angelegt. Das glaube ich aber nicht (sonst wäre es m.E. auch ein Bug, der dann wieder woanders zu diskutieren wäre), sondern es sind bestehende Readings, die eben nur nicht mehr aktualisiert werden. Beide Teile der readingList sollten für jeweils andere Readings zuständig sein.

Trotz OT kurz meine Meinung zur Frage, ob die prefix-Sache an sich gut ist:
Die ganze Geschichte mit MQTT2 ist noch neu, wer jetzt schon eingestiegen war, hat halt ggf. Aufwand, Dinge umzustellen (entweder in der readingList usw. oder in den Eventhandlern). Das ist nicht schön, aber wenn wir das alle durchgestanden haben, gibt es weniger Verwirrung, weil jedes Reading eine eindeutige Quelle hat.
Zum "Verbiegen" haben wir die templates, das ist auch eine gute Sache (wenn auch noch nicht an jeder Ecke von jedem verstanden und daher eben noch mit Verbesserungspotential). Es hilft bereits jetzt vielen Einsteigern sehr.

Mir kommt die "Bridge"-Sache auch nicht als zu speziell vor. Betrifft zwar scheinbar nur zigbee2mqtt (und den "Exoten" ESP-Milight-Hub), aber da mqtt ein universelles Protokoll ist, dürften zukünftig noch deutlich mehr Dienste auftauchen, die irgendwo Daten einsammeln und dann unter ihrer Kennung weitergeben (das wäre btw. auch ein FHEM, das seine Devices via MQTT zur Verfügung stellt...).

Fazit: Finde es tendenziell besser, das so zu lassen wie es ist. Abschaltbar wäre mir persönlich zwar egal, aber vermutlich bildet das dann wieder eine Fehlerquelle für noobs, die vergessen haben, dass es da eine Option gab, die sie geschaltet haben.

@gvzdus:
Würdest du ein list liefern, könnte man die Zeitstempel sehen. So mußte ich die Glaskugel bemühen...

EDIT: Noch ein Vertreter einer MQTT-Bridge: MySensors (in der MQTT-GW-Variante)...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 10 Dezember 2018, 14:13:16
Bitteschön!

nternals:
   CFGFN     
   CID        shellybulb_3CC533
   DEF        shellybulb_3CC533
   DEVICETOPIC MQTT2_shellybulb_3CC533
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 26
   MQTT2_FHEM_Server_TIME 2018-12-10 12:21:56
   MSGCNT     26
   NAME       MQTT2_shellybulb_3CC533
   NR         228
   STATE      brightness
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-10 12:21:56   blue            255
     2018-12-10 12:21:56   brightness      100
     2018-12-10 12:21:56   effect          0
     2018-12-10 12:21:56   gain            100
     2018-12-10 12:21:56   green           99
     2018-12-10 12:21:56   ison            true
     2018-12-10 12:21:56   mode            white
     2018-12-10 12:21:56   red             119
     2018-12-10 12:21:56   shellies/shellybulb-3CC533/color/0 on
     2018-12-10 12:21:56   state           brightness
     2018-12-10 12:19:42   status_blue     255
     2018-12-10 12:19:42   status_brightness 18
     2018-12-10 12:19:42   status_effect   0
     2018-12-10 12:19:42   status_gain     100
     2018-12-10 12:19:42   status_green    99
     2018-12-10 12:19:42   status_ison     true
     2018-12-10 12:19:42   status_mode     white
     2018-12-10 12:19:42   status_red      119
     2018-12-10 12:19:42   status_temp     6395
     2018-12-10 12:19:42   status_white    0
     2018-12-10 12:21:56   temp            6395
     2018-12-10 12:21:56   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   genericDeviceType light
   icon       light_control
   readingList shellies/shellybulb-3CC533/color/0/status:.* {json2nameValue($EVENT)}
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
   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"}
   webCmd     toggle:on:off:brightness


Ja, ich habe definitiv das Device gelöscht, gespeichert und restartet. Du (ich) sehe auch im Log bei jedem Status-Update:

2018.12.10 14:04:47 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:{"ison":false,"mode":"white","red":119,"green":99,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}


Der Prefix "status" ist ja da, weil das Topic am Ende "status" heisst - daher wird es in 10_MQTT2_DEVICE.pm geholt. Allerdings gibt es halt (möglicherweise mehrere) Devices, die nur ein einziges Topic haben, wo dann das Prefix für die garantierte Eindeutigkeit der readings nicht nötig ist.

Hoffentlich liest Rudolf das jetzt und entscheidet, wie man das am besten löst.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 Dezember 2018, 14:39:04
OK, der Reihe nach (kann aber auch sein, dass ich mich irre):

autocreate erkennt: "Ah, neues device" => readingList wird erstellt (mit prefix).
Dann template wird angewandt: "Ah, andere Umwandlung, neue Reading-Namen". Die werden dann befüllt, deswegen unterscheiden sich die Reading-Timestamps um 2 Minuten ;) . Wäre es dasselbe Event, wäre es gleich (eine Sekunde Differenz max.).

Zitat von: Beta-User am 10 Dezember 2018, 13:47:39
Man könnte in das template auch einen entsprechenden Löschbefehl ziemlich zu Beginn reinschreiben: "deletereading DEVICE .*".
Kannst du daher das bitte noch versuchen? Dann sollten die alten Readings verschwinden und dann nur noch neue kommen :) .

Edit, um es noch spezifischer zu machen:# shellybulb using original firmware.
name:shellybulb
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
deletereading DEVNAME status_.*
...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 10 Dezember 2018, 16:20:54
Also habe jetzt mal in my.template folgendes für meine Wemos hinterlegt:

name:WemosD1
filter:TYPE=MQTT2_DEVICE
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
deleteReading DEVICE .*

Das Problem mit den STATE_ ... ist dass dann z. B. für POWER, POWER1, ... verschiedene Readings angelegt werden. Interessieren tut aber eigentlich nur der neueste. Wenn im STATE_POWER1 of on gesetzt ist, ist das der aktuelle Status für POWER1 egal ob vorhin mal ein cmd mit POWER1 kam mit off. Dadurch ist der Status immer richtig. Egal ob über ein cmd.../POWER subscribe oder ein RESULT oder ein STATE_ ein Wert kam, der neueste ist der Richtige. Dadurch kann man Störungen, wenn mal irgendwas nicht geklappt hat sauber erkennen und FHEM zeigt immer den korrekten Status an. Durch die ganzen Präfix-Geschichten unterlaufe ich das wieder. Deswegen ist die Sache mit dem hinzugefügten Präfix zwar sauber, aber zumindest für mich, nicht besser.

Wohin sollte ich das denn nun am besten Posten als Verbesserungsvorschlag mit der Konfiguration?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 Dezember 2018, 16:32:38
ZitatWohin sollte ich das denn nun am besten Posten als Verbesserungsvorschlag mit der Konfiguration?

Rudi liest hier grundsätzlich mit. Von daher ist es "an sich" hier richtig.

Ein paar Anmerkungen, was mir auf die Schnelle auffällt:
- "WemosD1" ist eine bestimmte ESP8266-Hardware, auf der ganz unterschiedliche firmwares laufen können. Ist das Tasmota? Dann sollte der name: auch irgendwas mit Tasmota beinhalten ;) . Wenn es was anderes ist, dann eben das.
- Eine kurze Erläuterung wäre nicht schlecht (Kommentare beginnen immer mit #).

Wenn ich das richtig verstanden habe, geht es dir um "tasmota_general_without_prefixes" (use this for "classic" behaviour of tasmota flashed devices to avoid any prefixes in reading names).

Optimal wäre ein Patch für mqtt2.template (howto (https://wiki.fhem.de/wiki/How_to_write_a_patch)), aber wenigstens Code-Tags (#-Taste oben) wären nett ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 10 Dezember 2018, 16:54:38
Und nun wieder der Kollege mit seiner ollen Lampe :-)

Ja, die Idee mit dem "deletereading" im Template war gut. Denn der AutoCreate "verbessert" immer nur das "fehlende"
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
- damit kann man leben oder autocreate abschalten.

Inzwischen bin auch schon recht dicht vor dem Finale:
- Farbtemperatur funzt
- Aus den Einzelwerten für red, green, blue einen Wert "rgb" wie bei den anderen Kindern basteln, um den Colorpicker zu füttern, funzt.

Wo es hakt: das zigbee2mqtt_RGB2JSON gescheit weiterzuverarbeiten, um eine Farbe zu setzen. So, wie ich das definitiert habe, landet bei der Farbänderung
2018.12.10 16:45:58 5: MQTT2_FHEM_Server_192.168.0.26_64922 shellybulb-3CC533 => shellies/shellybulb-3CC533/color/0/set:{"ison":"true","mode":"white","rgb":zigbee2mqtt_RGB2JSON(59ffac)}
im Logfile.

Gesamtsituation:

Internals:
   CFGFN     
   CID        shellybulb_3CC533
   DEF        shellybulb_3CC533
   DEVICETOPIC MQTT2_shellybulb_3CC533
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 63
   MQTT2_FHEM_Server_TIME 2018-12-10 16:45:28
   MSGCNT     63
   NAME       MQTT2_shellybulb_3CC533
   NR         271
   STATE      rgb
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2018-12-10 16:45:28   blue            255
     2018-12-10 16:45:28   brightness      52
     2018-12-10 16:45:28   effect          0
     2018-12-10 16:45:28   gain            100
     2018-12-10 16:45:28   green           99
     2018-12-10 16:45:28   ison            true
     2018-12-10 16:45:28   mode            white
     2018-12-10 16:45:28   red             119
     2018-12-10 16:45:59   rgb             7763FF
     2018-12-10 16:45:28   shellies/shellybulb-3CC533/color/0 on
     2018-12-10 16:45:59   state           rgb
     2018-12-10 16:45:28   temp            5290
     2018-12-10 16:45:28   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   genericDeviceType light
   icon       light_control
   readingList shellies/shellybulb-3CC533/color/0/status:.* {json2nameValue($EVENT)}
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
   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 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","rgb":zigbee2mqtt_RGB2JSON($EVTPART1)}
   userReadings rgb {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
   webCmd     toggle:on:off:brightness:temp:rgb
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 10 Dezember 2018, 17:05:26
Zitat von: Beta-User am 10 Dezember 2018, 16:32:38
Ein paar Anmerkungen, was mir auf die Schnelle auffällt:
- "WemosD1" ist eine bestimmte ESP8266-Hardware, auf der ganz unterschiedliche firmwares laufen können. Ist das Tasmota? Dann sollte der name: auch irgendwas mit Tasmota beinhalten ;) . Wenn es was anderes ist, dann eben das.

Klar Tasmota was sonst ;-) Aber ich nutze das auch für die sonoffBasic, die 4 Ports etc., also grundsätzlich für alle Tasmota Geräte. Nur stateFormat etc. lege ich dann unterschiedlich an. Aber readingList ist einheitlich. Ich fand autocreate schön, habe nur was gegen die Präfixe und auch die cmnd/.../POWER sind unnötig, aber mit POWER könnte ich im autocreate gut leben.

readingList sollte für Tasmota:

LWT für den Status ist ein muss
RESULT für die Antwort (egal wie POWER gesetzt wurde per FHEM, MQTT selbst oder per Hardware)
SENSOR um alle Sensordaten zu erhalten
STATE um die Stati alle paar Minuten zu erhalten von POWER etc.

enthalten. Mehr braucht es nicht für Tasmota, egal was da dran hängt. Relays, Sensoren (Temperatur, Feuchtigkeit, Helligkeit, ...), Switches wie Bewegungsmelder, Taster, ...

Werde mal ein paar Templates erstellen inklusive Kommentare etc ;-) und hier posten, mache dann auch mal einen für 4 Port mit setList und Stati etc.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 Dezember 2018, 17:14:35
Zitat von: gvzdus am 10 Dezember 2018, 16:54:38
Und nun wieder der Kollege mit seiner ollen Lampe :-)
;D ;D ;D
Zitat
Ja, die Idee mit dem "deletereading" im Template war gut. Denn der AutoCreate "verbessert" immer nur das "fehlende"
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
- damit kann man leben oder autocreate abschalten.
Danke für die Rückmeldung. Kannst du das direkt in das template mit aufnehmen? Dann hat man keine nachträglichen Änderungen mehr, die irgendjemanden irritieren könnten.

ZitatInzwischen bin auch schon recht dicht vor dem Finale:
- Farbtemperatur funzt
- Aus den Einzelwerten für red, green, blue einen Wert "rgb" wie bei den anderen Kindern basteln, um den Colorpicker zu füttern, funzt.
Sowas hört man doch gerne. Paßt denn der Zeitstempel für das userReading? (Ich will was ähnliches für die MiLights machen, glaube aber, dass das userreading immer aktualisiert wird, wenn sich irgendein Status ändert; aber da wird auch "anders" auf weiß geschaltet, unabhängig von der alten Farbe, und dann würde ein farbiges devStateIcon ggf. nicht mehr passen).

ZitatWo es hakt: das zigbee2mqtt_RGB2JSON gescheit weiterzuverarbeiten, um eine Farbe zu setzen. So, wie ich das definitiert habe, landet bei der Farbänderung
Da mußt du vermutlich die Funktion zigbee2mqtt_RGB2JSON() aus MQTT2_DEVICE mal in eine eigene myUtils übernehmen und entsprechend editieren. Die Art, wie zigbee2mqtt den JSON haben will, scheint deutlich anders zu sein. Dazu kannst du den MQTT2-Server auf "gesprächig" stellen (rawEvents), um das Ergebnis direkt zu prüfen.
Und wenn alles Perl-Code sein soll, muß die Klammer auch um das topic (schau mal im mqtt2template, da gab es ein Beispiel mit der Funktion, die dir hier nicht weiterhilft, soweit ich mich entsinne).

Zitat von: osr am 10 Dezember 2018, 17:05:26
Klar Tasmota was sonst ;-)
ESPEasy spricht auch MQTT, wenn ich das richtig verstanden habe. Und meine MiLight-Bridge ist auch ein D1-Mini, genau wie meine IR-Bridge, auf der wieder eine ganz andere Firmware läuft. Ergo: Nicht alle ESP8266 sind Tasmota, nicht mal alle WemosD1 :P .

Aber davon weg: "name:tasmota_pure_base"?

Ansonsten bin ich auf die templates gespannt.
Kann man darüber auch firmware-updates hauen, restarts auslösen und irgendwas abfragen (uptime...)? Dann wäre eine setList nicht übel :P .

Andere Sache noch: wenn es eine einheitliche Basis gibt, müßte man evtl. auch einfach ein set DEVICE attrTemplate tasmota_pure_base vorneweg schießen können, um dann nur noch nachzupflegen, was jeweils anders ist...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 10 Dezember 2018, 17:50:11
Mal noch eine andere Idee. Wäre es möglich (oder geht das bereits) das autocreate auch pro Device setzen zu können? Also globales autocreate=1 und mit dem template setzt man das lokale DEVICE autocreate auf 0 so dass readingList nicht mehr aktualisiert wird?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 10 Dezember 2018, 18:31:32
So, proudly presenting:
So ist in fertig:

# shellybulb using original firmware. Tested with 1.3
name:shellybulb
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/color/0/command off\
  on:noArg shellies/DEVNAME/color/0/command on\
  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}\
  temp:colorpicker,CT,3000,10,6500 shellies/DEVNAME/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/; "shellies/DEVNAME/color/0/set {\"ison\":true,\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2)."\"blue\":".hex($3) }
deletereading DEVICE status_.*
attr DEVICE readingList shellies/DEVNAME/color/0/status:.* {json2nameValue($EVENT)}
attr DEVICE userReadings rgb {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
attr DEVICE webCmd on:off:brightness:temp:rgb
attr DEVICE genericDeviceType light
attr DEVICE icon light_control


Sprich: So werden die Werte für RGB hin- und zurückgerechnet. MyUtils kommt nicht in die Tüte: Es ist ja für die Nachwelt :-)
Das Template liefert die Picker für Brightness, "Weißtemperatur" (Nutzung schaltet in den Modus "Weißlicht") oder eben den RGB-Colorpicker, dann wird auf Farbe umgeschaltet.
Hat einmal Device-Löschen und Neuerkennung überstanden, sollte also veröffentlichungsfähig sein.

Nee, den Bug mit dem Auto-Create, dass permanent ein unschönes Reading dazu zaubert, will ich nicht übertünchen. Vielleicht ist er ja bald Geschichte.
Ja, das userReadings "rgb" entsteht erst, wenn ein neuer Status reinkommt. Dafür muss man mindestens einmal an- oder ausschalten. Erwähnte ich, dass ich am Schönsten fände, wenn das Template gleich bei dem AutoCreate angezogen wird?  ::) Dann läge auch gleich ein Event vor.

Danke für die Unterstützung!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 10 Dezember 2018, 21:16:28
So habe mal 2 templates angelegt eines wo nur die readingList gesetzt wird und eines für einen sonoff 4 Kanal inklusive setList, webCmd und stateFormat damit man alle 4 Kanäle in einem Device nutzen kann.

set Device p1on schaltet dann Kanal 1 ein, ...

Perfect wäre es wenn man mit dem template im device noch ein attribute autocreate=0 setzen könnte damit readingList auch bei global gesetztem autocreate nichts mehr ändert:

# basic tasmota device with unprefixed readings
name:tasmota_noprefix_pure_base
filter:TYPE=MQTT2_DEVICE
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO1:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO2:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO3:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
deleteReading DEVICE .*

name:tasmota_noprefix_sonoff_4ch
filter:TYPE=MQTT2_DEVICE
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO1:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO2:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO3:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
attr DEVICE setList \
  p1on:noArg cmnd/DEVICE/POWER1 on\
  p1off:noArg cmnd/DEVICE/POWER1 off\
  p2on:noArg cmnd/DEVICE/POWER2 on\
  p2off:noArg cmnd/DEVICE/POWER2 off\
  p3on:noArg cmnd/DEVICE/POWER3 on\
  p3off:noArg cmnd/DEVICE/POWER3 off\
  p4on:noArg cmnd/DEVICE/POWER4 on\
  p4off:noArg cmnd/DEVICE/POWER4 off
attr DEVICE webCmd p1on:p1off:p2on:p2off:p3on:p3off:p4on:p4off
attr DEVICE stateFormat {\
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))\
  . " P3:". FW_makeImage(lc ReadingsVal($name, "POWER3", "off"))\
  . " P4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off"))\
  . "</div>"
  }
attr DEVICE webCmd p1on:p1off:p2on:p2off:p3on:p3off:p4on:p4off

Auf Wunsch könnte ich auch noch ein Beispiel für ein Gerät mit 1 Relay und Temperatursensor bereitstellen. Gerade für Anfänger sollte es damit dann möglich sein beliebige Konstellationen abzubilden.

Was hier auch noch ergänzt werden sollte wäre die eventMap. Ich verwende ein angepasstes Tasmota welches on, off und toggle fhem-konform kleingeschrieben sendet und nicht ON, OFF, TOGGLE. So brauche ich die eventMap nicht.

Ich hoffe mein Code ist sonst soweit gut. Das FW_makeImage habe ich auch erst heute gefunden. Aber damit wird der Code richtig kurz. Das einzige was mir noch fehlt wäre, dass die Relay toggeln wenn das Symbol geklickt wird. Aber vielleicht hat da ja noch jemand eine Idee wie man das umsetzt?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 11 Dezember 2018, 11:13:23
So, hier mal das erste Lebenszeichen vom Shelly1.
Werde auf der Grundlage mal das Template fertigen.

2018.12.11 11:11:18 5: CONNECT: (0)(4)MQTT(4)(2)(0)<(0)(14)shelly1-12B9BD
2018.12.11 11:11:18 4: MQTT2_SERVER_192.168.1.20_20537 shelly1-12B9BD CONNECT V:4 keepAlive:60
2018.12.11 11:11:18 5: PUBLISH: (0)(31)shellies/shelly1-12B9BD/relay/0on
2018.12.11 11:11:18 4: MQTT2_SERVER_192.168.1.20_20537 shelly1-12B9BD PUBLISH shellies/shelly1-12B9BD/relay/0:on
2018.12.11 11:11:18 5: MQTT2_SERVER: dispatch autocreate:shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:on
2018.12.11 11:11:18 2: autocreate: define MQTT2_shelly1_12_9__ MQTT2_DEVICE shelly1_12B9BD
2018.12.11 11:11:18 2: autocreate: define FileLog_MQTT2_shelly1_12_9__ FileLog ./log/MQTT2_shelly1_12_9__-%Y.log MQTT2_shelly1_12_9__
2018.12.11 11:11:18 5: PUBLISH: (0)(17)shellies/announce{"id":"shelly1-12B9BD"}
2018.12.11 11:11:18 4: MQTT2_SERVER_192.168.1.20_20537 shelly1-12B9BD PUBLISH shellies/announce:{"id":"shelly1-12B9BD"}
2018.12.11 11:11:18 5: MQTT2_SERVER: dispatch autocreate:shelly1_12B9BD:shellies/announce:{"id":"shelly1-12B9BD"}
2018.12.11 11:11:18 5: SUBSCRIBE: (0)(3)(0)(16)shellies/command(1)
2018.12.11 11:11:18 4: MQTT2_SERVER_192.168.1.20_20537 shelly1-12B9BD SUBSCRIBE
2018.12.11 11:11:18 4:   topic:shellies/command qos:1


2018-12-11 11:11:18 Global global DEFINED MQTT2_shelly1_12_9__
2018-12-11 11:11:18 Global global DEFINED FileLog_MQTT2_shelly1_12_9__
2018-12-11 11:11:18 Global global ATTR MQTT2_shelly1_12_9__ readingList shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:.* shellies/shelly1-12B9BD/relay/0
2018-12-11 11:11:18 MQTT2_DEVICE MQTT2_shelly1_12_9__ shellies/shelly1-12B9BD/relay/0: on
2018-12-11 11:11:18 Global global ATTR MQTT2_shelly1_12_9__ readingList shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:.* shellies/shelly1-12B9BD/relay/0 shelly1_12B9BD:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
2018-12-11 11:11:18 MQTT2_DEVICE MQTT2_shelly1_12_9__ announce_id: shelly1-12B9BD
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Dezember 2018, 11:16:17
Zitat von: gvzdus am 10 Dezember 2018, 18:31:32
So, proudly presenting:
Gratulation, sieht gut aus, und ohne myUtils-Code auszukommen, ist richtig klasse!

patch dazu ist hier zu finden: https://forum.fhem.de/index.php/topic,91394.msg870402.html#msg870402 (https://forum.fhem.de/index.php/topic,91394.msg870402.html#msg870402)

Zitat von: miggun am 11 Dezember 2018, 11:13:23
So, hier mal das erste Lebenszeichen vom Shelly1.
Werde auf der Grundlage mal das Template fertigen.
:)

Zitat von: osr am 10 Dezember 2018, 21:16:28
So habe mal 2 templates angelegt eines wo nur die readingList gesetzt wird und eines für einen sonoff 4 Kanal inklusive setList, webCmd und stateFormat damit man alle 4 Kanäle in einem Device nutzen kann.
Das erste würde ich gerne mal so getestet wissen:
# basic tasmota device with unprefixed readings
name:tasmota_noprefix_pure_base
filter:TYPE=MQTT2_DEVICE
deletereading DEVICE .*attr DEVICE readingList \  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO.:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }


ZitatWas hier auch noch ergänzt werden sollte wäre die eventMap. Ich verwende ein angepasstes Tasmota welches on, off und toggle fhem-konform kleingeschrieben sendet und nicht ON, OFF, TOGGLE. So brauche ich die eventMap nicht.
M.E. sollten die templates die Standardkonfiguration abdecken, vor dem Einchecken sollte das also passen.

Für die weitere Entwicklung mal folgende Anregungen:

name:tasmota_noprefix_sonoff_4ch
filter:TYPE=MQTT2_DEVICE
set DEVICE attrTemplate tasmota_noprefix_pure_base
attr DEVICE setList \
  p1:on,off cmnd/DEVICE/POWER1 $EVTPART1\
  p2:on,off  cmnd/DEVICE/POWER2 $EVTPART1\
  p3:on,off  cmnd/DEVICE/POWER3 $EVTPART1\
  p4:on,off  cmnd/DEVICE/POWER4 $EVTPART1
attr DEVICE webCmd p1 on:p1 off:p2 on:p2 off:p3 on:p3 off:p4 on:p4 off
attr DEVICE stateFormat {\
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))\
  . " P3:". FW_makeImage(lc ReadingsVal($name, "POWER3", "off"))\
  . " P4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off"))\
  . "</div>"
  }
Was die Darstellung angeht, könnte cmdIcon noch was für dich sein, aber einfacher dürfte es mit einer passenden ReadingsGroup werden. Zu cmdIcon habe ich nichts gefunden, ob da ein anderes Trennzeichen definiert werden kann (wie bei eventMap).

Und bitte nutze wenn möglich zukünftig die code-Tags; das ist einfach besser zu lesen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 11 Dezember 2018, 11:20:18
Template Shelly1:

# shelly1 using original firmware.
name:shelly1
filter:TYPE=MQTT2_DEVICE
par:shelly11;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/shelly1/relay/0/command off\
  on:noArg shellies/shelly1/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 11 Dezember 2018, 11:30:46
So sieht es jetzt aus.

Shelly1
# shelly1 using original firmware.
name:shelly1
filter:TYPE=MQTT2_DEVICE
par:shelly11;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/shelly1/relay/0/command off\
  on:noArg shellies/shelly1/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state


Shelly2

# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
par:SHELLY2;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/SHELLY2/relay/0/command off\
  on:noArg shellies/SHELLY2/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVICE/relay/1/command off\
  on:noArg shellies/DEVICE/relay/1/command on
deleteattr DEVICE_CH2 getList


Shelly4Pro

# shelly4pro using original firmware
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:SHELLY4PRO;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/SHELLY4PRO/relay/0/command off\
  on:noArg shellies/SHELLY4PRO/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/0/power power1\
  shellies/DEVICE/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/SHELLY4PRO/relay/1/command off\
  on:noArg shellies/SHELLY4PRO/relay/1/command on
attr DEVICE getList shellies/DEVICE/relay/1/power power2\
  shellies/DEVICE/relay/1/energy energy2
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH3
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVICE/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/SHELLY4PRO/relay/2/command off\
  on:noArg shellies/SHELLY4PRO/relay/2/command on
attr DEVICE getList shellies/DEVICE/relay/2/power power3\
  shellies/DEVICE/relay/2/energy energy3
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVICE/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/SHELLY4PRO/relay/3/command off\
  on:noArg shellies/SHELLY4PRO/relay/3/command on
attr DEVICE getList shellies/DEVICE/relay/3/power power4\
  shellies/DEVICE/relay/3/energy energy4
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Dezember 2018, 11:36:39
Zitat von: miggun am 11 Dezember 2018, 11:20:18
Template Shelly1:
Klasse!

(war noch nicht fertig mit tippen zum shelly1, aber die Anmerkungen/Änderungen gelten entsprechend auch für die anderen templates).

Kannst du mal folgendes bitte testen:
# shelly1 using original firmware.
name:shelly1
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state

Anmerkung: bisher waren alle Parameter ausschließlich groß geschrieben, und in der bulb heißt es jetzt DEVNAME, das wäre m.E. ein möglicher Standard. Und irgendwie habe ich das Gefühl, dass der Parameter einheitlich sein sollte (hier ist er evtl. nur zufällig gleich; das könnte aber abweichen, wenn jemand das Teil vorher umbenennt...).

Aus dem Code von gvzdus, für den Fall, dass es nicht so recht will:
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 11 Dezember 2018, 11:54:10
Mist, wenn ich das Template auf das automatisch angelegte MQTT2-DEVICE anwende, wird es nicht richtig angelegt, Da autocreate den falschen Eintrag verwendet.

So sieht es aus:
defmod MQTT2_shelly1_12_9__ MQTT2_DEVICE shelly1_12B9BD
attr MQTT2_shelly1_12_9__ IODev MQTT2_SERVER
attr MQTT2_shelly1_12_9__ readingList shellies/MQTT2_shelly1_12_9__/relay/0:.* state\
shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:.* shellies/shelly1-12B9BD/relay/0
attr MQTT2_shelly1_12_9__ room MQTT2_DEVICE
attr MQTT2_shelly1_12_9__ setList off:noArg shellies/shelly1/relay/0/command off\
  on:noArg shellies/shelly1/relay/0/command on


So sollte es aussehen:
defmod MQTT2_shelly1_12B9BD MQTT2_DEVICE shelly1_12B9BD
attr MQTT2_shelly1_12B9BD IODev MQTT2_SERVER
attr MQTT2_shelly1_12B9BD readingList shellies/shelly1-12B9BD/relay/0:.* state\
shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:.* shellies/shelly1-12B9BD/relay/0
attr MQTT2_shelly1_12B9BD room MQTT2_DEVICE
attr MQTT2_shelly1_12B9BD setList off:noArg shellies/shelly1-12B9BD/relay/0/command off\
  on:noArg shellies/shelly1-12B9BD/relay/0/command on
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Dezember 2018, 11:59:14
Zitat von: miggun am 11 Dezember 2018, 11:54:10
Mist, wenn ich das Template
Welches? Eines von deinen oder das von mir modifizierte ;) ?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 11 Dezember 2018, 16:56:56
 
ZitatWäre es möglich (oder geht das bereits) das autocreate auch pro Device setzen zu können?
Habe autocreate in MQTT2_DEVICE eingebaut: die Voreinstellung ist 1, falls es auf 0 gesetzt wird, dann unterbleibt die Erweiterung der ReadingList.
Weiterhin habe ich die Voreinstellung fuer autocreate in MQTT2_SERVER von 0 auf 1 geaendert.
In MQTT2_CLIENT bliebt sie auf 0.

Ich meine immer noch, dass per Voreinstellung readingList mit { json2nameValue($EVENT, 'Praefix_') } erweitert werden sollte, aber mit AttrTemplate und autocreate=0 hat man die Moeglichkeit, es fuer einzelne Geraete besser zu loesen.

ZitatAlso habe jetzt mal in my.template folgendes für meine Wemos hinterlegt:
Habs mit dem Namen tasmota_WemosD1 hinzugefuegt.

ZitatSo, proudly presenting:
Hinzugefuegt.

ZitatSo habe mal 2 templates angelegt [...] Perfect wäre es wenn man mit dem template im device noch ein attribute autocreate=0 setzen könnte damit readingList auch bei global gesetztem autocreate nichts mehr ändert:
Hinzugefuegt, und jeweils mit "attr DEVICE autocreate 0" ergaenzt.

Mit den weiteren Shellies bin ich verwirrt, da brauche ich eine klare Ansage zum Einchecken.
Btw.: will nicht jemand die Patenschaft fuer mqtt2.template uebernehmen? :)
   
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Dezember 2018, 17:11:15
ZitatMit den weiteren Shellies bin ich verwirrt, da brauche ich eine klare Ansage zum Einchecken.
Da war mind. in dem shelly1-template von miggun noch ein bug drin, wenn ich das richtig deute. Wenn du sicher beurteilen kannst, dass meine Fassung paßt, könnte man die auch einchecken, den Rest eher nicht (da geht es m.E. noch ein wenig durcheinander).

ZitatBtw.: will nicht jemand die Patenschaft fuer mqtt2.template uebernehmen? (https://forum.fhem.de/Smileys/default/smiley.gif (https://forum.fhem.de/Smileys/default/smiley.gif))
:o ??? ??? ??? ???
Puhhh, ich vermute mal, du denkst an jemanden bestimmten...
An sich glaube ich, zwischenzeitlich sowohl mqtt(2) wie auch die Mechanismen im template selbst halbwegs verstanden zu haben. Was mich aber schreckt, sind die Administrationswerkzeuge. Die wollte ich eigentlich nicht auch noch lernen ::) . Mit sowas hatte ich jedenfalls bislang nie was zu tun...
Aber an sich würde ich erwarten, dass das mit der Einpflegerei irgendwann auch mal deutlich weniger wird, und dann steigt eben wieder das Risiko, dass "derjenige" das dann irgendwann in der Zukunft falsch macht, weil er die Werkzeuge nicht beherrscht.

Wenn das mit dem Einarbeiten und derh Handhabung der Tools halbwegs überschaubar ist: Weil du mich so nett fragst...

EDIT:
Noch was anderes: Ich hatte - leider erfolglos - versucht, die set-Funktion in MQTT2_DEVICE entsprechend dem code in Dummy so umzubauen, dass man ein Reading setzt (und nicht state), wenn der Name in der setList auftaucht (mit einem Doppelpunkt dahinter). An sich sah das nicht schwierig aus, aber leider hat es nicht funktioniert und ich kann nicht genug Perl, um das in einigermaßen überschaubarer Zeit zu fixen...
Vielleicht hättest du 10 Min über, um das anzusehen?

Konkret will ich erreichen, dass z.B. bei der zigbee2mqtt-Bridge ein Reading "permit_join" mit dem Wert "true" oder "false" auftaucht, statt eben "permit_join" ohne weitere Angabe in "state".
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 11 Dezember 2018, 19:59:40
Zitat von: Beta-User am 11 Dezember 2018, 11:36:39
Klasse!

(war noch nicht fertig mit tippen zum shelly1, aber die Anmerkungen/Änderungen gelten entsprechend auch für die anderen templates).

Kannst du mal folgendes bitte testen:
# shelly1 using original firmware.
name:shelly1
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state



Funktioniert.  :)
Jetzt legt er Shelly1 sauber an, mit Adresse und allem. Ich musste nur das Backslash hinter off ergänzen, da er sonst meckert.
So wie ich das sehe ist Beta-User der perfekte Mann um diese templates zu betreuen, oder?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Dezember 2018, 08:06:51
Zitat von: miggun am 11 Dezember 2018, 19:59:40
Funktioniert.  :)
Auch hier ein Dankeschön für die Rückmeldung.

Kannst du die übrigen, noch fehlenden templates für deine Shellys auch noch entsprechend überarbeiten und dann (getestet ;) ) hier posten?

Wenn möglich auch ein "unified" 4-Kanal-template? (also alle Kanäle in einem Device, das ganze möglichst kompakt...)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 12 Dezember 2018, 08:54:23
Getestet und funktioniert.

Shelly4Pro:
# shelly4pro using original firmware
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/0/power power1\
  shellies/DEVNAME/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVNAME/relay/1/command off\
  on:noArg shellies/DEVNAME/relay/1/command on
attr DEVICE getList shellies/DEVNAME/relay/1/power power2\
  shellies/DEVNAME/relay/1/energy energy2
attr DEVICE comment Channel 2 for DEVICE, see also DEVICE, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVNAME/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/DEVNAME/relay/2/command off\
  on:noArg shellies/DEVNAME/relay/2/command on
attr DEVICE getList shellies/DEVNAME/relay/2/power power3\
  shellies/DDEVNAME/relay/2/energy energy3
attr DEVICE comment Channel 3 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVNAME/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/DEVNAME/relay/3/command off\
  on:noArg shellies/DEVNAME/relay/3/command on
attr DEVICE getList shellies/DEVNAME/relay/3/power power4\
  shellies/DEVNAME/relay/3/energy energy4
attr DEVICE comment Channel 4 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH3


Shelly2:
# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVNAME/relay/1/command off\
  on:noArg shellies/DEVNAME/relay/1/command on
deleteattr DEVICE_CH2 getList


Shelly1:
# shelly1 using original firmware.
name:shelly1
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state


Ich würde ja für den Shelly4Pro gerne ein 5. und 6. Device anlegen. Muss nicht im Template sein. Aber da kommen wieder meine mangelnden Kenntnisse.
Shelly4Pro liefert power1-power4 und Energy1-energy4. Wie kann ich diese summieren?
Damit könnte ich/man ein Device power (Gesamt) und ein Device energy (Gesamt anlegen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Dezember 2018, 09:20:56
Danke, ich verpatche das heute abend (da ist mir auch was in zigbee2mqtt doch nicht recht gelungen, patch dafür anbei...)

Was dein 5. Device angeht (wofür ist das 6.?): Einfach die Readings aller Kanäle einfangen und dann ein userreadings-Attribut mit anlegen, das die Infos für beide Angaben addiert. Beispiel für userreadings im template war in der shelly-Bulb.

Und nochmal: Es gibt Leute, die gerne _nur ein_ Device haben wollen, in dem alles drin ist (alle 4 Kanäle, Summen...). Vielleicht tobst du dich da nochmal aus (kannst ja mal versuchen, meinen 4-Kanal-Code für den Wemos-Tasmota zu adaptieren, ansonsten auf Basis des codes von hier:
Zitat von: osr am 10 Dezember 2018, 21:16:28
So habe mal 2 templates angelegt eines wo nur die readingList gesetzt wird und eines für einen sonoff 4 Kanal inklusive setList, webCmd und stateFormat damit man alle 4 Kanäle in einem Device nutzen kann.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 12 Dezember 2018, 09:34:44
Das mit einem Device für alle 4 Kanäle klingt auf jeden Fall sehr gut. Da werde ich mich mal dran geben. Muss aber hier noch ein paar Kabel verlegen, damit ich alles umrüsten kann.
Habe das mit dem addieren gelöst. Falls es einer nutzen will...
Shelly4Pro plus Gesamt-Power und Gesamt-Energy:
# shelly4pro using original firmware
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/0/power power1\
  shellies/DEVNAME/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVNAME/relay/1/command off\
  on:noArg shellies/DEVNAME/relay/1/command on
attr DEVICE getList shellies/DEVNAME/relay/1/power power2\
  shellies/DEVNAME/relay/1/energy energy2
attr DEVICE comment Channel 2 for DEVICE, see also DEVICE, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVNAME/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/DEVNAME/relay/2/command off\
  on:noArg shellies/DEVNAME/relay/2/command on
attr DEVICE getList shellies/DEVNAME/relay/2/power power3\
  shellies/DDEVNAME/relay/2/energy energy3
attr DEVICE comment Channel 3 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVNAME/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/DEVNAME/relay/3/command off\
  on:noArg shellies/DEVNAME/relay/3/command on
attr DEVICE getList shellies/DEVNAME/relay/3/power power4\
  shellies/DEVNAME/relay/3/energy energy4
attr DEVICE comment Channel 4 for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3, DEVICE_POWER and DEVICE_ENERGY
copy DEVICE DEVICE_POWER
attr DEVICE_POWER userReadings power { (ReadingsVal("DEVICE_POWER","power1",0)+ReadingsVal("DEVICE_POWER","power2",0)+ReadingsVal("DEVICE_POWER","power3",0)+ReadingsVal("DEVICE_POWER","power4",0));; }
attr DEVICE_POWER stateFormat power
attr DEVICE comment Power for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3, DEVICE_CH4 and DEVICE_ENERGY
copy DEVICE DEVICE_ENERGY
attr DEVICE_ENERGY userReadings energy { (ReadingsVal("DEVICE_ENERGY","energy1",0)+ReadingsVal("DEVICE_ENERGY","energy2",0)+ReadingsVal("DEVICE_ENERGY","energy3",0)+ReadingsVal("DEVICE_ENERGY","energy4",0));; }
attr DEVICE_ENERGY stateFormat energy
attr DEVICE comment Energy for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3, DEVICE_CH4 and DEVICE_POWER
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Dezember 2018, 09:36:24
Das kannst du noch nicht abschließend getestet haben: userreadings kann man nur einmal anlegen, es müssen beide in die eine Zeile ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 12 Dezember 2018, 09:39:06
Wollte ich gerade testen. Habe es jetzt manuell angelegt.
Wenn es dann passt noch schnell abändern. Danke für den Tip.
Das war der Grund für's posten. Allein bin ich da doch aufgeschmissen.

Edit: Manuell bekomme ich es hin, aber leider nicht ins Template gegossen. Er haut da DEVNAME kaputt und schmeißt energy und power wild durcheinander.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Dezember 2018, 14:18:46
Hab' mich mal versucht:
# shelly4pro using original firmware
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/0/power power1\
  shellies/DEVNAME/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVNAME/relay/1/command off\
  on:noArg shellies/DEVNAME/relay/1/command on
attr DEVICE getList shellies/DEVNAME/relay/1/power power2\
  shellies/DEVNAME/relay/1/energy energy2
attr DEVICE comment Channel 2 for DEVICE, see also DEVICE, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVNAME/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/DEVNAME/relay/2/command off\
  on:noArg shellies/DEVNAME/relay/2/command on
attr DEVICE getList shellies/DEVNAME/relay/2/power power3\
  shellies/DDEVNAME/relay/2/energy energy3
attr DEVICE comment Channel 3 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVNAME/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/DEVNAME/relay/3/command off\
  on:noArg shellies/DEVNAME/relay/3/command on
attr DEVICE getList shellies/DEVNAME/relay/3/power power4\
  shellies/DEVNAME/relay/3/energy energy4
attr DEVICE comment Channel 4 for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3 and DEVICE_POWER
copy DEVICE DEVICE_POWER
attr DEVICE_POWER userReadings \
power { (ReadingsVal("DEVICE_POWER","power1",0)+ReadingsVal("DEVICE_POWER","power2",0)+ReadingsVal("DEVICE_POWER","power3",0)+ReadingsVal("DEVICE_POWER","power4",0))},\  energy { (ReadingsVal("DEVICE_POWER","energy1",0)+ReadingsVal("DEVICE_POWER","energy2",0)+ReadingsVal("DEVICE_POWER","energy3",0)+ReadingsVal("DEVICE_POWER","energy4",0))}attr DEVICE_POWER stateFormat P:power E:energy
attr DEVICE_POWER comment Power for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4

Aber:
Vom Gefühl her gehört da noch eine readingList dazu, damit die Daten auch ankommen (oder klappt das)?
Was mir an sich nicht gefällt, ist die "Umnummerierung". Da die firmware intern das erste Relais mit "0" belabelt, sollte man diese Zählweise m.E. insgesamt (auch bei Energy etc) beibehalten (ich vermute, da kommt ein Teil deiner Probleme her).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 12 Dezember 2018, 21:33:34
Zitat von: Beta-User am 11 Dezember 2018, 11:16:17


# basic tasmota device with unprefixed readings
name:tasmota_noprefix_pure_base
filter:TYPE=MQTT2_DEVICE
deletereading DEVICE .*
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO.:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
attr DEVICE autocreate 0


ja das INFO. ist cool. Habe es getestet funktioniert tadellos.
Dazu das autocreate per device von rudolkoenig ist natürlich auch super.


name:tasmota_noprefix_sonoff_4ch
filter:TYPE=MQTT2_DEVICE
set DEVICE attrTemplate tasmota_noprefix_pure_base
attr DEVICE setList \
  p1:on,off cmnd/DEVICE/POWER1 $EVTPART1\
  p2:on,off  cmnd/DEVICE/POWER2 $EVTPART1\
  p3:on,off  cmnd/DEVICE/POWER3 $EVTPART1\
  p4:on,off  cmnd/DEVICE/POWER4 $EVTPART1
attr DEVICE webCmd p1 on:p1 off:p2 on:p2 off:p3 on:p3 off:p4 on:p4 off
attr DEVICE stateFormat {\
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))\
  . " P3:". FW_makeImage(lc ReadingsVal($name, "POWER3", "off"))\
  . " P4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off"))\
  . "</div>"\
  }


Auch das habe ich soweit getestet und funktioniert sehr schön und elegant, das set DEVICE attrTemplate darin macht den Code noch kompakter und besser zu warten.

cmdIcon und ReadingsGroup schaue ich mir mal noch an bezüglich schalten über die Icons, hast du vermutlich gemeint.

Werde das nochmal durchtesten und noch ein template für relay+sensor machen. Die 3 Templates poste ich dann morgen. Das WemosD1 template kann dann raus.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Dezember 2018, 22:21:35
Hallo zusammen!

Die gesammelten Werke sind im wesentlichen jetzt hier (https://forum.fhem.de/index.php/topic,91394.msg871189.html#msg871189) verarbeitet, Danke auch für die diversen Rückmeldungen zu meinen Vorschlägen.

Offen wären dann vorläufig noch:- 4-fach-Shelly als ein Device (bzw. ggf. mit der Erweiterung um ein 5. Device mit den Energy- etc-Werten)
- Shelly2 im roller-Mode (sollte sich auch wieder umstellen lassen, oder ;) )

@osr
Mir ist nicht klar, was die tasmota-Patche bewirken:
Wenn es andere Sendebefehle erforderlich macht oder andere Schreibweisen der Rückmeldungen, kann das uU. Schwierigkeiten machen (und wenn es nur bei der Anzeige ist). Das sollte daher möglichst ohne Modifikation gehen (oder mit einem comment, was zu tun ist, dass es geht).
Rest ist "nice-to-have".
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 12 Dezember 2018, 22:37:29
OK das passt soweit alles. Habe es doch noch heute geschafft...

Von meiner Seite sollte das template tasmota_WemosD1 wieder raus.

Dann das template tasmota_noprefix_pure_base so geändert werden:





# basic tasmota device with unprefixed readings
name:tasmota_noprefix_pure_base
filter:TYPE=MQTT2_DEVICE
attr DEVICE autocreate 0
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO.:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
deletereading DEVICE .*



sowie tasmota_noprefix_ sonoff_4ch in tasmota_noprefix_4ch weil das für jedes Tasmota Gerät mit 4 Kanälen funktioniert:



# tasmota 4 channel as one FHEM device

name:tasmota_noprefix_4ch
filter:TYPE=MQTT2_DEVICE
set DEVICE attrTemplate tasmota_noprefix_pure_base
attr DEVICE setList \
  p1:on,off cmnd/DEVICE/POWER1 $EVTPART1\
  p2:on,off  cmnd/DEVICE/POWER2 $EVTPART1\
  p3:on,off  cmnd/DEVICE/POWER3 $EVTPART1\
  p4:on,off  cmnd/DEVICE/POWER4 $EVTPART1
attr DEVICE webCmd p1 on:p1 off:p2 on:p2 off:p3 on:p3 off:p4 on:p4 off
attr DEVICE stateFormat {\
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))\
  . " P3:". FW_makeImage(lc ReadingsVal($name, "POWER3", "off"))\
  . " P4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off"))\
  . "<>"\
  }



und schließlich neu tasmota_noprefix_1ch+motion+SI7021

# tasmota device with one relay, one motion sensor via switch
# and one SI7021 combined temperature and humidity sensor
# as one FHEM device

name:tasmota_noprefix_1ch+motion+SI7021
filter:TYPE=MQTT2_DEVICE
set DEVICE attrTemplate tasmota_noprefix_pure_base
attr DEVICE setList \
  on:noArg cmnd/DEVICE/POWER1 on\
  off:noArg  cmnd/DEVICE/POWER1 off
attr DEVICE stateFormat {\
  my $state = lc ReadingsVal($name, "POWER2", "off");\
  my $devStateIcon = 'building_security@green';\
  if ($state eq "on") {\
    $devStateIcon = 'building_security@red';\
  }\
  "<div>" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
    . FW_makeImage($devStateIcon) . sprintf(\
    "&nbsp;&nbsp;[Temp: %.1f°C / Feucht: %.0f%%]",\
    ReadingsVal($name,"SI7021_Temperature",0),\
    ReadingsVal($name,"SI7021_Humidity",0)\
    ) . "<>"\
  }



webCmd ist hier wohl nicht notwendig. Jedenfalls erscheinen bei mir on und off auch so.


Mit dem Satz an tasmota_noprefix templates sollte, mit etwas Anpassung, vieles was mit Wemos und Konsorten über Tasmota möglich ist sehr einfach in einem Gerät in FHEM umgesetzt werden können. Auch meine Markisensteuerung habe ich damit umgesetzt. 2 Relay + Temperatursensor für draußen. Auch das Shellygerät sollte mit den Ideen in einem Gerät umgesetzt werden können. Davon wollte ich mir auch noch welche zu legen. Wie seid ihr denn mit denen so zufrieden? Würde die wohl aber eher mit Tasmota einsetzen ;-)


Vielen vielen Dank an Beta-User für die Ideen und an rudolkoenig für das schnelle umsetzen von autocreate auf MQTT2_DEVICE.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Dezember 2018, 22:51:50
Danke für die Rückmeldung, hoffe es auf die Schnelle richtig eingearbeitet zu haben und Rudi hat das noch mitgekriegt.

Sonst gibt's die letzte Fassung dann morgen oder so...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 12 Dezember 2018, 22:54:22
Shelly4Pro bekomme ich nicht ans laufen mit dem Template. Es erscheint ein PopUp, wo ich DEVNAME vergeben soll. Egal in welcher Variante ich es eingebe, er legt es nicht sauber an. Vorher hat es ja gut funktioniert. Ich denke, wir lassen Power raus. Wenn einer das haben will, soll er fragen oder lesen. Wenn ich das hin bekomme, bekommt das jeder hin.
Shelly2 im roller-Modus kommt noch. Ich muss da noch eins bestellen, was wirklich die eine Rolllade fährt, die nicht über die Zentralsteuerung läuft.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 12 Dezember 2018, 22:56:21
Zitat von: Beta-User am 12 Dezember 2018, 22:21:35

@osr
Mir ist nicht klar, was die tasmota-Patche bewirken:
Wenn es andere Sendebefehle erforderlich macht oder andere Schreibweisen der Rückmeldungen, kann das uU. Schwierigkeiten machen (und wenn es nur bei der Anzeige ist). Das sollte daher möglichst ohne Modifikation gehen (oder mit einem comment, was zu tun ist, dass es geht).
Rest ist "nice-to-have".

OK Tasmota verwendet ON nicht on wie sonst bei FHEM. Das wollte ich einheitlich haben. Deswegen (und für andere Voreinstellungen wie WIFI Passwort etc.) verwende ich eine selbst kompilierte Tasmota Firmware.

Habe das aber getestet es ist egal ob ich an ein Tasmota Device ON oder on sende. Das selbe gilt für off und toggle. Das heißt für meine Templates sollte die eventMap wie bei den anderen tasmota templates verwendet ergänzt werden. Dann funktioniert es sauber auch mit der Standard-Tasmota Firmware. Also in tasmota_noprefix_pure_base muss noch

attr DEVICE eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }

dazu. Bei mir hat das keine Auswirkungen und bei Standardfirmware wird dann das OFF bzw. ON auf off, on umgesetzt, so dass auch FHEM zufrieden ist und die Stati wie gewohnt in FHEM sind.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Dezember 2018, 23:37:24
Danke für eure Rückmeldungen.

Das mit Tasmota hatte ich so vermutet, die Ergänzung kommt dann noch (Rudi hatte den "alten" patch schon eingepflegt).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 13 Dezember 2018, 09:10:05
@Rudi
Kurz ein Gedanke: Sowas in der Form wie unten  taucht im MQTT-Kontext ständig auf. Wäre es nicht einfacher, direkt über das Modul lowercase für (ON|OFF|On|Off) zu verwenden, sobald irgend ein Reading (incl. state) (von extern, also idR. vom Gerät kommend) auf genau einen der Werte gesetzt werden soll?

(Kann sein, dass das Änderungen bei dem zigbee-devStateIcon nach sich zöge, aber sonst fällt mir im Moment auf die Schnelle nichts ein, was unangenehme Nebenwirkungen anginge).

Zitat von: osr am 12 Dezember 2018, 22:56:21

attr DEVICE eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 13 Dezember 2018, 09:47:38
Mein Plan ist, dass das Framework (FHEMWEB) auf beides reagiert.
Ich habe aus diesem Grund in images/openautomation/iconalias.txt ON und OFF eingetragen, d.h. diese werden schon passend angezeigt, was noch fehlt ist das kuenstlich erzeugte toggle, d.h. wenn man auf dem Symbol klickt ON als on zu erkennen und OFF zu senden, und kein off. Ist etwas mehr als ein einzeiler, und ich habe noch nicht die Gelegenheit gehabt es anzugehen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 13 Dezember 2018, 10:25:56
@Rudi: Danke für die Rückmeldung, schön, dass das Thema insgesamt auf dem Radar ist. Eilt nicht, solange es irgedwie konkret am Ende gelöst wird :) .

@gvzdus:
Danke für die Infos und den screenshot von "nebenan", sind schon im Wiki zu finden :) .

@all:
- Im Wiki würden sich m.E. noch Shelly2 als Beispiele gut machen: Würde das dann im Gesamtkontext vor Tasmota darstellen (da Original-Hersteller-firmware) und drei Arten vorstellen wollen, wie man das Teil mit attrTemplate konfiguriert: Einheitsdevice mit 2 Kanälen, gesplittet je Kanal und Roller-Mode.
Das ist m.E. dann hinreichend, um die Möglichkeiten prototypisch darzustellen, Darstellung im Grunde ähnlich wie bei der shellybulb.

- (Voraussichtlich) am WE werde ich dann mal erste Gehversuche mit svn machen, Zugang wurde erteilt...

Schönen Tag allseits,

Beta-User
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 13 Dezember 2018, 19:57:22
Zitat von: rudolfkoenig am 13 Dezember 2018, 09:47:38
Mein Plan ist, dass das Framework (FHEMWEB) auf beides reagiert.
Ich habe aus diesem Grund in images/openautomation/iconalias.txt ON und OFF eingetragen, d.h. diese werden schon passend angezeigt, was noch fehlt ist das kuenstlich erzeugte toggle, d.h. wenn man auf dem Symbol klickt ON als on zu erkennen und OFF zu senden, und kein off. Ist etwas mehr als ein einzeiler, und ich habe noch nicht die Gelegenheit gehabt es anzugehen.

Also für Tasmota (wo ja toggle nicht künstlich erzeugt werden muss weil die Geräte das ja machen) ist es vollkommen egal ob mit einem cmd/... on ON off OFF toggle oder TOGGLE oder Kombinationen gesendet werden. Was macht Shelly mit Originalfirmware? Gibt es dazu Infos?

Zitat von: Beta-User am 13 Dezember 2018, 09:10:05
Kurz ein Gedanke: Sowas in der Form wie unten  taucht im MQTT-Kontext ständig auf. Wäre es nicht einfacher, direkt über das Modul lowercase für (ON|OFF|On|Off) zu verwenden, sobald irgend ein Reading (incl. state) (von extern, also idR. vom Gerät kommend) auf genau einen der Werte gesetzt werden soll?

Ja das würde die Sache vereinheitlichen, sofern das nicht irgendwelche negativen Auswirkungen im Code hat. Aber eventMap sind dafür überall wirklich nicht schön. Gut wäre es wenn aber auch TOGGLE in toggle dann umgesetzt würde. Auch das kann von einem Switch/Button gesendet werden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Dezember 2018, 07:42:19
Auch hier die kurze Info:

habe das template-file eben etwas überarbeitet. Gebt doch bitte nach einem update heute Rückmeldung, ob/wie euch das gefällt.

Ankündigung: Es kommt  bei Gelegenheit insgesamt ein neuer Thread dazu, sonst ist die Diskussion ggf. zu sehr verteilt hier, sonstwo und zigbee), habe aber leider grade nicht mehr die Zeit und Ruhe dazu. Aber die bisher Beteiligten dürfen/sollen selbstredend vorläufig auch noch hier...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: dkreutz am 14 Dezember 2018, 19:00:11
Hier dann noch ein Vorschlag für ein ShellyPlug-Template - der hat einen Kanal mit Strommessung, also quasi ein halber Shelly2. Ich habe das Shelly2-Template genommen und den copy-Teil für den zweiten Kanal weggelassen:


# shellyplug using original firmware.
name:shellyplug
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;ShellyPlug name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/power power
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: osr am 14 Dezember 2018, 19:26:55
Hatte in der letzten Version die 3 templates nochmal komplett gepostet. Die scheinen aber noch nicht im Repository zu sein.

Bitte beachten, das <> sollte eigentlich ein < dann / dann div dann > sein aber das macht die Forumsoftware immer weg.

In der letzten Version hatte ich auch autocreate 0 an den Anfang und deleteReading an den Schluss gesetzt, so dass da nicht irgendwas dazwischen passieren kann.

Das einzige was noch hinzu muss ist


attr DEVICE eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }


Dann sollte das passen auch für Standard-Tasmotas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Dezember 2018, 22:24:49
Hallo zusammen,

habe eben ein update ins svn geschoben und hoffe, den gesamten input von heute einigermaßen verarbeitet zu haben.

ACHTUNG: es sind die ersten desc:-Anweisungen drin, vermutlich wird daher auch ein update vom attrTemplate-Modul benötigt! (laden lies sich das auch so, aber wesentlich mehr habe ich nicht getestet!) Am besten daher einfach die Auszüge ohne die desc-Anweisungen verwenden, wenn jemand vor dem update von morgen noch was machen will).

Kurzfassung:- shellyplug dazugefügt (DANKE!)
- dto. für den tasmota+motion+si7021 (hatte ich irgendwann gedacht drin zu haben, die anderen sollten eigentlich schon drin gewesen sein, allerdings ggf. unter etwas anderem Namen und s.u.)

Bei den tasmota-Sachen stand im Topic noch DEVICE drin. Das war in jedem Fall nicht richtig (siehe https://forum.fhem.de/index.php/topic,94434.msg871955.html#msg871955), ich habe daher eine ungetestete Variante der shelly-DEVNAME-Extraktion versucht. Bitte um Rückmeldung!

Ansonsten ist das interne Weiterverweisen ausgeweitet. So wird jetzt bei allen Tasmotas das 09x-template vorab durchlaufen, was z.B. dann generell auch die "vermissten"
deleteReading DEVICE .*
attr DEVICE autocreate 0
und die Basis-readingList setzt.
Wenn dann was "vorläufig falsch" ist, wird einfach die nächste gleichnamige Anweisung drübergebügelt, nach dem Motto: last beats all.

Das macht es erst mal etwas unübersichtlicher (wenn das über 2 oder 3 Stufen läuft), die Ergebnisse aber hoffentlich in sich konsistent und leichter zu pflegen.

@Rudi: habe das nicht getestet, gehe aber davon aus, dass die Parameter (par:) nur jeweils innerhalb eines template verfügbar sind, also auf jeder Stufe neu ermittelt werden müssen?

Großes Danke an alle geduldigen Tester, seht mir nach, dass ich mich grad nicht noch in die Tasmota-firmware einarbeiten will, um das vorab alles nachzuvollziehen!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Dezember 2018, 23:31:51
Kurze Frage noch: Ist das getList aus den shellys wirklich so korrekt?

attr DEVICE getList shellies/DEVNAME/relay/power power


Nach meinen (bisher nicht erfolgreichen) Versuchen mit der get-Funktion müßte es eher so sein ??? :
attr DEVICE getList power shellies/DEVNAME/relay/power
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Dezember 2018, 23:37:44
Es funktioniert so auf jeden Fall.
Hier mal die funktionierende Leistungserfassung der Küchenbeleuchtung Shelly2:

defmod Kueche_Licht_Leistung MQTT2_DEVICE shellyswitch-32B268
attr Kueche_Licht_Leistung IODev MQTT2_SERVER
attr Kueche_Licht_Leistung getList shellies/shellyswitch-32B268/relay/power power
attr Kueche_Licht_Leistung readingList shellyswitch_32B268:shellies/shellyswitch-32B268/relay/power:.* power
attr Kueche_Licht_Leistung room 01_Küche,MQTT2_DEVICE,Messwerte
attr Kueche_Licht_Leistung stateFormat power
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Dezember 2018, 00:58:13
Danke für die Rückmeldung.

Ist aber in der Darstellung komisch, ich bekomme da ein dropDown-Feld mit dem topic-String?!?

Hätte eher gedacht, dass es aussehen sollte wie das hier:
attr Kueche_Licht_Leistung getList power:noArg shellies/shellyswitch-32B268/relay/power power


Kannst das ja mal so ändern, dann verstehst du, was ich von der optischen Seite her meine.

Aber jetzt ist bei mir der Groschen gefallen, Danke!

@Rudi:
Hilfe...
Jetzt weiß ich zwar, wie ich einen get-Befehl für zigbee2mqtt zusammenbauen muß, aber a) sieht es besch... aus und b) habe ich keine Ahnung, was ich für "Reading" hinten reinschreiben soll, wenn da ein json zurückkommt. log, log.* habe ich versucht (so beginnen alle Readings, die dadurch angelegt werden) :o .

Schön wäre es, wenn wir das wie setList bauen könnten mit $EVENT etc. und einem eindeutigen Trenner (oder Klammerung), der das Topic vom Sendeinhalt und dem Reading (-Array) abgrenzt. Den Topic braucht in der Anzeige in FHEMWEB keiner...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Dezember 2018, 10:34:49
So.
Eben noch etwas mit den neuen desc-Optionen rumgespielt, daher gabs nochmal ein update im svn. Wer testen will, sollte diese Version nutzen, ist einfach schöner 8) ...

Da man mit <br> auch mehrzeilige Beschreibungen generieren kann, fände ich es am wenigsten fehleranfällig, zukünftig den Status (Experimentell, testing...) in die Beschreibung mit unterzubringen; dto. für konkrete Geräte, firmwareversionen etc.. Das verhindert, dass durch die Änderung eines Namens Weiterleitungen zu Bruch gehen können und macht updates für getestete Geräte einfacher.

@Rudi:
Da ist noch eine Anregung mit drin, so eine Art Einleitung zuzulassen (name:<filename>). Habe keine Ahnung, ob das viel Aufwand wäre und über mehrere Dateien funktioniert, könnte aber hilfreich sein, um weitere Info anzuzeigen. Geht aber auch so...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 15 Dezember 2018, 11:04:27
ZitatSchön wäre es, wenn wir das wie setList bauen könnten mit $EVENT etc. und einem eindeutigen Trenner (oder Klammerung), der das Topic vom Sendeinhalt und dem Reading (-Array) abgrenzt.
Kannst du mir bitte einen konkreten Beispiel nennen, indem du die raw Daten (gesendet+empfangen) hier anhaenst, und das was du im Dialog sehen willst.

ZitatDa ist noch eine Anregung mit drin, so eine Art Einleitung zuzulassen (name:<filename>)
Damit sehe ich zwei Probleme:
- ich will diese Hilfe nicht zu wiki/commandref Ersatz verkommen lassen. Es waere sinnvoller einen attrTemplate Abschnitt in der MQTT2_DEVICE Commandref-Abschnitt einzufuegen, was dann beim Auswahl von attrTemplate eingeblendet wird. Ich will das Einblenden auf etwas dezenteres umbauen, als das aktuell der Fall ist.
- fuer ein Geraet koennen/werden attrTemplate Eintraege aus mehreren .template Dateien (fuer FHEMWEB, alexa, etc, alles noch TODO) zusammengemischt, da wuerde eine "MQTT2-Einfuehrung" verwirren.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 15 Dezember 2018, 12:09:01
Zitathabe das nicht getestet, gehe aber davon aus, dass die Parameter (par:) nur jeweils innerhalb eines template verfügbar sind, also auf jeder Stufe neu ermittelt werden müssen?
Ja. Ein Template faengt mit einer name: Zeile an. Ausnahme ist die letzte vor dem name: befindliche Kommentarzeile, falls kein desc: vorhanden ist.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Dezember 2018, 12:25:13
Moin Rudi,

vorab: magst du diesen Thread (https://forum.fhem.de/index.php/topic,94495.msg872201.html#msg872201) anpinnen?

Der Vorschlag, die MQTT2-DEVICE-cref zu nutzen, gefällt mir, bei Gelegenheit kommt da dann ein Vorschlag.

Was getList angeht:
Die rawEvents finden sich in der beigefügten file.
list vom Bridge-Device:
defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_pi bridgeRegexp zigbee_pi:zigbee2mqtt/(0x[A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee_pi getList zigbee_pi:zigbee2mqtt/bridge/config/devices message_.*
attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT) }\
  zigbee_pi:zigbee2mqtt/bridge/state:.* state
attr MQTT2_zigbee_pi room MQTT2_DEVICE
attr MQTT2_zigbee_pi setList permit_join:true,false zigbee_pi:zigbee2mqtt/bridge/config/permit_join $EVTPART1\
  remove:textField zigbee_pi:zigbee2mqtt/bridge/config/remove $EVTPART1\
  log_level:debug,info,warn,error zigbee_pi:zigbee2mqtt/bridge/config/log_level $EVTPART1\
  rename:textField zigbee_pi:zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  network_map:raw,graphviz zigbee_pi:zigbee2mqtt/bridge/networkmap  $EVTPART1\
  devicelist:noArg zigbee_pi:zigbee2mqtt/bridge/config/devices

setstate MQTT2_zigbee_pi network_map
setstate MQTT2_zigbee_pi 2018-12-15 11:58:59 message device incoming
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_1_friendly_name 0x90fd9ffffe65db16
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_1_ieeeAddr 0x90fd9ffffe65db16
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_1_model LED1650R5
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_1_type Router
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_2_friendly_name 0x90fd9ffffe0bcd51
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_2_ieeeAddr 0x90fd9ffffe0bcd51
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_2_model LED1650R5
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_2_type Router
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_3_friendly_name 0x90fd9ffffefe2b91
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_3_ieeeAddr 0x90fd9ffffefe2b91
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_3_model TRADFRI remote control
setstate MQTT2_zigbee_pi 2018-12-15 11:56:26 message_3_type EndDevice
setstate MQTT2_zigbee_pi 2018-12-15 11:52:49 state network_map
setstate MQTT2_zigbee_pi 2018-12-15 11:58:59 type pairing

Die getList funktioniert weitgehend so wie im list dargestellt, wobei ich eben mit diversen Varianten (der Reading-Angabe rumgespielt hatte: log, log_.*, message, message_.*), aber immer die timeout-message erhalte. Gehe davon aus, dass das entweder ist, weil die Antwort auf einem anderen Topic kommt oder eben wg. des JSON-Formats.

Von der Darstellung her wäre mir das so lieber, wie es bei "set" ist.
Folgendes sieht m.E. stringent aus (in FHEMWEB):
attr MQTT2_zigbee_pi getList network_map:raw,graphviz zigbee_pi:zigbee2mqtt/bridge/networkmap  $EVTPART1 $EVTPART1\
  devicelist:noArg zigbee_pi:zigbee2mqtt/bridge/config/devices log

(2*$EVTPART1, da einmal zu versenden, einmal reading, auf das gewartet wird)
Damit wäre auch als normaler FHEM-Befehl (vom Aufbau her, über den Effekt mag man streiten) sinnig: "get MQTT2_zigbee_pi networkmap raw".

Im Dialogfeld wäre dann super, wenn untereinander alle sich aus dem JSON ergebenden Readings (sortiert) gelistet würden (hier: message_.*); auf das "message_" könnte man dabei verzichten (v.a., wenn das anders die Kompabilität mit normalen Strings bricht).

Hoffe, das ist so nachvollziehbar?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 15 Dezember 2018, 13:01:47
Zitat von: Beta-User am 15 Dezember 2018, 00:58:13
Danke für die Rückmeldung.

Ist aber in der Darstellung komisch, ich bekomme da ein dropDown-Feld mit dem topic-String?!?

Hätte eher gedacht, dass es aussehen sollte wie das hier:
attr Kueche_Licht_Leistung getList power:noArg shellies/shellyswitch-32B268/relay/power power


Kannst das ja mal so ändern, dann verstehst du, was ich von der optischen Seite her meine.

Aber jetzt ist bei mir der Groschen gefallen, Danke!

Wenn ich ehrlich bin fällt mir gerade kein Unterschied zwischen den beiden Varianten auf. Worauf muss ich achten?
Das war ja der alte:
attr Kueche_Licht_Leistung getList shellies/shellyswitch-32B268/relay/power power

Jetzt habe ich Deinen drin:
attr Kueche_Licht_Leistung getList power:noArg shellies/shellyswitch-32B268/relay/power power
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Dezember 2018, 13:15:26
Kommt denn auf die zweite Variante eine vernünftige Antwort, wenn du das set nutzt?
Sehen beide Varianten in FHEMWEB gleich aus? (bei mir mit den Modulversionen von gestern eindeutig nicht).

Wenn dieselbe Antwort kommt, würde ich die templates direkt so umbauen! Im Moment besteht sonst das Risiko, dass das demnächst in der bisherigen Form nicht mehr funktioniert...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 15 Dezember 2018, 13:35:34
Zitat von: Beta-User am 15 Dezember 2018, 13:15:26
Kommt denn auf die zweite Variante eine vernünftige Antwort, wenn du das set nutzt?
Sehen beide Varianten in FHEMWEB gleich aus? (bei mir mit den Modulversionen von gestern eindeutig nicht).

Wenn dieselbe Antwort kommt, würde ich die templates direkt so umbauen! Im Moment besteht sonst das Risiko, dass das demnächst in der bisherigen Form nicht mehr funktioniert...
Beide genau gleich.
Aber ich kann nur das Ergebnis beurteilen. Von der Programmierung habe ich ja so gut wie keine Ahnung.
Da beides gleiche Ergebnisse liefert, dass nehmen, was programmiertechnisch safe ist.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Dezember 2018, 14:44:04
THX, Korrektur ist im svn ;) .

Bitte um Prüfung&Rückmeldung, möglichst für alle shelly-Varianten.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 15 Dezember 2018, 20:23:16
@Beta-User

Ich habe heute die Gelegenheit genutzt, ein wenig mit getList,setList,readingList sowie bridgeRegexp,readingList zu experimentieren.

Bis jetzt hat sich dabei folgende attr-Festlegung ergeben:

attr MQTT2_myMqttClient bridgeRegexp\
zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_myMqttClient getList\
devicelist:noArg log zigbee2mqtt/bridge/config/devices\
networkmap:graphviz,raw networkmap_result zigbee2mqtt/bridge/networkmap $EVTPART1
attr MQTT2_myMqttClient readingList\
zigbee2mqtt/bridge/state:.* state\
zigbee2mqtt/bridge/config/devices:.* {}\
zigbee2mqtt/bridge/config/log_level:.* log_level\
zigbee2mqtt/bridge/config/permit_join:.* permit_join\
zigbee2mqtt/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
zigbee2mqtt/bridge/log:.* log\
zigbee2mqtt/bridge/networkmap:.* {}\
zigbee2mqtt/bridge/networkmap/graphviz:.* networkmap_result\
zigbee2mqtt/bridge/networkmap/raw:.* networkmap_result
attr MQTT2_myMqttClient setList\
log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1\
permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1\
remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1\
rename:textField zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
devicelist:noArg zigbee2mqtt/bridge/config/devices\
networkmap:graphviz,raw zigbee2mqtt/bridge/networkmap $EVTPART1



Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 26 Dezember 2018, 21:46:24
Es gab ein Update von Shelly, jetzt wird energy nicht mehr gemeldet. Weder beim Shelly4Pro noch beim Shelly2. Der Rest funktioniert wie vorher.

Wobei nicht ganz wie vorher, jetzt sendet auch der Shelly4Pro stetig seinen Status, auch wenn kein Ausgang aktiv ist.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 10 Januar 2019, 22:18:11
So, hier wie versprochen erst mal die Internals vom shelly2 im Roller-Mode:

Internals:
   CFGFN     
   CID        shellyswitch_32BD01
   DEF        shellyswitch_32BD01
   DEVICETOPIC MQTT2_shellyswitch_32__01
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 166
   MQTT2_SERVER_TIME 2019-01-10 22:16:46
   MSGCNT     166
   NAME       Lea_Rollladen
   NR         1785
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-01-10 21:56:46   announce_fw_ver 20190103-091640/v1.4.4@165d718b
     2019-01-10 21:56:46   announce_id     shellyswitch-32BD01
     2019-01-10 21:56:46   announce_ip     192.168.1.2
     2019-01-10 21:56:46   announce_mac    86F3EB32B
     2019-01-10 21:56:46   announce_new_fw false
     2019-01-10 21:56:46   online          true
     2019-01-10 22:16:46   pos             100
     2019-01-10 22:16:46   power           0.00
     2019-01-10 22:16:46   shellies/shellyswitch-32BD01/roller/0 stop
Attributes:
   IODev      MQTT2_SERVER
   readingList shellyswitch_32BD01:shellies/shellyswitch-32BD01/online:.* online
shellyswitch_32BD01:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0:.* shellies/shellyswitch-32BD01/roller/0
shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0/pos:.* pos
shellyswitch_32BD01:shellies/shellyswitch-32BD01/relay/power:.* power
   room       MQTT2_DEVICE


Event monitor
2019-01-10 22:34:39 MQTT2_DEVICE Lea_Rollladen shellies/shellyswitch-32BD01/roller/0: open
2019-01-10 22:34:39 MQTT2_DEVICE Lea_Rollladen power: 1.28
2019-01-10 22:34:40 MQTT2_DEVICE Lea_Rollladen shellies/shellyswitch-32BD01/roller/0: stop
2019-01-10 22:34:40 MQTT2_DEVICE Lea_Rollladen power: 0.00
2019-01-10 22:34:41 MQTT2_DEVICE Lea_Rollladen shellies/shellyswitch-32BD01/roller/0: close
2019-01-10 22:34:41 MQTT2_DEVICE Lea_Rollladen power: 1.08
2019-01-10 22:34:42 MQTT2_DEVICE Lea_Licht off
2019-01-10 22:34:42 MQTT2_DEVICE Lea_Licht shellies/shelly1-12B9BD/relay/0: off
2019-01-10 22:34:43 MQTT2_DEVICE Lea_Rollladen pos: 0
2019-01-10 22:34:43 MQTT2_DEVICE Lea_Rollladen shellies/shellyswitch-32BD01/roller/0: stop
2019-01-10 22:34:43 MQTT2_DEVICE Lea_Rollladen power: 0.00
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Januar 2019, 07:21:45
Moin,
wenn du magst und nach gestern vormittag ein update gemacht hast, kannst du Rückmeldung geben, wie dir das von torte hier (https://forum.fhem.de/index.php/topic,94495.msg884104.html#msg884104) vorgeschlagene (und bereits via svn verteilte) template gefällt :) .

Einen ht hatte ich auch dazugepackt (ergänzt aber "nur" ein devStateIcon).

Fehlt eigentlich nur noch der 4-er als Einheitsdevice (wer das braucht, kann sich aber auch in den beiden tasmota-templates bedienen) :) .

Oder gibt es zwischenzeitlich weitere shellys?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: LudgerR am 11 Januar 2019, 11:17:04
Hallo,

Habe gerade meinen zweiten shelly1 für mqtt aktiviert und diesmal das vorgefertigte Template für shelly1 benutzt. Dabei ist mir aufgefallen das ein Reading für ../relay/0  zunächst erstellt, später jedoch nicht mehr abgedated wird.
Deswegen habe ich bei mir die readingList um

shelly1_2BE282:shellies/shelly1-2BE282/relay/0:.* shellies/shelly1-2BE282/relay/0

ergänzt.

Fhem hatte ich gestern noch per ,,update" aktualisiert.

Folgend die automatisch erstellte Config meines Shellys, die ich bis auf die o.g. Änderung nur um
event-on-change-reading  ergänzt habe.


defmod MQTT2_shelly1_2BE282 MQTT2_DEVICE shelly1_2BE282
attr MQTT2_shelly1_2BE282 IODev MQTT2_FHEM_Server
attr MQTT2_shelly1_2BE282 event-on-change-reading .*
attr MQTT2_shelly1_2BE282 model A_10_shelly1
attr MQTT2_shelly1_2BE282 readingList shellies/shelly1-2BE282/relay/0:.* state\
shelly1_2BE282:shellies/shelly1-2BE282/input/0:.* shellies/shelly1-2BE282/input/0\
shelly1_2BE282:shellies/shelly1-2BE282/relay/0:.* shellies/shelly1-2BE282/relay/0\
shelly1_2BE282:shellies/shelly1-2BE282/online:.* online\
shelly1_2BE282:shellies/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }
attr MQTT2_shelly1_2BE282 room MQTT2_DEVICE
attr MQTT2_shelly1_2BE282 setList off:noArg shellies/shelly1-2BE282/relay/0/command off\
  on:noArg shellies/shelly1-2BE282/relay/0/command on

setstate MQTT2_shelly1_2BE282 on
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_fw_ver 20190103-091629/v1.4.4@165d718b
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_id shelly1-2BE282
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_ip 192.168.69.68
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_mac 3E71BF2BE282
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 announce_new_fw false
setstate MQTT2_shelly1_2BE282 2019-01-11 10:19:00 online true
setstate MQTT2_shelly1_2BE282 2019-01-11 10:38:30 shellies/shelly1-2BE282/input/0 0
setstate MQTT2_shelly1_2BE282 2019-01-11 10:38:30 shellies/shelly1-2BE282/relay/0 on
setstate MQTT2_shelly1_2BE282 2019-01-11 10:38:30 state on


Ist das ursprünglich verwaiste Reading ../relay/0  bei mir nur Zufall oder ist es beabsichtigt?

VG


Ergänzung:

Habe eine weiteren shelly1 konfiguriert und die folgende Beobachtung gemacht:

Das ../relay/0  ist zunächst in der readingList  enthalten.  Nach Ausführung von set attrTemplate ist es immernoch vorhanden.
Jedoch nach dem ersten reboot des shelly1 verschwindet es.
Nach meiner anschließenden manuellen Hinzufügung bleibt es erhalten (auch nach weiteren reboots).

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Januar 2019, 11:30:15
Zitat von: LudgerR am 11 Januar 2019, 11:17:04
Ist das ursprünglich verweiste Reading ../relay/0  bei mir nur Zufall oder ist es beabsichtigt?
Vorhandene Readings werden (in dem Fall bzw. durch die derzeitige Fassung des template) nicht gelöscht, es ist also verwaist.

Ich würde allerdings dazu tendieren, das entweder (per template?) zu löschen, oder zusätzlich auf ein reading relay0 (ohne den MQTT-Pfad) zu mappen - Präferenz auf löschen.
Interessant ist aber das andere "Zeug":
- Braucht es das "announce"-Prefix?
- Macht es Sinn, den Schalter auf ein eigenes Reading zu mappen (input0)? Könnte man evtl. brauchen, um manuelle Schaltungen zu detektieren...
(die "0" für die Readings deswegen, weil es für die mehrkanaligen für mehr Klarheit sorgt, wo was herkommt).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: LudgerR am 11 Januar 2019, 12:42:25


Ergänzung:

Habe eine weiteren shelly1 konfiguriert und die folgende Beobachtung gemacht:

Das ../relay/0  ist zunächst in der readingList  enthalten.  Nach Ausführung von set attrTemplate ist es immernoch vorhanden.
Jedoch nach dem ersten reboot des shelly1 verschwindet es.
Nach meiner anschließenden manuellen Hinzufügung bleibt es erhalten (auch nach weiteren reboots).

Die anderen Readings wie announce werden ja automatisch erzeugt. 
Ich kann damit leben, dass ich  /relay/0  anschließend händisch hinzufügen muss.
Insgesamt finde ich es etwas verwirrend.

VG
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Januar 2019, 12:57:15
Merke: readingList ist nicht dasselbe wie Reading.Die readingList wird durch das attrTemplate neu geschrieben, diese wird aber geändert und enthält ein mapping der message auf "state".

Durch einen Reboot des shelly werden keine Angaben in FHEM gelöscht, es werden höchstens durch die damit verbundenen Messages weitere Änderungen durch autocreate vorgenommen.

Du solltest mal den Verkehr auf dem MQTT-Server mithören (mosquitto_sub kann das auch bei einem MQTT2_SERVER).

Auf Basis des lists mal folgender erweiterte Vorschlag:
name:A_10_shelly1
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
deleteReading DEVICE .*
attr DEVICE model A_10_shelly1
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: LudgerR am 11 Januar 2019, 14:13:15
Ich hatte bei einem weiteren shelly mqtt Aktivierung offenbar einen snapshot mit "Raw Definition"  gemacht bevor 
"set attrTemplate" beendet war und mich damit selbst verwirrt (Asche auf mein Haupt!).

Eine Verkürzung der Readings finde ich gut.   

Die Frage ist nur

  input0 relay0  oder   input/0 relay/0

Die erste Variante passt mehr zu TASMOTA, die andere mehr zu Letscontrolit.

Zur Zeit bin ich noch in der Findungsphase welche Firmware ich auf meinen Sonoff und Shelly Geräten einsetzen werde. Um ein Votum zugeben bin ich noch zur kurz im MQTT Thema.

Bzgl. mosquito_sub  lässt sich der seperat installieren oder nur zusammen mit mosquito.  Die installation von MQTT.fix habe ich nicht weiterverfolgt nachdem dieser ein X11 Window oder ähnliches verlangte.

Ein link für die einfache Installation und Nutzung von mosquito_sub  wäre hilfreich.

VG




Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Januar 2019, 14:26:07
Hier geht es um die shelly-firmware. Da die mit MQTT gut kann und man ihr offensichtlich auch das "nach hause telefonieren" abgewöhnen kann, würde ich für diese Geräte auch die originale FW behalten (schon aus versicherungsrechtlichen Gründen).

Wie geschrieben war input0 etc. bedingt dadurch, dass ich das ggf. auch als Basis nehme für mehrkanalige templates und dann keine Verwirrung entstehen sollte. Ansonsten ist man in der Benennung ziemlich frei, sinnvoll sollte es eben sein. Dabei finde ich "besondere" Zeichen aber immer "schwierig", vor allem den dir-Marker "/". Wenn ihr einen Trenner haben wollt, wie wäre es mit relay_0?
Die "Kompabilität" mit anderen firmwares finde ich jetzt nicht sooo wichtig, kann das aber gerne berücksichtigen (mal abgesehen von "/", das gibt es nur auf klare Ansage, dass ihr das wollt und einer "Umleitung" (z.B. von .../relay/0 auf relay_1; die Zahlenwerte sollten konsistent sein und die Benennung international/englisch/ascii)).

mosquitto_sub (und ..._pub) ist Teil von mosquitto_clients und kann gesondert installiert werden. Allerdings kann insbesondere auch der MQTT2_SERVER für debugging genutzt werden und das direkte Absetzen von Befehlen (in den Tasmota-templates wird das teilweise gemacht; wenn ihr das hier auch haben wollt, um z.B. Statusmeldungen einmalig abzufragen usw., dann kann ich das ggf. berücksichtigen (aber nicht testen, bitte möglichst fertigen Code!)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 11 Januar 2019, 14:36:13
ZitatAllerdings kann insbesondere auch der MQTT2_SERVER für debugging genutzt werden [...]
Gilt fuer MQTT2_SERVER und MQTT2_CLIENT:
- Ebene 1, alle topics und messages: "attr mqtt2_server rawEvents", z.Bsp. im Event-Monitor (evtl. mit Filter) verfolgbar
- Ebene 2, kompletter MQTT Datenaustausch: "attr mqtt2_server verbose 5", hier wird ins FHEM-Log geschrieben, das kann man aber auch im Event-Monitor verfolgen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Januar 2019, 14:45:14
Zitat von: rudolfkoenig am 11 Januar 2019, 14:36:13
Gilt fuer MQTT2_SERVER und MQTT2_CLIENT:
- Ebene 1, alle topics und messages: "attr mqtt2_server rawEvents", z.Bsp. im Event-Monitor (evtl. mit Filter) verfolgbar
- Ebene 2, kompletter MQTT Datenaustausch: "attr mqtt2_server verbose 5", hier wird ins FHEM-Log geschrieben, das kann man aber auch im Event-Monitor verfolgen.
Thx, hab's hier entsprechend verarbeitet: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#MQTT2_SERVER_und_MQTT2_CLIENT_f.C3.BCr_Debugging_nutzen
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: LudgerR am 11 Januar 2019, 19:53:59
mosquitto_sub (und ..._pub)

war genau dass was ich zum Testen als MQTT Beginner gebraucht habe. Die Frage nach einem Link beantworte ich nun mal selbst:

https://www.open-homeautomation.com/de/2016/06/09/install-an-mqtt-broker-on-your-raspberry-pi/
(https://www.open-homeautomation.com/de/2016/06/09/install-an-mqtt-broker-on-your-raspberry-pi/)

http://www.steves-internet-guide.com/mosquitto_pub-sub-clients/
(http://www.steves-internet-guide.com/mosquitto_pub-sub-clients/)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Januar 2019, 20:12:27
Aber nochmal zur Sicherheit: Man kann dazu auch den MQTT2-Server direkt nutzen. Wer neu einsteigt, sollte vermutlich den von Rudi aufgezeigten Weg nutzen (ich bin da Gewohnheitstier, deswegen fällt mir immer zuerst der _sub ein, das ist aber keine qualitative Aussage...).

Für kleine Installationen ist der MQTT2-Server innerhalb FHEM die "leichtere" Lösung, was Systemperformance und Einstelloptionen angeht, daher ist der Hinweis auf mosquitto (und seine Installation) hier m.E. irreführend.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 12 Januar 2019, 07:24:29
Hier noch kurz die Kommandos, die ich im Roller-Mode verwende.

attr Rollladen setList open:noArg shellies/shellyswitch-32BD01/roller/0/command open\
  stop:noArg shellies/shellyswitch-32BD01/roller/0/command stop\
  close:noArg shellies/shellyswitch-32BD01/roller/0/command close\
  rc:noArg shellies/shellyswitch-32BD01/roller/0/command rc\
  10:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 10\
  20:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 20\
  30:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 30\
  40:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 40\
  50:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 50\
  60:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 60\
  70:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 70\
  80:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 80\
  90:noArg shellies/shellyswitch-32BD01/roller/0/command/pos 90
attr Rollladen stateFormat pos


rc-rekalibrieren
der Rest sollte klar sein
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Januar 2019, 07:51:07
Das mit der Calibration kann ich aufnehmen, wenn man das häufiger benötigt (?).
Aber was spricht gegen den Slider für die Level-Abgaben wie von torte vorgeschlagen?
(da könnte man bei Bedarf evtl. die Intervalle vergrößern, z.B. auf 5-er-Schritte).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 12 Januar 2019, 07:55:01
Da spricht gar nichts gegen. Den möchte ich auch einrichten, muss mich aber erst einlesen. Bin ja nicht so fit und das ist das Ergebnis, was ich alleine hin bekommen habe.
Jetzt bin ich dabei mich in den Slider einzulesen.

Edit: Slider eingerichtet und läuft super.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: LudgerR am 12 Januar 2019, 10:24:16
ad #181

Sorry,

aber die Tools mosquitto_pub und mosquitto_sub  sind auf dem Pi derartig einfach zu installieren und intuitiv anzuwenden, dass ich mich einfach nur ärgere sie nicht vorher verwendet zu haben.

Ich habe ja nicht propagiert mosquitto statt MQTT2-Server zu verwenden. Die Installationsanweisung im Link beschränkt sich ja auf mosquitto_pub & sub  und nicht auf die komplette Installation von mosquitto.

Die Nutzung der mosquitto tools  im Zusammenspiel mit MQTT2 Server und Bridge erleichtert m.E. schneller die Funktionalität von MQTT2 Server und Bridge zu verstehen. 

Ehrlich gesagt die Beschwörung, nur Bordmittel von fhem zu benutzen, macht mich eher neugierig auch mal mosquitto im Zusammenspiel mit MQTT2 auszuprobieren.  Bisher war dies nicht in meinem Focus.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 12 Januar 2019, 15:04:44
Hallo,
ich bin ja immer noch ein ziemlicher Anfänger was FHEM betrifft, hab aber mit Hilfe des Forums schon sehr viel erreicht. Unter Anderem auch mehrere Shelly's (original), Sonoff's (mit Tasmota), ...

Jetzt hab ich aber eine (wohl ziemlich blöde) Frage. Ich nutze zwar schon von Anfang an die Leistungsmessung der Shelly's, aber erst Heute ist mir aufgefallen, daß die gar keinen Gesamtverbrauch (kWh) als Wert (Reading) liefern.

Sehe ich den Wald vor lauter Bäumen nicht, oder gibt's die "Energy"-Werte nur über MQTT und/oder Tasmota-FW?

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 12 Januar 2019, 18:34:20
Verstehe ich jetzt nicht.
Meinst Du über den Shelly-Web-Zugang? Energy wird beim Shelly ja gesendet (über MQTT). Somit wird die Arbeit Wh gesendet, das ist Leistung mal Zeit.

Edit: Ich sehe es gerade auch. Problem, Shelly macht gerade alle nase lang Updates. nach enigen Updates ist energy weg. Entweder umbenannt, oder wird nicht mehr übertragen. Nächstes Update energy wieder da. Ist etwas nervig.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 13 Januar 2019, 12:52:13
@miggun:
Es wäre nett, wenn du von dem shelly2 im roller-Modus mal ein list hier oder im Thread zu AutoShuttersControl (https://forum.fhem.de/index.php/topic,92628.0.html) einstellen könntest (am besten zwei, einmal vor Anwendung des templates und einmal danach).

Dann können wir das template gleich so gestalten, dass die Geräte ohne große Klimmzüge mit dem AutoShuttersControl-Modul genutzt werden können ;) . Im Moment habe ich bereits statt pos ein pct-Reading vorgesehen und ein setStateEvent-Attribut. Wenn du magst, kannst du dafür gerne den Tester machen, aber Achtung: Das ist ein sehr mächtiges Modul mit vielen Einstellmöglichkeiten (ergo: Erst mal ausgiebig Doku lesen!)...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 13 Januar 2019, 23:13:47
@miggun:
Ja, z.B. über das Shelly Web-IF, oder auch in FHEM (ich nutze das Shelly-Modul).

Sowohl beim
Shelly 2 (Gestern Neu erhalten, FW: 20181011-110617/v1.3.0@7da7a3c1), als auch beim
Shelly 4Pro (seit zwei Monaten in Betrieb, FW: 20181031-101313/v1.3.5@62608979)
gibt es keine Energy-Werte.

FW-Update habe ich noch nicht gemacht. Muß ich mal versuchen.

Über MQTT hab ich das bisher nicht getestet.

Aber wenn ich Dich richtig verstanden habe, dann müßten die Energy-Werte über alle Wege zur Verfügung stehen (wenn sie denn da sind), oder?

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 13 Januar 2019, 23:30:39
Hab gerade ein FW-Update beim
Shelly 2 auf 20190103-091640/v1.4.4@165d718b
und
Shelly 4Pro auf 20181217-130631/v1.4.2@cc724b51
gemacht.

Aber immer noch keine Energy-Werte.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 07:52:05
@Beta-User:
Ohne Template habe ich das List in den entsprechenden Beitrag kopiert. Dann habe ich auf Fhem ein Update gefahren und shelly2 ausgewählt. Das ist aber nur für Schalter. Irgendwas muss ich noch laden, oder liege ich falsch.

@:Guzzi-Charlie
Ja, seit den letzten Updates scheint Energy weg zu sein. Bei mir geht es gerade auch nicht. Hatte ich aber jetzt schon ein paar mal. Dann kam wieder ein Update von Shelly und es ging wieder. Darauf hoffe ich gerade.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 07:56:54
Es sollte dieses template sein: A_11b_shelly2_roller
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 08:11:54
Jetzt war es da. Trotz Update und shutdown restart war es nicht sofort da.
Bei mir steht noch pos drin. Muss ich mein Ursprüngliches Device erst löschen?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 08:33:51
Nein, löschen sollte nicht erforderlich sein.

Aber da ist ein Fehler drin, sorry! Lösche mal in Zeile 366 das abschließende "\". Deswegen wird das nächste attr nicht ausgeführt...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 09:10:26
In dem Template hier?
/opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template

# shelly2 using original firmware in roller mode.
name:A_11b_shelly2_roller
filter:TYPE=MQTT2_DEVICE
desc:shelly2 using original firmware. <br>NOTE: shelly2 roller operated, change$
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m$
attr DEVICE comment shelly2 roller operated
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command open\
  close:noArg shellies/DEVNAME/roller/0/command close\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pos:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1
attr DEVICE readingList shellies/DEVNAME/roller/0/pos:.* state\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr DEVICE devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter$
attr DEVICE model A_11b_shelly2_roller
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 09:19:43
"Im Prinzip" ja, aber das scheint nicht die letzte Version zu sein. Kannst auch die aus dem svn (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template) nehmen, habe vorhin ein update hochgeladen (ist dann ab morgen früh kurz vor 8 im allg. update drin).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 09:37:11
Habe ich im template geändert.
Irgendwas hat er aber nicht übernommen, weil im template ja jetzt pct steht.
Jetzt sieht es so aus:

Internals:
   CID        shellyswitch_32BD01
   DEF        shellyswitch_32BD01
   DEVICETOPIC Rollladen
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 589
   MQTT2_SERVER_TIME 2019-01-14 09:36:14
   MSGCNT     589
   NAME       Rollladen
   NR         74
   STATE      0
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-01-12 16:09:27   1               0
     2019-01-14 08:12:11   announce_fw_ver 20190103-091640/v1.4.4@165d718b
     2019-01-14 08:12:11   announce_id     shellyswitch-32BD01
     2019-01-14 08:12:11   announce_ip     192.168.1.28
     2019-01-14 08:12:11   announce_mac    86F3EB32BD01
     2019-01-14 08:12:11   announce_new_fw false
     2019-01-14 08:12:11   online          true
     2019-01-14 09:31:41   pos             0
     2019-01-14 09:36:14   power           0.00
     2019-01-12 16:09:29   shellies/shellyswitch-32BD01/input/0 0
     2019-01-14 09:36:14   shellies/shellyswitch-32BD01/roller/0 stop
     2019-01-14 09:36:14   state           0
Attributes:
   IODev      MQTT2_SERVER
   comment    shelly2 roller operated
   devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
   getList    shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0/power:.* power
shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0/pos:.* pos
   model      A_11b_shelly2_roller
   readingList shellies/shellyswitch-32BD01/roller/0/pos:.* state
  shellies/shellyswitch-32BD01/status/0/rollers:.* power
  shellies/shellyswitch-32BD01/online:.* online
  shellies/shellyswitch-32BD01/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0:.* shellies/shellyswitch-32BD01/roller/0
shellyswitch_32BD01:shellies/shellyswitch-32BD01/relay/power:.* power
   room       MQTT2_DEVICE
   setList    open:noArg shellies/shellyswitch-32BD01/roller/0/command open
  close:noArg shellies/shellyswitch-32BD01/roller/0/command close
  stop:noArg shellies/shellyswitch-32BD01/roller/0/command stop
  pos:slider,0,1,100 shellies/shellyswitch-32BD01/roller/0/command/pos $EVTPART1
   stateFormat state
   webCmd     stop:open:close:pos:rc
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 10:12:34
War das die Version aus dem update oder aus dem svn? Wenn update:
Zitat von: Beta-User am 14 Januar 2019, 08:33:51Lösche mal in Zeile 366 das abschließende "\". Deswegen wird das nächste attr nicht ausgeführt...
Wenn es das nicht ist, liegt noch irgendwo anders der Hund begraben. Ansonsten solltest du auch mal alle Readings löschen, da sich die Namen und der Prefix geändert haben. Also
deleteReading Rollladen .*(Würde wohl auch im template zweckmäßig sein).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 10:24:48
War das aus dem svn, Version heute 7:35. Da war das \ schon raus.
Ich warte mal, bis morgen das Update drin ist. deleteReading Rollladen .* hat es auch nicht gelöst.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 10:40:54
Hmm, das ist wirklich seltsam, weil eigentlich die Attribute teilweise überschrieben werden sollten.

Hattest du die template-Reinititialisierung gemacht oder FHEM neu gestartet nach der Änderung des templates?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 10:42:09
Ja, hatte in Fhem danach den Befehl update gefolgt von shutdown restart ausgeführt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 10:45:14
Kannst do dann bitte nochmal nachsehen, ob Zeile 366 noch korrekt ist?
Denn dann könnte es sein, dass die svn-Version wieder von der update-Version überschrieben wurde.
(7:35GMT=8:35MEZ, die aus dem svn war also noch nicht im update)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 10:51:01
So sieht es bei mir gerade im Template aus:

# shelly2 using original firmware in roller mode.
name:A_11b_shelly2_roller
filter:TYPE=MQTT2_DEVICE
desc:shelly2 using original firmware. <br>NOTE: shelly2 roller operated, change settings first!
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment shelly2 roller operated
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command open\
  close:noArg shellies/DEVNAME/roller/0/command close\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pct:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1\
  DoRecalibration:noArg shellies/DEVNAME/roller/0/command rc\
attr DEVICE readingList shellies/DEVNAME/roller/0/pos:.* pct\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr DEVICE devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80$
attr DEVICE stateFormat pct
attr DEVICE setStateList open close stop
attr DEVICE model A_11b_shelly2_roller


Ist tatsächlich das \ wieder drin. Lösche es jetzt raus und probiere noch mal.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 10:54:14

Bekomme jetzt folgende Fehlermeldung.

Global symbol "$JSONMAP" requires explicit package name (did you forget to declare "my $JSONMAP"?) at (eval 67) line 1.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 11:20:07
OK, dann machen wir das raus, ist in dem Fall m.E. eh' nicht erforderlich, also sollte die betr. Zeile so aussehen:
shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 11:39:51
Jetzt funktioniert das Template. :)

Einzige, was nicht ganz so schön ist, wenn man auf einen Wert fährt, wird bis der Wert erreicht ist set66 oder set 50 oder set40 angezeigt, bis der Wert tatsächlich erreicht ist uns die Position gesendet wird.

Internals:
   CID        shellyswitch_32BD01
   DEF        shellyswitch_32BD01
   DEVICETOPIC Lea_Rollladen
   IODev      MQTT2_SERVER
   LASTInputDev MQTT2_SERVER
   MQTT2_SERVER_MSGCNT 242
   MQTT2_SERVER_TIME 2019-01-14 11:39:16
   MSGCNT     242
   NAME       Lea_Rollladen
   NR         74
   STATE      66
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-01-14 11:00:40   announce_fw_ver 20190103-091640/v1.4.4@165d718b
     2019-01-14 11:00:40   announce_id     shellyswitch-32BD01
     2019-01-14 11:00:40   announce_ip     192.168.1.28
     2019-01-14 11:00:40   announce_mac    86F3EB32BD01
     2019-01-14 11:00:40   announce_new_fw false
     2019-01-14 11:00:40   online          true
     2019-01-14 11:39:16   pct             66
     2019-01-14 11:29:41   pos             100
     2019-01-14 11:39:16   power           0.00
     2019-01-14 11:39:16   shellies/shellyswitch-32BD01/roller/0 stop
Attributes:
   IODev      MQTT2_SERVER
   comment    shelly2 roller operated
   devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
   getList    shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0/power:.* power
shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0/pos:.* pos
   model      A_11b_shelly2_roller
   readingList shellies/shellyswitch-32BD01/roller/0/pos:.* pct
  shellies/shellyswitch-32BD01/status/0/rollers:.* power
  shellies/shellyswitch-32BD01/online:.* online
  shellies/shellyswitch-32BD01/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
shellyswitch_32BD01:shellies/shellyswitch-32BD01/roller/0:.* shellies/shellyswitch-32BD01/roller/0
shellyswitch_32BD01:shellies/shellyswitch-32BD01/relay/power:.* power
   room       03_Lea,MQTT2_DEVICE
   setList    open:noArg shellies/shellyswitch-32BD01/roller/0/command open
  close:noArg shellies/shellyswitch-32BD01/roller/0/command close
  stop:noArg shellies/shellyswitch-32BD01/roller/0/command stop
  pct:slider,0,1,100 shellies/shellyswitch-32BD01/roller/0/command/pos $EVTPART1
  DoRecalibration:noArg shellies/shellyswitch-32BD01/roller/0/command rc
   setStateList open close stop
   stateFormat pct
   webCmd     stop:open:close:pct:rc
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 11:53:55
Puh, das klingt schon mal nicht schlecht.

Warum findest du das nicht so gut, wenn man erst mal das Ziel angezeigt bekommt? Sonst würde der slider springen, das wäre auch nicht das Gelbe vom Ei, oder? Kannst ja mal testweise die setStateList löschen und dann sagen, ob du das besser findest.

Das Verhalten (mit "set_xx") ist z.B. bei HM-Rolladenaktoren auch so ähnlich.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 14 Januar 2019, 11:59:07
Ah, O.K.
In der Konfiguration die ich nutze, schiebe ich den Slider auf den gewünschten Wert und das Status-Icon behält den letzten realen Wert bei, bis eine neue Position übertragen wird.
Ist halt etwas seltsam, wenn man ein StateIcon verwendet. Das verschwindet dann und setxx erscheint. StateIcon kommt dann wieder zurück. Sieht optisch nach einem Fehler aus, auch wenn es gewollt ist.
Wobei man da natürlich auch ein Icon nutzen könnte, dass Bewegung anzeigt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 Januar 2019, 12:06:44
Zitat von: miggun am 14 Januar 2019, 11:59:07
Wobei man da natürlich auch ein Icon nutzen könnte, dass Bewegung anzeigt.
Darfst gerne einen Vorschlag machen für eine Erweiterung des devStateIcon :) . Wie wäre es mit:
0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100 set_.*:fts_shutter_updown
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: neturmel am 15 Januar 2019, 18:50:34
Hallo zusammen,

damit ich hier nicht nur ganz passiv lese und lerne, hier mal noch mein Device:

ein Shelly 2 als Rollladenaktor.
Ich verwende die aktuellste Version des mqtt2_templates, habe aber manuell die readingList angepasst,
indem  shellyswitch_XYZ:shellies/shellyswitch-XYZ/roller/0:.*  auf "state"  gemappt wird.
Dadurch (und durch "genericDeviceType blind") erscheint der Rollladen dann auch ohne weiteres Mapping in der Homebridge und funktioniert problemlos im Homekit/Siri

Für mich sieht das also sehr gut aus.

Super!




Internals
CID shellyswitch_559F03
DEF shellyswitch_559F03
DEVICETOPIC MQTT2_shellyswitch_559F03
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 647
MQTT2_FHEM_Server_TIME 2019-01-15 18:43:32
MSGCNT 647
NAME MQTT2_shellyswitch_559F03
NR 120
STATE 0
TYPE MQTT2_DEVICE


Readings
1 0 019-01-15 18:26:12
announce_fw_ver 20190103-091640/v1.4.4@165d718b 2019-01-15 17:03:50
announce_id shellyswitch-559F03 2019-01-15 17:03:50
announce_ip 192.168.178.48 2019-01-15 17:03:50
announce_mac CE50E3559F03 2019-01-15 17:03:50
announce_new_fw false 2019-01-15 17:03:50
online true 2019-01-15 17:03:50
pct 0 2019-01-15 18:44:32
pos 9 2019-01-15 05:03:36
power 0.00 2019-01-15 18:44:32
state stop
2019-01-15 18:47:32

defmod MQTT2_shellyswitch_559F03 MQTT2_DEVICE shellyswitch_559F03
attr MQTT2_shellyswitch_559F03 IODev MQTT2_FHEM_Server
attr MQTT2_shellyswitch_559F03 alias sz.rollladen
attr MQTT2_shellyswitch_559F03 comment shelly2 roller operated
attr MQTT2_shellyswitch_559F03 devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80$
attr MQTT2_shellyswitch_559F03 genericDeviceType blind
attr MQTT2_shellyswitch_559F03 model A_11b_shelly2_roller
attr MQTT2_shellyswitch_559F03 readingList shellies/shellyswitch-559F03/roller/0/pos:.* pct\
  shellies/shellyswitch-559F03/status/0/rollers:.* power\
  shellies/shellyswitch-559F03/online:.* online\
  shellies/shellyswitch-559F03/announce:.* { json2nameValue($EVENT) }\
shellyswitch_559F03:shellies/shellyswitch-559F03/roller/0:.* state\
shellyswitch_559F03:shellies/shellyswitch-559F03/relay/power:.* power\
shellyswitch_559F03:shellies/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }\
shellyswitch_559F03:shellies/shellyswitch-559F03/input/1:.* 1\
shellyswitch_559F03:shellies/shellyswitch-559F03/input/0:.* shellies/shellyswitch-559F03/input/0
attr MQTT2_shellyswitch_559F03 room Homekit,MQTT2_DEVICE,Schlafzimmer
attr MQTT2_shellyswitch_559F03 setList open:noArg shellies/shellyswitch-559F03/roller/0/command open\
  close:noArg shellies/shellyswitch-559F03/roller/0/command close\
  stop:noArg shellies/shellyswitch-559F03/roller/0/command stop\
  pct:slider,0,1,100 shellies/shellyswitch-559F03/roller/0/command/pos $EVTPART1\
  DoRecalibration:noArg shellies/shellyswitch-559F03/roller/0/command rc
attr MQTT2_shellyswitch_559F03 setStateList open close stop
attr MQTT2_shellyswitch_559F03 siriName Rollladen
attr MQTT2_shellyswitch_559F03 stateFormat pct
attr MQTT2_shellyswitch_559F03 webCmd stop:open:close:pct:rc
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 15 Januar 2019, 19:15:52
@Beta-User
Komme so gut klar.

@neturmel
Super direkt mal eingebaut. Funktioniert auf anhieb. Top.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Januar 2019, 19:17:59
Zitat von: neturmel am 15 Januar 2019, 18:50:34
damit ich hier nicht nur ganz passiv lese und lerne, hier mal noch mein Device:
Dann also willkommen hier im Forum und Danke für die positive Rückmeldung.
Zitat
indem  shellyswitch_XYZ:shellies/shellyswitch-XYZ/roller/0:.*  auf "state"  gemappt wird.
Dadurch (und durch "genericDeviceType blind") erscheint der Rollladen dann auch ohne weiteres Mapping in der Homebridge und funktioniert problemlos im Homekit/Siri
Vorab mal eine Anmerkung: Bisher war es jedenfalls bei mir nicht im Fokus, Attribute mit reinzubasteln, die für bestimmte Module erforderlich sein könnten (hier: Homekit).
Solche Dinge gehören m.E. ggf. in andere Dokumente, oder gibt es Argumente, das zu ändern?

Zum eigentlichen Code. Da scheint mir manches doppelt drin, für deinen Anwendungsfall müßte eigentlich genügen

defmod MQTT2_shellyswitch_559F03 MQTT2_DEVICE shellyswitch_559F03
attr MQTT2_shellyswitch_559F03 IODev MQTT2_FHEM_Server
attr MQTT2_shellyswitch_559F03 alias sz.rollladen
attr MQTT2_shellyswitch_559F03 comment shelly2 roller operated
attr MQTT2_shellyswitch_559F03 devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100 set_.*:fts_shutter_updown
attr MQTT2_shellyswitch_559F03 genericDeviceType blind
attr MQTT2_shellyswitch_559F03 model A_11b_shelly2_roller
attr MQTT2_shellyswitch_559F03 readingList shellies/shellyswitch-559F03/roller/0/pos:.* pct\
  shellies/shellyswitch-559F03/status/0/rollers:.* power\
  shellies/shellyswitch-559F03/online:.* online\
  shellies/shellyswitch-559F03/announce:.* { json2nameValue($EVENT) }\
  shellies/shellyswitch-559F03/roller/0:.* state\
  #shellies/shellyswitch-559F03/relay/power:.* relay_power\
  shellies/shellyswitch-559F03/input/1:.* input1\
  shellies/shellyswitch-559F03/input/0:.* input0
attr MQTT2_shellyswitch_559F03 room Homekit,MQTT2_DEVICE,Schlafzimmer
attr MQTT2_shellyswitch_559F03 setList open:noArg shellies/shellyswitch-559F03/roller/0/command open\
  close:noArg shellies/shellyswitch-559F03/roller/0/command close\
  stop:noArg shellies/shellyswitch-559F03/roller/0/command stop\
  pct:slider,0,1,100 shellies/shellyswitch-559F03/roller/0/command/pos $EVTPART1\
  DoRecalibration:noArg shellies/shellyswitch-559F03/roller/0/command rc
attr MQTT2_shellyswitch_559F03 setStateList open close stop
attr MQTT2_shellyswitch_559F03 siriName Rollladen
attr MQTT2_shellyswitch_559F03 stateFormat pct
attr MQTT2_shellyswitch_559F03 webCmd stop:open:close:pct:rc


Wobei webCmd vermutlich überflüssig ist (ergibt sich aus der setList) und siriName und genericDeviceType homekit-spezifisch.
Was hatte es mit dem doppelten power auf sich? Müßte unterschiedliche Readings ergeben, wenn es was anderes ist.
Wenn es das bzw. auch den Rest (relay_power, state, inputn) braucht, kann ich das gerne dazubauen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: neturmel am 15 Januar 2019, 20:55:54
@Beta-User

Danke für die Rückmeldung.

Das mit dem Homekit/Siri war nur als zusätzliche (nicht MQTT2) Info gedacht, würde ich auch nicht ins Template übernehmen. Hilft aber vielleicht anderen Siri-Nutzern, die zufällig hier landen.

webcmd ist wohl wirklich überflüssig und die zusätzlichen Werte sind ohne mein manuelles Zutun dazu gekommen.
Möglicherweise durch iegendwelche MQTT-Nachrichten des Shelly und autocreate?

Von Hand geändert hatte ich nur den state.

Nachdem ich alles überflüssige wieder gelöscht habe und nochmal über FHEM, Schalter und Homekit rumgespielt habe, sind die zusätzlichen Readings nicht mehr aufgetaucht.
Also keine Ahnung, was das war - passt also so.




Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 21 Januar 2019, 23:01:44
Hallo,

ich hab mich nochmal mit der (teilweise nicht vorhandenen) kWh-Anzeige der Shelly's beschäftigt.

Dabei bin ich zu folgenden Ergebnissen und folgendem Schluß gekommen:
Für mich sieht das so aus als hat man die Berechnung/Addierung der kWh über mehrere Wege (in meinen Augen immer schlecht) implementiert.

D.h.

Kann das Jemand bestätigen? Sind meine Ergebnisse/Schlußfolgerungen richtig?

Ich habe dazu auch schon eine Anfrage an den Support von Allterco geschickt. Bin mal auf die Antwort gespannt. Die antworten relativ zeitnah.

Wenn das tatsächlich so ist (ich hoffe ich liege falsch), dann ist das in meinen Augen komplett daneben. Alle Berechnungen sollten direkt auf den Shelly's ausgeführt und gespeichert werden. Andernfalls führt ein Ausfall der Internetverbindung, oder auch des FHEM-Servers zu falschen Werten. Auch scheint die Berechnung der kWh beim Shelly 4 Pro erst zu starten wenn MQTT aktiviert wird. Hier bin ich mir allerdings noch nicht ganz sicher. Die Werte kamen mir nur sehr niedrig vor. Mein Shelly 4 läuft schon ca. 8 Wochen. Das werde ich demnächst nochmal prüfen.

Heute habe ich auch mal das Shelly 4 Template ausprobiert, aber so ganz verstehe ich das noch nicht. Ich habe z.B. bei alle 4 angelegten Devices bei energy die gleichen Werte. Auch sieht mir die ReadingList etwas seltsam aus. Alles ist doppelt und in allen angelegten Devices sind die Readings aller 4 Kanäle enthalten. Aber vielleicht verstehe ich das Template auch noch nicht richtig.

Ich hoffe es klärt sich alles auf, bzw. die (vermeintlichen) Fehler werden demnächst behoben. Ich warte gerade auf vier weitere Shelly 4Pro. Eine Cloud-Anbindung kommt für mich nämlich nicht in Frage.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 22 Januar 2019, 07:46:22
Zitat von: Guzzi-Charlie am 21 Januar 2019, 23:01:44
Heute habe ich auch mal das Shelly 4 Template ausprobiert, aber so ganz verstehe ich das noch nicht. Ich habe z.B. bei alle 4 angelegten Devices bei energy die gleichen Werte. Auch sieht mir die ReadingList etwas seltsam aus. Alles ist doppelt und in allen angelegten Devices sind die Readings aller 4 Kanäle enthalten. Aber vielleicht verstehe ich das Template auch noch nicht richtig.

Ich hoffe es klärt sich alles auf, bzw. die (vermeintlichen) Fehler werden demnächst behoben. Ich warte gerade auf vier weitere Shelly 4Pro. Eine Cloud-Anbindung kommt für mich nämlich nicht in Frage.
Bin nicht sicher, ob das dieselbe Ursache für das doppelte Anlegen der readingList-Einträge ist: https://forum.fhem.de/index.php/topic,96189.msg892733.html#msg892733
Das template A_14a_shelly4pro_split sieht ansonsten von hier aus soweit ok aus - ich kann aber mangels Hardware nicht testen oder was zum Rest sagen.
Würde vorschlagen, nach einem update in ein paar Minuten alle Readings zu löschen und das template nochmal anzuwenden. Danach sollte es eigentlich bei einzelnen Geräten mit recht kurzen Attribut-Listen bleiben.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 22 Januar 2019, 08:37:49
ZitatWenn das tatsächlich so ist..., dann ist das in meinen Augen komplett daneben.

Es ist immer wieder herzerwärmend, wenn Neulinge so detailliert erklären, was gemacht werden sollte. Und in diesem Falle ist die Erklärung absoluter Bockmist.

Bei der Leistungsmessung handelt es sich um eine relativ einfache Sache. Daraus die verbrauchte Energie zu berechnen, ist trickreich - denn die Leistungsmessung erfolgt ja nicht kontinuierlich, sondern zeitdiskret. Man muss also Annahmen zur Interpolation treffen - und da ist Allterco nicht gut drin. Nach meinen Daten sind die angezeigten Energiewerte nur sehr grobe Näherungen.

Aus genau diesem Grund schweigt sich erstens die API-Doku darüber aus, und habe ich das zweitens im Shelly-Modul nicht implementiert.

Schlussfolgerung; Es ist viel sinnvoller und genauer, die Energieberechnung im Backend (also in diesem Falle FHEM) durchzuführen.

LG

pah

P.S.: Ach ja, es heißt nicht "Shelly's", sondern "Shellys". Weder im Deutschen, noch im Englischen erfolgt eine Mehrzahlbildung mit Apostroph.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 11:06:57
@ pah

Vielen Dank Herr Oberlehrer für die "Belehrungen", aber Ihre Antworten sind ja wohl komplett am Thema vorbei.

Ich habe nur den Ist-Stand (aus meiner Sicht) beschrieben und zwei konkrete Fragen gestellt:

Auf keine meiner Fragen gab es eine Antwort.

Ich habe auch nicht nach irgendwelchen Erklärungen zur Energieberechnung in der API gefragt. Ich habe nur festgestellt, daß es zur Bereitstellung des Energiewertes für den Shelly 2 keine Angaben gibt (im Gegensatz zum Shelly 4Pro).

Im Übrigen ist die Berechnung des Energiewertes keinesfalls "trickreich". Wo, wenn nicht direkt am Shelly soll man das denn genauer berechnen können. Bei jedem Zyklus der FW hat man Leistung und Zeit (die genaue Zykluszeit kenne ich zwar nicht, aber wahrscheinlich ms und nicht s. Nach "Außen", wo nur alle 10s, 60s, oder was man halt einstellt Werte übertragen werden kann es nur ungenauer werden. Erst Recht, wenn mal was ausfällt (Internetverbindung, Shelly-Server, FHEM-Server). Die Berechnung also erst im Backend zu machen ist völliger Quatsch. Gerade dadurch wird es ja ungenau. Jedes billige "Steckdosen-Energiemeßgerät", oder auch Hutschienenzähler (auch geeichte) machen sowas onboard.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 11:18:35
@Beta-User

Hallo,
auf diesen Thread bin ich auch schon gestoßen, hab das aber noch nicht komplett durchgelesen. Werde es Heute nochmal versuchen zu testen. Im Moment bin ich mir aber auch noch nicht ganz im Klaren ob ich tatsächlich 4 Devices anlegen will, oder doch alles in einem Device lasse.

Aber nochmal zurück zu meiner Frage:
"Ich habe z.B. bei alle 4 angelegten Devices bei energy die gleichen Werte."
Da stimmt doch auch was nicht, oder?

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 22 Januar 2019, 11:30:31
Zitat von: Guzzi-Charlie am 22 Januar 2019, 11:18:35
Im Moment bin ich mir aber auch noch nicht ganz im Klaren ob ich tatsächlich 4 Devices anlegen will, oder doch alles in einem Device lasse.
Sofern du ein Einheits-Device anlegen willst, kannst du dich an den tastmota-unified orientieren. Wenn du das in template-Form lieferst, übernehme ich das gerne...

ZitatAber nochmal zurück zu meiner Frage:
"Ich habe z.B. bei alle 4 angelegten Devices bei energy die gleichen Werte."
Da stimmt doch auch was nicht, oder?
Richtig scheint das nicht zu sein, aber wenn es in unterschiedlich benannten Readings zu finden ist (was nach dem template so sein sollte), liegt die Ursache m.E. auf dem Gerät. Auch der Shelly2 hatte zunächst (bzw. liefert immer noch) zweifelhafte bzw. keine Daten.

Würde daher pah zustimmen und behaupten, dass wir der Fa. noch Gelegenheit lassen sollten, ihre firmware auch an der Stelle nachzubessern (soweit es überhaupt sinnvoll möglich ist, ordentliche Messergebnisse zu bekommen).

Ohne list-Infos (nach update und Korrektur der readingList) iVm. dem, was der Server an rawEvents hergibt ist das aber sehr spekulativ...
Wenn der shelly schlicht MQTT-seitig komische Dinge liefert und es darum geht, das zu verbessern, bitte einen separaten Thread dazu aufmachen, das ist dann keine template-Frage mehr; hier geht es darum, das zu verarbeiten, was wir haben, nicht um eine qualitative Beurteilung ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 13:24:13
@Beta-User

Ok, wie gesagt: Ich schaue mir das nochmal genau an. Löschen neu anlegen, testen.

Melde mich dann nochmal.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 17:31:44
So, ich habe nun nochmal alles von Vorne neu angelegt. Nachfolgend meine Ergebnisse:

1.   Shelly über das WEB-IF auf MQTT umgestellt
       -->  Shelly wird in FHEM automatisch angelegt (ohne energy-readings):

raw-definition:
defmod MQTT2_shelly4pro_801300 MQTT2_DEVICE shelly4pro_801300
attr MQTT2_shelly4pro_801300 IODev MQTT2_FHEM_Server
attr MQTT2_shelly4pro_801300 readingList shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0:.* shellies/shelly4pro-801300/relay/0\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0:.* shellies/shelly4pro-801300/relay/0\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1:.* 1\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1:.* 1\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2:.* 2\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2:.* 2\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3:.* 3\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3:.* 3\
shelly4pro_801300:shellies/announce:.* { json2nameValue($EVENT, 'announce_',$JSONMAP) }\
shelly4pro_801300:shellies/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }
attr MQTT2_shelly4pro_801300 room MQTT2_DEVICE

setstate MQTT2_shelly4pro_801300 2019-01-22 13:36:09 1 off
setstate MQTT2_shelly4pro_801300 2019-01-22 13:36:09 2 off
setstate MQTT2_shelly4pro_801300 2019-01-22 13:36:09 3 off
setstate MQTT2_shelly4pro_801300 2019-01-22 13:34:09 announce_fw_ver 20181217-130631/v1.4.2@cc724b51
setstate MQTT2_shelly4pro_801300 2019-01-22 13:34:09 announce_id shelly4pro-801300
setstate MQTT2_shelly4pro_801300 2019-01-22 13:34:09 announce_ip 192.168.178.131
setstate MQTT2_shelly4pro_801300 2019-01-22 13:34:09 announce_mac C8FD19801300
setstate MQTT2_shelly4pro_801300 2019-01-22 13:34:09 announce_new_fw false
setstate MQTT2_shelly4pro_801300 2019-01-22 13:34:09 announce_online true
setstate MQTT2_shelly4pro_801300 2019-01-22 13:36:09 power 0.00
setstate MQTT2_shelly4pro_801300 2019-01-22 13:36:09 shellies/shelly4pro-801300/relay/0 off

==> hier werden schon alle Readings doppelt erzeugt. Das kommt doch dann wohl vom MQTT2-Server, oder?

2.   Template ausgeführt mit:
       set MQTT2_shelly4pro_801300 attrTemplate A_14a_shelly4pro_split

       Log:
       Deleted reading power for device MQTT2_shelly4pro_801300
       Deleted reading 2 for device MQTT2_shelly4pro_801300
       Deleted reading 1 for device MQTT2_shelly4pro_801300
       Deleted reading announce_mac for device MQTT2_shelly4pro_801300
       Deleted reading announce_fw_ver for device MQTT2_shelly4pro_801300
       Deleted reading announce_new_fw for device MQTT2_shelly4pro_801300   
       Deleted reading announce_online for device MQTT2_shelly4pro_801300
       Deleted reading announce_ip for device MQTT2_shelly4pro_801300
       Deleted reading shellies/shelly4pro-801300/relay/0 for device MQTT2_shelly4pro_801300
       Deleted reading announce_id for device MQTT2_shelly4pro_801300
       Deleted reading 3 for device MQTT2_shelly4pro_801300

       ==> Shelly auf 4 Devices gesplittet:
               siehe Bild Shelly4Pro_Split

raw-definition CH1:
defmod MQTT2_shelly4pro_801300 MQTT2_DEVICE shelly4pro_801300

attr MQTT2_shelly4pro_801300 IODev MQTT2_FHEM_Server
attr MQTT2_shelly4pro_801300 comment Channel 3 for MQTT2_shelly4pro_801300, see also MQTT2_shelly4pro_801300, MQTT2_shelly4pro_801300_CH2 and MQTT2_shelly4pro_801300_CH4
attr MQTT2_shelly4pro_801300 getList power3:noArg shellies/shelly4pro-801300/relay/2/power power3\
shellies/Dshelly4pro-801300/relay/2/energy energy3
attr MQTT2_shelly4pro_801300 model A_14a_shelly4pro_split
attr MQTT2_shelly4pro_801300 readingList shellies/shelly4pro-801300/relay/0:.* state\
shellies/shelly4pro-801300/relay/0:.* relay0\
shellies/shelly4pro-801300/input/0:.* input0\
shellies/shelly4pro-801300/online:.* online\
shellies/shelly4pro-801300/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power
attr MQTT2_shelly4pro_801300 room MQTT2_DEVICE
attr MQTT2_shelly4pro_801300 setList off:noArg
shellies/shelly4pro-801300/relay/0/command off\
on:noArg shellies/shelly4pro-801300/relay/0/command on

setstate MQTT2_shelly4pro_801300 2019-01-22 13:41:40 power 0.00
setstate MQTT2_shelly4pro_801300 2019-01-22 13:41:40 relay0 off


raw-definition CH2:
defmod MQTT2_shelly4pro_801300_CH2 MQTT2_DEVICE shelly4pro_801300

attr MQTT2_shelly4pro_801300_CH2 IODev MQTT2_FHEM_Server
attr MQTT2_shelly4pro_801300_CH2 comment Channel 2 for MQTT2_shelly4pro_801300
attr MQTT2_shelly4pro_801300_CH2 getList power1:noArg
shellies/shelly4pro-801300/relay/0/power power1\
shellies/shelly4pro-801300/relay/0/energy energy1
attr MQTT2_shelly4pro_801300_CH2 model A_10a_shellyplug
attr MQTT2_shelly4pro_801300_CH2 readingList shellies/shelly4pro-801300/relay/1:.* state\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power
attr MQTT2_shelly4pro_801300_CH2 room MQTT2_DEVICE
attr MQTT2_shelly4pro_801300_CH2 setList off:noArg
shellies/shelly4pro-801300/relay/1/command off\
on:noArg shellies/shelly4pro-801300/relay/1/command on

setstate MQTT2_shelly4pro_801300_CH2 off
setstate MQTT2_shelly4pro_801300_CH2 2019-01-22 13:38:17 associatedWith MQTT2_shelly4pro_801300,MQTT2_shelly4pro_801300_CH3,MQTT2_shelly4pro_801300_CH4
setstate MQTT2_shelly4pro_801300_CH2 2019-01-22 13:42:12 power 0.00
setstate MQTT2_shelly4pro_801300_CH2 2019-01-22 13:42:12 state off


raw-definition CH3:
defmod MQTT2_shelly4pro_801300_CH3 MQTT2_DEVICE shelly4pro_801300

attr MQTT2_shelly4pro_801300_CH3 IODev MQTT2_FHEM_Server
attr MQTT2_shelly4pro_801300_CH3 comment Channel 3 for MQTT2_shelly4pro_801300
attr MQTT2_shelly4pro_801300_CH3 getList power2:noArg shellies/shelly4pro-801300/relay/1/power power2\
  shellies/shelly4pro-801300/relay/1/energy energy2
attr MQTT2_shelly4pro_801300_CH3 model A_10a_shellyplug
attr MQTT2_shelly4pro_801300_CH3 readingList shellies/shelly4pro-801300/relay/2:.* state\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power
attr MQTT2_shelly4pro_801300_CH3 room MQTT2_DEVICE
attr MQTT2_shelly4pro_801300_CH3 setList off:noArg shellies/shelly4pro-801300/relay/2/command off\
on:noArg shellies/shelly4pro-801300/relay/2/command on

setstate MQTT2_shelly4pro_801300_CH3 off
setstate MQTT2_shelly4pro_801300_CH3 2019-01-22 13:38:17 associatedWith MQTT2_shelly4pro_801300,MQTT2_shelly4pro_801300_CH2,MQTT2_shelly4pro_801300_CH4
setstate MQTT2_shelly4pro_801300_CH3 2019-01-22 13:42:41 power 0.00
setstate MQTT2_shelly4pro_801300_CH3 2019-01-22 13:42:41 state off


raw-definition CH3:
defmod MQTT2_shelly4pro_801300_CH4 MQTT2_DEVICE shelly4pro_801300

attr MQTT2_shelly4pro_801300_CH4 IODev MQTT2_FHEM_Server
attr MQTT2_shelly4pro_801300_CH4 comment Channel 4 for MQTT2_shelly4pro_801300, see also MQTT2_shelly4pro_801300, MQTT2_shelly4pro_801300_CH2 and MQTT2_shelly4pro_801300_CH3
attr MQTT2_shelly4pro_801300_CH4 getList power4:noArg shellies/shelly4pro-801300/relay/3/power power4\
  shellies/shelly4pro-801300/relay/3/energy energy4
attr MQTT2_shelly4pro_801300_CH4 model A_10a_shellyplug
attr MQTT2_shelly4pro_801300_CH4 readingList shellies/shelly4pro-801300/relay/3:.* state\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power
attr MQTT2_shelly4pro_801300_CH4 room MQTT2_DEVICE
attr MQTT2_shelly4pro_801300_CH4 setList off:noArg shellies/shelly4pro-801300/relay/3/command off\
  on:noArg shellies/shelly4pro-801300/relay/3/command on

setstate MQTT2_shelly4pro_801300_CH4 off
setstate MQTT2_shelly4pro_801300_CH4 2019-01-22 13:38:17 associatedWith MQTT2_shelly4pro_801300,MQTT2_shelly4pro_801300_CH2,MQTT2_shelly4pro_801300_CH3
setstate MQTT2_shelly4pro_801300_CH4 2019-01-22 13:43:15 power 0.00
setstate MQTT2_shelly4pro_801300_CH4 2019-01-22 13:43:15 state off


   ==> keine energy-readings vorhanden

3.   CH1 eingeschaltet:
Energy reading für Kanal 1 taucht in allen 4 devices in der readingList. Der Wert von CH1 wird in allen 4 devices unter "Readings" mit dem gleichen Wert (falsch) angezeigt.
siehe Bild "ReadingList_1"

4.   CH2 eingeschaltet:
Energy reading für Kanal 1+2 tauchen in alle 4 devices in der readingList. Der Wert von CH2 wird in allen 4 devices unter "Readings" mit dem gleichen Wert (falsch) angezeigt.
siehe Bild "ReadingList_2"

5.   CH3 eingeschaltet:
Energy reading für Kanal 1+2+3 tauchen in alle 4 devices in der readingList. Der Wert von CH3 wird in allen 4 devices unter "Readings" mit dem gleichen Wert (falsch) angezeigt.
siehe Bild "ReadingList_3"

6.   CH4 eingeschaltet:
Energy reading für Kanal 1+2+3+4 tauchen in alle 4 devices in der readingList auf. Der Wert von CH4 wird in allen 4 devices unter "Readings" mit dem gleichen Wert (falsch) angezeigt.
siehe Bild "ReadingList_4"

==> Beim Ausschalten geht es dann praktisch rückwärts. Der jeweils letzte übertragene energy-Wert wird dann auf allen Devices in den Readings ausgegeben. Da scheint also irgendetwas mit den Zuordnungen nicht zu stimmen.

Wegen dem "Einheits-Device" bin ich ja noch am Überlegen und ich bin auch noch ein ziemlicher Anfänger was die Tiefen von FHEM betrifft, aber natürlich teile ich gerne meine Ergebnisse. Ich habe auch noch soooo viele Baustellen was FHEM betrifft. Das kann also auch noch dauern. Mein Haus ist ziemlich groß und wenn ich was mache dann gleich komplett und nicht nur ein paar Lampen, oder Messungen.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 22 Januar 2019, 17:54:36
@Guzzi-Charlie kurz vorab:
Deine Module waren bei dieser Sache auf welchem Stand?
Rudi hatte da gestern abend was in MQTT2_DEVICE geändert, die sollte rev. 18363 sein (Server habe ich nicht nachgesehen). Dein Update sollte ab heute morgen nach 8:00 Uhr erfolgt sein...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 18:09:39
Oh Mist. Das letzte Update hatte ich Gestern gemacht.

Ich versuchs dann halt nochmal.

Danke für die Info.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 18:39:39
So, ich habe nochmal alles gelöscht und neu angelegt (anlegen lassen).

Das Ergebnis ist aber (was das automatische Anlegen durch den MQTT2-Server betrifft) annähernd das Gleiche. D.h. es werden immer noch alle Einträge der readingList doppelt erstellt.

Ergebnis Gestern:
......shelly4pro_801300:shellies/shelly4pro-801300/relay/3:.* 3\
shelly4pro_801300:shellies/announce:.* { json2nameValue($EVENT, 'announce_',$JSONMAP) }\
shelly4pro_801300:shellies/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }


Ergebnis Jetzt (nach Update):
......shelly4pro_801300:shellies/shelly4pro-801300/relay/3:.* 3\
shelly4pro_801300:shellies/announce:.* __json2nameValue__EVENT___announce_____JSONMAP___


Der Rest (Vorne dran) ist gleich. Die letzte Zeile sieht ein wenig komisch aus. Ist das so richtig? Hab von Pearl leider wenig Ahnung.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 18:47:44
Oh, ich sehe gerade: Das "__json2nameValue__EVENT___announce_____JSONMAP___" ist ja nur der Name des Readings (sieht aber komisch aus).
Das Ergebnis des Readings ist:
{"id":"shelly4pro-801300","online":true,"mac":"C8FD19801300","ip":"192.168.178.131","new_fw":false, "fw_ver":"20181217-130631/v1.4.2@cc724b51"}

Ist jetzt alles in einem Reading. Ob das jetzt besser oder schlechter ist als Vorher, keine Ahnung. Aber das ist ja im Moment auch nicht das Problem.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 18:56:16
Was mir gerade erst aufgefallen ist:
Das erste "power" Reading wird beim Anlegen nicht verdoppelt. Erst ab Kanal 2 wird alles verdoppelt.

Und der Readingsname vom Zustand des relay 0 ist auch seltsam:
Statt wie bei Kanal 2-4 "1\", "2\", "3\" wird hier "shellies/shelly4pro-801300/relay/0\" angelegt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 22 Januar 2019, 19:04:13
...das ist definitiv nicht so ganz im Sinne des Erfinders...

@Rudi: ich hoffe, du liest hier noch mit.

@Guzzi-Charlie:
Ich habe eben noch eine neue Fassung der templates ins svn geladen (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template), die auch die readingList passend schreiben sollte (auch auf Basis deiner kaputten Perl-Anweisung).

Vielleicht magst du die mal Testen, ob dann was vernünftiges bei rumkommt, garantieren kann ich aber dafür nicht...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 22 Januar 2019, 19:28:22
Ein getretener Hund bellt, und der hier wird halt ausfallend. Vielleicht einfach mal recherchieren, wie man eine stark variable Größe über die Zeit integriert.

LG

pah

P.S.: Ach ja: Es heißt Perl, und nicht "Pearl". Ich empfehle einen Blick in die Anfänger-Doku  ;D ;D
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 22 Januar 2019, 19:40:39
Zitatshelly4pro_801300:shellies/announce:.* __json2nameValue__EVENT___announce_____JSONMAP___
Da habe ich wohl einen Eigentor geschossen.
Habs gefixt, eingecheckt, und (ausnahmsweise) fuers sofortigen fhem-update zur Verfuegung gestellt

@Guzzi-Charlie: wenn du das Neuanlegen mit einem "attr MQTT2_FHEM_Server verbiose 5" dokumentieren koenntest, waere ich fuer den Log dankbar.
Natuerlich nach einem FHEM-Update, den ich dringend empfehle, da deine aktuelle Version von 00_MQTT2_DEVICE.pm beim autocreate Mist baut.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 22:27:11
Hallo Rudi,

heißt das Modul "00_MQTT2_DEVICE.pm", oder "00_MQTT2_CLIENT.pm"?

Ein "00_MQTT2_DEVICE.pm" hab ich nämlich nicht im FHEM-Ordner, nur ein "00_MQTT2_CLIENT.pm" und das ist von Heute Abend 18:13Uhr (war mein letztes Update).

Ich mache gleich nochmal ein Update, lege dann alles nochmal neu an und poste dann das Log.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 22 Januar 2019, 22:59:04
Ich meinte 10_MQTT2_DEVICE.pm.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 23:07:54
So, nun die Ergebnisse nach Update, Löschen und Neuanlegen des Shelly 4Pro mit autocreate.

Auf die Schnelle betrachtet sieht der neu angelegte Shelly 4Pro auch nicht anders aus als vorher.
Hier die readingList:
shelly4pro_801300:shellies/announce:.* __json2nameValue__EVENT___announce_____JSONMAP___
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power
shelly4pro_801300:shellies/shelly4pro-801300/relay/0:.* shellies/shelly4pro-801300/relay/0
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power
shelly4pro_801300:shellies/shelly4pro-801300/relay/1:.* 1
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power
shelly4pro_801300:shellies/shelly4pro-801300/relay/2:.* 2
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/energy:.* energy
shelly4pro_801300:shellies/shelly4pro-801300/relay/3:.* 3
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/energy:.* energy
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/energy:.* energy
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/energy:.* energy


Auszug aus dem Logfile (ich hoffe das ist so richtig, Das attr Verbose vom MQTT2-Server hatte ich auf 5 gestellt):
2019.01.22 22:53:40 5: CONNECT: (0)(4)MQTT(4)(2)(0)<(0)(17)shelly4pro-801300
2019.01.22 22:53:40 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 CONNECT V:4 keepAlive:60
2019.01.22 22:53:41 5: PUBLISH: (0)(17)shellies/announce{"id":"shelly4pro-801300","online":true,"mac":"C8FD19801300","ip":"192.168.178.131","new_fw":false, "fw_ver":"20181217-130631/v1.4.2@cc724b51"}
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/announce:{"id":"shelly4pro-801300","online":true,"mac":"C8FD19801300","ip":"192.168.178.131","new_fw":false, "fw_ver":"20181217-130631/v1.4.2@cc724b51"}
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/announce:{"id":"shelly4pro-801300","online":true,"mac":"C8FD19801300","ip":"192.168.178.131","new_fw":false, "fw_ver":"20181217-130631/v1.4.2@cc724b51"}
2019.01.22 22:53:41 2: autocreate: define MQTT2_shelly4pro_801300 MQTT2_DEVICE shelly4pro_801300
2019.01.22 22:53:41 2: autocreate: define FileLog_MQTT2_shelly4pro_801300 FileLog ./log/MQTT2_shelly4pro_801300-%Y.log MQTT2_shelly4pro_801300
2019.01.22 22:53:41 5: PUBLISH: (0)(shellies/shelly4pro-801300/relay/0/power0.00
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/0/power:0.00
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:0.00
2019.01.22 22:53:41 5: PUBLISH: (0)"shellies/shelly4pro-801300/relay/0off
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/0:off
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/0:off
2019.01.22 22:53:41 5: PUBLISH: (0)(shellies/shelly4pro-801300/relay/1/power0.00
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/1/power:0.00
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:0.00
2019.01.22 22:53:41 5: PUBLISH: (0)"shellies/shelly4pro-801300/relay/1off
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/1:off
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/1:off
2019.01.22 22:53:41 5: PUBLISH: (0)(shellies/shelly4pro-801300/relay/2/power0.00
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/2/power:0.00
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:0.00
2019.01.22 22:53:41 5: PUBLISH: (0)"shellies/shelly4pro-801300/relay/2off
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/2:off
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/2:off
2019.01.22 22:53:41 5: PUBLISH: (0)(shellies/shelly4pro-801300/relay/3/power23.50
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/3/power:23.50
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:23.50
2019.01.22 22:53:41 5: PUBLISH: (0))shellies/shelly4pro-801300/relay/3/energy322
2019.01.22 22:53:41 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/3/energy:322
2019.01.22 22:53:41 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/3/energy:322
2019.01.22 22:53:42 5: PUBLISH: (0)"shellies/shelly4pro-801300/relay/3on
2019.01.22 22:53:42 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/3:on
2019.01.22 22:53:42 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/3:on
2019.01.22 22:53:42 5: SUBSCRIBE: (133);(0)(16)shellies/command(1)
2019.01.22 22:53:42 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 SUBSCRIBE
2019.01.22 22:53:42 4:   topic:shellies/command qos:1
2019.01.22 22:53:42 5: SUBSCRIBE: (133)<(0)"shellies/shelly4pro-801300/command(1)
2019.01.22 22:53:42 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 SUBSCRIBE
2019.01.22 22:53:42 4:   topic:shellies/shelly4pro-801300/command qos:1
2019.01.22 22:53:42 5: SUBSCRIBE: (133)=(0)*shellies/shelly4pro-801300/relay/3/command(1)
2019.01.22 22:53:42 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 SUBSCRIBE
2019.01.22 22:53:42 4:   topic:shellies/shelly4pro-801300/relay/3/command qos:1
2019.01.22 22:53:42 5: SUBSCRIBE: (133)>(0)*shellies/shelly4pro-801300/relay/2/command(1)
2019.01.22 22:53:42 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 SUBSCRIBE
2019.01.22 22:53:42 4:   topic:shellies/shelly4pro-801300/relay/2/command qos:1
2019.01.22 22:53:42 5: SUBSCRIBE: (133)?(0)*shellies/shelly4pro-801300/relay/1/command(1)
2019.01.22 22:53:42 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 SUBSCRIBE
2019.01.22 22:53:42 4:   topic:shellies/shelly4pro-801300/relay/1/command qos:1
2019.01.22 22:53:42 5: SUBSCRIBE: (133)@(0)*shellies/shelly4pro-801300/relay/0/command(1)
2019.01.22 22:53:42 4: MQTT2_FHEM_Server_192.168.178.131_63354 shelly4pro-801300 SUBSCRIBE
2019.01.22 22:53:42 4:   topic:shellies/shelly4pro-801300/relay/0/command qos:1
2019.01.22 22:53:43 5: PINGREQ:
2019.01.22 22:53:43 4: MQTT2_FHEM_Server_192.168.178.162_15416 DVES_E4AC01 PINGREQ
2019.01.22 22:53:43 5: PUBLISH: (0)$shellies/shellyswitch-135A27/relay/0on
2019.01.22 22:53:43 4: MQTT2_FHEM_Server_192.168.178.141_57225 shellyswitch-135A27 PUBLISH shellies/shellyswitch-135A27/relay/0:on
2019.01.22 22:53:43 5: MQTT2_FHEM_Server: dispatch autocreate:shellyswitch_135A27:shellies/shellyswitch-135A27/relay/0:on
2019.01.22 22:53:43 5: PUBLISH: (0)$shellies/shellyswitch-135A27/relay/1off
2019.01.22 22:53:43 4: MQTT2_FHEM_Server_192.168.178.141_57225 shellyswitch-135A27 PUBLISH shellies/shellyswitch-135A27/relay/1:off
2019.01.22 22:53:43 5: MQTT2_FHEM_Server: dispatch autocreate:shellyswitch_135A27:shellies/shellyswitch-135A27/relay/1:off
2019.01.22 22:53:43 5: PUBLISH: (0)(shellies/shellyswitch-135A27/relay/power34.57
2019.01.22 22:53:43 4: MQTT2_FHEM_Server_192.168.178.141_57225 shellyswitch-135A27 PUBLISH shellies/shellyswitch-135A27/relay/power:34.57
2019.01.22 22:53:43 5: MQTT2_FHEM_Server: dispatch autocreate:shellyswitch_135A27:shellies/shellyswitch-135A27/relay/power:34.57


Die Adressen ...161 und ...162 sind ein Shelly 1 (gerade nicht in Betrieb und ein Shelly 2).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 23:12:27
Oh, jetzt haben sich die Posts überschnitten.

Hab gerade nochmal geschaut. Das Modul "10_MQTT_DEVICE.pm" ist tatsächlich noch alt (vom 07.10.2018) und wurde nicht geupdatet gerade. Dann kann ja auch nichts anderes herauskommen.

Ist das beim Komplett-Update nicht dabei? Muß ich das separat updaten?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 23:28:58
Oh Mann, oh Mann. Ich höre besser auf für Heute, mache zu viele Fehler.

1. Mein FileZilla war nicht aktuallisiert, also "10_MQTT_DEVICE.pm" wurde doch geupdatet.
2. Habe aber den "shutdown restart"vergessen.

Also alles nochmal von Vorne. Schicke gleich die Daten.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 22 Januar 2019, 23:49:47
So, nun hoffentlich die richtigen Daten nach Update, Restart, Löschen und Neuanlegen des Shelly 4Pro mit autocreate.

Die "announce"-Werte sind jetzt wieder richtig. Der Rest ist aber immer noch wie ursprünglich, d.h. falscher Name beim relay0 und keine Unterscheidung der einzelnen Kanäle für "power" und "energy".

Hier die readingList:
shelly4pro_801300:shellies/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* power
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/energy:.* energy
shelly4pro_801300:shellies/shelly4pro-801300/relay/0:.* shellies/shelly4pro-801300/relay/0
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* power
shelly4pro_801300:shellies/shelly4pro-801300/relay/1:.* 1
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* power
shelly4pro_801300:shellies/shelly4pro-801300/relay/2:.* 2
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* power
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/energy:.* energy
shelly4pro_801300:shellies/shelly4pro-801300/relay/3:.* 3
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/energy:.* energy
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/energy:.* energy

Die "energy"-Werte erscheinen übrigens nur wenn der Kanal "EIN" ist.

Auszug aus dem Logfile (ich hoffe das ist so richtig, Das attr Verbose vom MQTT2-Server hatte ich auf 5 gestellt):
2019.01.22 23:36:21 5: PUBLISH: (0)(shellies/shelly4pro-801300/relay/0/power0.00
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/0/power:0.00
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:0.00
2019.01.22 23:36:21 5: PUBLISH: (0)"shellies/shelly4pro-801300/relay/0off
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/0:off
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/0:off
2019.01.22 23:36:21 5: PUBLISH: (0)(shellies/shelly4pro-801300/relay/1/power0.00
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/1/power:0.00
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:0.00
2019.01.22 23:36:21 5: PUBLISH: (0)"shellies/shelly4pro-801300/relay/1off
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/1:off
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/1:off
2019.01.22 23:36:21 5: PUBLISH: (0)(shellies/shelly4pro-801300/relay/2/power0.00
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/2/power:0.00
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:0.00
2019.01.22 23:36:21 5: PUBLISH: (0)"shellies/shelly4pro-801300/relay/2off
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/2:off
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/2:off
2019.01.22 23:36:21 5: PUBLISH: (0)(shellies/shelly4pro-801300/relay/3/power23.39
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/3/power:23.39
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:23.39
2019.01.22 23:36:21 5: PUBLISH: (0))shellies/shelly4pro-801300/relay/3/energy324
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/3/energy:324
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/3/energy:324
2019.01.22 23:36:21 5: PUBLISH: (0)"shellies/shelly4pro-801300/relay/3on
2019.01.22 23:36:21 4: MQTT2_FHEM_Server_192.168.178.131_52806 shelly4pro-801300 PUBLISH shellies/shelly4pro-801300/relay/3:on
2019.01.22 23:36:21 5: MQTT2_FHEM_Server: dispatch autocreate:shelly4pro_801300:shellies/shelly4pro-801300/relay/3:on


Ich hoffe das ist Richtig und hilft. Ich mache jetzt Schluß für Heute.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 23 Januar 2019, 07:40:29
Zitat von: Guzzi-Charlie am 22 Januar 2019, 23:49:47
[...] keine Unterscheidung der einzelnen Kanäle für "power" und "energy".
Das kommt daher, dass man beim Festlegen der Readings irgendeine Annahme treffen muß; hier: der Letzte Teil des Topic-Strings ist der Reading-Name.
Da der shelly aber denselben Namen hinten verwendet, kann autocreate das nicht unterscheiden und man muß manuell eingreifen, sonst landet eben immer der letzte Wert von irgendwo her in diesem Reading. Wenn du das manuell bearbeiten willst: einfach die Kanalnummer dahinter schreiben (also energy0 bzw. power0 usw.).

@Rudi:
- An einen Automatismus, um sowas zu umgehen, glaube ich nicht so recht; man könnte aber vielleicht immer eine pure Zahl im Topicstring als "Warnzeichen" auffassen: Bei den MiLights ist das ähnlich, nur dass da danach noch einiges an Detailinfo via JSON kommt. Wenn, dann wäre die Logik ggf. so: "Gibt es eine Zahl in den letzten beiden Elementen des Topic-Strings, bilde das Reading als $TEXT$ZAHL". 
- zu dem seltsamen Readingnamen mit dem topicstring fällt mir nichts ein.
- Die Sache mit den Präfixen in json2nameValue ist zwar in einigen Fällen wohl zweckmäßig, in der Mehrzahl der uns bisher untergekommenen Fällen führt es aber eher zu Verwirrung und Änderungswünschen. Meine Tendenz wäre daher, das im Default nur in der einfachen Form ({ json2nameValue($EVENT) }) in autocreate zu verwenden; ggf. kann man einen Hinweis auf die komplexere Form in einen comment schreiben, wenn da noch nichts drin steht.

Gruß, Beta-User
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 23 Januar 2019, 09:34:43
Hallo Guten Morgen,

Danke erstmal für die bisherigen Hilfen und Erklärungen.

Ich weiß, daß ich manuell die readingList ändern kann (habe ich ja auch schon gemacht). Ich hab aber keine Ahnung wie das autocreate und das template im Detail funktioniert (ich habe es bisher "nur" benutzt), deshalb die Anmerkungen. Ich kann auch absolut damit leben wie es jetzt ist. Ein wenig Handarbeit ist ja kein Problem.

Ich wollte hier auch nicht alle wuschig machen. Ich bin ja eigentlich nur wegen der seltsamen/unterschiedliche Methoden der "Bereitstellung" der Energiewerte bei den Shellys auf diesen Thread gestoßen und wollte zu meinen Feststellungen/Erkenntnissen/Vorstellungen ein paar Bestätigungen/Hilfen. Vielen Dank an Rudi und Beta-User. Wenn ich von Allterco was Neues erfahre werde ich das gerne hier kund tun.

Grundsätzlich bin ich ja von der autocreate-Funktion des MQTT2-Servers begeistert. Das funktioniert wunderbar und ist gerade für Anfänger ein wahnsinniger Vorteil. Hab inzwischen über 30 Devices (hauptsächlich Sonoff und Wemos D1 mini) angelegt. Die funktionieren alle perfekt.

So, jetzt muß ich mich Heute erstmal um was Anderes kümmern. Muß 2 Wechselrichter meiner PV-Anlagen austauschen.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 24 Januar 2019, 16:00:53
@Guzzi-Charlie:
Danke fuer die Daten. Die aktuelle Version verruracht bei mir damit keine doppelten Readings, dieses Problem scheint also erledigt zu sein.

@Beta-User:
ab sofort werden in autocreate die letzten 2 Stellen des topics auf "pure Zahl" geprueft, und daraus entweder $TEXT$ZAHL, $TEXT$ZAHL$TEXT (falls moeglich, sonst $ZAHL$TEXT) als Readingname generiert. Damit werden aus Guzzi-Charlies Log folgende Readings automatisch erzeugt:
Zitatrelay_0
relay_0_power
relay_1
relay_1_power
relay_2
relay_2_power
relay_3
relay_3_energy
relay_3_power
json2nameValue im autocreate habe ich so abgeaendert, wie bestellt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Januar 2019, 16:20:52
Zitat von: rudolfkoenig am 24 Januar 2019, 16:00:53
ab sofort werden in autocreate die letzten 2 Stellen des topics auf "pure Zahl" geprueft, und daraus entweder $TEXT$ZAHL, $TEXT$ZAHL$TEXT (falls moeglich, sonst $ZAHL$TEXT) als Readingname generiert.
Danke, soweit hatte ich nicht gedacht, ist aber m.E. klasse. Bin mal gespannt, wie sich das dann in der Praxis bewährt :) .

@all: Irgendwelche Einwände, wenn die Shelly-templates dann bei Gelegenheit dieser Namenskonvention angeglichen werden? Dann gibt es keine Brüche vor/nach Anwendung der templates, und die Nummerik wird konsistenter?
Ist halt ggf. ein einmaliger Aufwand für die, die die Dinge schon im Einsatz haben, aber "up-to-date" bleiben wollen (was man nicht muß! es geht auch so...).

Zitatjson2nameValue im autocreate habe ich so abgeaendert, wie bestellt.
Auch hier: Bin mal gespannt, was uns zukünftige User dazu sagen werden...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 24 Januar 2019, 19:27:10
@Rudi
Das ist wirklich klasse wenn die kanalspezifischen Readings auch automatisch angelegt werden. Dann hat man noch weniger Nacharbeit.
Ich nehme an das Update steht dann ab Morgen zum Download zur Verfügung, oder?

@Beta-User
Ich hätte nichts dagegen wenn das Template auch entsprechend angeglichen würde. Dann wäre es wirklich konsistent.

@all
Dann bleibt nur noch zu hoffen, daß die Energy-Werte auch von allen Shellys mit Meßfunktion per MQTT zur Verfügung gestellt werden. Ich denke da gerade an den kommenden Shelly 1PM und natürlich auch Shelly Plug und den Shelly 2 (wo z.Z keine Energy-Werte zur Verfügung gestellt werden).

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 26 Januar 2019, 11:56:25
@Rudi
So, hab gerade das Update von MQTT2 installiert und das Neuanlegen per autocreate eines Shelly 4Pro getestet.

Das funktioniert jetzt perfekt. Es wird nichts mehr doppelt angelegt und die Readings werden kanalspezifisch angelegt. Damit ist eine händische Nacharbeit nicht mehr notwendig.

Vielen Dank für die schnelle Korrektur.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 28 Januar 2019, 13:10:23
Zitat von: miggun am 14 Januar 2019, 07:52:05
@:Guzzi-Charlie
Ja, seit den letzten Updates scheint Energy weg zu sein. Bei mir geht es gerade auch nicht. Hatte ich aber jetzt schon ein paar mal. Dann kam wieder ein Update von Shelly und es ging wieder. Darauf hoffe ich gerade.

Hallo,
Gerade habe ich eine Antwort vom Shelly-Support bekommen lt. der die energy-Werte mit dem nächsten FW-Update ("Middle of the February with next FW update") wieder funktionieren soll.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: lewej am 17 Februar 2019, 12:16:18
Hallo zusammen,

die shellies publishen ja ihre Werte(fw_update und noch paar INfos) ins topic shellies/announce.

Wenn ich folgendes setze:
shellies/announce:.* { json2nameValue($EVENT) }

werden folgende Readings ertellt:
fw_ver
id
ip
mac
new_fw


Wenn man mehrere shellies hat, dann publishen dort alle rein. Kann man die Readings anhand der ID irgendwie bennen?

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Februar 2019, 14:57:15
Zitat von: lewej am 17 Februar 2019, 12:16:18
Hallo zusammen,

die shellies publishen ja ihre Werte(fw_update und noch paar INfos) ins topic shellies/announce.
Ist das so?

In den templates ist das so hinterlegt, dass jedes "sein" announce auch unter dem eigenen Namen macht: "shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\"

Gab es da Änderungen?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: lewej am 17 Februar 2019, 16:10:44
Hi,

Also ich habe shellies/# subscribed und es ist immer nur unter shellies/announce was gepublished worden und nicht unter dem device.

Ich hab die 1.4.7 revertwifi firmware drauf.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Februar 2019, 16:21:54
Hmm, wenn nicht der JSON-Blob selbst Infos dazu enthält, zu was er gehört, wird das schwierig...

Mehr kann ich dazu aber nicht sagen, habe nach wie vor keinen Shelly...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: lewej am 17 Februar 2019, 16:45:39
Zitat von: Beta-User am 17 Februar 2019, 16:21:54
Hmm, wenn nicht der JSON-Blob selbst Infos dazu enthält, zu was er gehört, wird das schwierig...

Mehr kann ich dazu aber nicht sagen, habe nach wie vor keinen Shelly...

Doch der Json Blob enthält infos dazu, ich weiss nur nicht wie ich das readlist aufbauen soll.

{"id":"shellyswitch-IDID","mac":"MAC","ip":"IP","new_fw":false, "fw_ver":"20190214-074442/1.4.7-revertwifi@0f3372b3"}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 17 Februar 2019, 20:24:18
Es gibt mehrere Wege:
- mit etwas Perl-Akrobatik, z.Bsp. indem man statt json2nameValue eine eigene Routine aufruft, die wiederum json2nameValue "nachbehandelt".
- regexp mit IP im readingsList, und jsonmap, der die "falschen" Eintraege wegfiltert.
- am einfachsten fuer FHEM waere die topics im Sender zu separieren.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 08 März 2019, 20:42:51
Hallo,
mich würde interessieren wie ihr überprüft ob der Shelly online ist.
Ich beschäftige mich erst seit kurzem mit MQTT2. Deshalb, falls ich hier etwas übersehen/überlesen habe, nicht gleich schlagen ;)

Nach dem Autocreate und Auswahl des Shellytyps funktionieren diese auf anhieb. Vielen Dank für die Vorarbeit!!!
Nun habe ich testweise das MQTT im Shelly deaktiviert und musste feststellen, dass die Geräte auch weiterhin, nach dem anklicken, munter an und aus angezeigt werden, obwohl real nichts passiert.

Ich habe dann diese Attribute hinzugefügt.

attr Flurlicht_EG devStateIcon on:rc_GREEN:off off:rc_RED:on absent:rc_BLUE:off
attr Flurlicht_EG stateFormat {ReadingsVal($name,"online","") eq "false" ? "absent" : ReadingsVal($name,"relay0","")}
attr Flurlicht_EG webCmd :


Da die Shellys bei mir mal so, mal so angelegt werden, musste ich bei manchen noch folgendes Attribut ergänzen
attr Flurlicht_EG readingList shellies/shellyswitch-XXXXXX/online:.* online\

Jetzt verhält es sich so: Wenn der Shelly nicht erreichbar ist kann ich das erst nach anklicken sehen, da das "online" scheinbar nicht ohne weiteres abgefragt/gesendet wird.

Wie bekommt ihr das hin sofort im WebIf zu sehen ob die Geräte erreichbar sind ohne jedes anklicken zu müssen?

Danke und Gruß


Edit: Hat sich erledigt!!!! Funktioniert so wie beschrieben! Man(n) muss nur etwas abwarten können ;)

Ich hätte aber gleich noch eine Frage:
Kann man den MQTT2-Server noch anders absichern als über "allowed_WEB"?
Ich würde ungern in Geräten die, zB. bei Updates oä., online gehen dürfen mein User/Pass von meinem Fhem hinterlegen.

Danke
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 09 März 2019, 10:01:26
Zitat von: kabanett am 08 März 2019, 20:42:51
Kann man den MQTT2-Server noch anders absichern als über "allowed_WEB"?
Du kannst ohne weiteres eine eigene allowed-Instanz anlegen und dann mit anderen Passwörtern arbeiten.

Was das offline angeht: Evtl. hast du direkt ohne Warten ähnliche Ergebnisse, wenn du setStateList nutzt (on off toggle). Dann sollte das Lampensymbol mit dem Ausrufezeichen kommen, bis die Bestätigung da ist, dass der Aktor den Befehl erhalten hat.
Wenn gewünscht, kann ich sowas (setStateList) gerne in die shelly-templates einbauen; bei den tasmotas scheint das Standard zu sein.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 09 März 2019, 14:35:10
Zitat von: Beta-User am 09 März 2019, 10:01:26
Du kannst ohne weiteres eine eigene allowed-Instanz anlegen und dann mit anderen Passwörtern arbeiten.

Danke für den Hinweis! Mal schauen wie das wieder funktioniert  :-[
Für mich wäre es logisch dies im Modul selbst vergeben zu können. So wie in anderen Modulen auch! Naja, es ist wies ist ;)

Zitat von: Beta-User am 09 März 2019, 10:01:26
Was das offline angeht: Evtl. hast du direkt ohne Warten ähnliche Ergebnisse, wenn du setStateList nutzt (on off toggle)

Ausprobiert und funktioniet, bei mir, nicht! Hier muss man wirklich erst das Icon anklicken um das Ausrufelämpchen zu sehen. Ich habe 3 Minuten gewartet.
So wie ich es mache ist es spätestens nach ner Minute von selbst sichtbar :)

DAnke und Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: mele am 12 März 2019, 08:53:03
Hallo zusammen,

hat schon jemand versucht via mqtt2 Shellies zu updaten?

Laut API soll das per mqtt möglich sein, ich blicke hier aber nicht durch.

Wenn ja, ist eine Aufnahme in die Templates sinnvoll?

Vielen Dank und Gruß

Mele
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: miggun am 12 März 2019, 09:26:55
Mit MQTT ist das nicht vorgesehen.
Wo hast Du das gelesen?

Auszug von der Website:
MQTT in Relay mode

In relay mode, the following topics can be used to read and set output channels 0 and 1:

    shellies/shellyswitch-<deviceid>/relay/<i> to report status: on, off or overpower
    shellies/shellyswitch-<deviceid>/relay/<i>/command accepts on and off and applies accordingly

The device measures the total consumption on both channels, which can be seen on:

    shellies/shellyswitch-<deviceid>/relay/power reports instantaneous power consumption rate in Watts
    shellies/shellyswitch-<deviceid>/relay/energy reports amount of energy consumed in [10 * Wh]

MQTT in Roller mode

When configured to operate in roller mode, MQTT topics used by Shelly2 are:

    shellies/shellyswitch-<deviceid>/roller/0 reports the current state: open, close while in motion, stop when not moving.
    shellies/shellyswitch-<deviceid>/roller/0/command accepts rc (performs roller calibration), open, close and stop.

New in v1.4.0: roller mode position control. For this to work, the device must first be successfully calibrated, so that the time it takes for closing and opening are known.

    shellies/shellyswitch-<deviceid>/roller/0/pos reports the current position in percent
    shellies/shellyswitch-<deviceid>/roller/0/command/pos accepts a number between 0 and 100, which is target position in percent.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Brandensittich am 12 März 2019, 15:33:09
Zitat von: miggun am 12 März 2019, 09:26:55
Mit MQTT ist das nicht vorgesehen.
Wo hast Du das gelesen?
Die Info stammt aus der Shelly API Documentation:

https://shelly-api-docs.shelly.cloud/#common-mqtt-commands

ZitatCommon MQTT commands

Shellies support a set of commands published on shellies/command or shellies/<shellymodel>-<deviceid>/command to address an individual device:

    announce will trigger an announce packet by every Shelly connected to the broker on shellies/announce
    update will cause all Shellies to publish their state
    update_fw to perform a firmware update when one is available.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Brandensittich am 12 März 2019, 15:42:54
Hallo zusammen, ich komme nicht weiter.
Ich habe einen Shelly 1 als MQTT2_DEVICE angebunden. Ein und Ausschalten funktioniert von FHEM aus. Wenn ich im Shelly Webinterface oder per Lichtschalter (an SW) schalte sehe ich in FHEM auch, dass sich das Reading ändert. Im Event-Monitor ist das auch sichtbar. Ich schaffe es jedoch nicht, dass sich in FHEM auch der STATE ändert, sodass ich sehe ob das Device on oder off ist.

Hier das Listing:

Internals:
   CID        shelly1_22F1C8
   DEF        shelly1_22F1C8
   DEVICETOPIC MQTT2_shelly1_22F1C8
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 253
   MQTT2_TIME 2019-03-12 15:37:04
   MSGCNT     253
   NAME       MQTT2_shelly1_22F1C8
   NR         284
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-03-12 15:25:04   fw_ver          20190311-121907/v1.4.8@e44d9e2c
     2019-03-12 15:25:04   id              shelly1-22F1C8
     2019-03-12 15:25:04   ip              10.6.77.163
     2019-03-12 15:25:04   mac             3E71BF22F1C8
     2019-03-12 15:25:04   new_fw          false
     2019-03-12 15:25:04   online          true
     2019-03-12 15:37:04   shellies/shelly1-22F1C8/input/0 0
     2019-03-12 15:37:04   shellies/shelly1-22F1C8/relay/0 on
     2019-03-12 14:51:06   state           off
Attributes:
   IODev      MQTT2
   readingList shelly1_22F1C8:shellies/shelly1-22F1C8/online:.* online
shelly1_22F1C8:shellies/announce:.* { json2nameValue($EVENT) }
shelly1_22F1C8:shellies/shelly1-22F1C8/relay/0:.* shellies/shelly1-22F1C8/relay/0
shelly1_22F1C8:shellies/shelly1-22F1C8/input/0:.* shellies/shelly1-22F1C8/input/0
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shelly1-22F1C8/relay/0/command off
on:noArg  shellies/shelly1-22F1C8/relay/0/command on


Hier die Ausgabe aus dem Event-Monitor:

2019-03-12 15:36:34 MQTT2_DEVICE MQTT2_shelly1_22F1C8 shellies/shelly1-22F1C8/relay/0: on
2019-03-12 15:36:34 MQTT2_DEVICE MQTT2_shelly1_22F1C8 shellies/shelly1-22F1C8/input/0: 0
2019-03-12 15:37:04 MQTT2_DEVICE MQTT2_shelly1_22F1C8 shellies/shelly1-22F1C8/relay/0: on
2019-03-12 15:37:04 MQTT2_DEVICE MQTT2_shelly1_22F1C8 shellies/shelly1-22F1C8/input/0: 0


Wäre jemand bereit mir zu helfen?

Vielen Dank und viele Grüße
Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 März 2019, 15:50:36
Zitat von: mele am 12 März 2019, 08:53:03
Wenn ja, ist eine Aufnahme in die Templates sinnvoll?
Wenn das "nur" darauf hinausläuft, das update anzustoßen, ohne eine lokale Quelle zu haben, würde ich mal sagen: möglich, aber lohnt eher nicht, das geht (vermutlich) fast so komfortabel über die Weboberfläche, und wer alle updaten will, kann das über das IO direkt publishen...

Wenn jemand mag, kann er ja ein entsprechendes template erstellen, das müßte dann nur darin bestehen, das IO zu ermitteln (Muster: tasmota- Umstellung auf Klenschriebung) und den korrekten Pfad, um für den jeweiligen shelly den updatevorgang anzustoßen. Wenn's eines gibt, packe ich es dazu.

@Brandensittich: Entweder das shelly1-template anwenden oder (ggf. zusätzlich) die Rückmeldung an relay/0 auf state umbiegen (was auf's selbe rausläuft) (Siehe wiki zu den Praxisbeispielen@MQTT2)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Brandensittich am 12 März 2019, 16:30:25
Zitat von: Beta-User am 12 März 2019, 15:50:36
@Brandensittich: Entweder das shelly1-template anwenden oder (ggf. zusätzlich) die Rückmeldung an relay/0 auf state umbiegen (was auf's selbe rausläuft) (Siehe wiki zu den Praxisbeispielen@MQTT2)
Vielen Dank! Nach einem Update konnte ich jetzt auch die Templates nutzen. Daran war ich die ganze Zeit verzweifelt... Funktioniert.
Titel: Tasmota Dimmer
Beitrag von: stefan-dd am 22 März 2019, 21:53:27
Hallo, ich möchte einen Tasmota Dimmer einbinden.
Ein/Aus funktioniert. Wie müsste "setlist" definiert werden? Der Slider wird angezeigt, ruft aber keine Reaktion hervor.

attr MQTT2_DVES_2725AE setList Dimmer:slider,0,1,100 /dimmer/bad/cmnd/Dimmer\

Kann mir jemand helfen?

defmod MQTT2_DVES_2725AE MQTT2_DEVICE DVES_2725AE
attr MQTT2_DVES_2725AE IODev MQTT_Server
attr MQTT2_DVES_2725AE alias Bad LED
attr MQTT2_DVES_2725AE devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr MQTT2_DVES_2725AE readingList DVES_2725AE:dimmer/bad/tele/LWT:.* LWT\
DVES_2725AE:dimmer/bad/cmnd/POWER:.* POWER\
DVES_2725AE:dimmer/bad/tele/INFO1:.* { json2nameValue($EVENT) }\
DVES_2725AE:dimmer/bad/tele/INFO2:.* { json2nameValue($EVENT) }\
DVES_2725AE:dimmer/bad/tele/INFO3:.* { json2nameValue($EVENT) }\
DVES_2725AE:dimmer/bad/stat/RESULT:.* { json2nameValue($EVENT) }\
DVES_2725AE:dimmer/bad/stat/POWER:.* POWER\
DVES_2725AE:dimmer/bad/tele/STATE:.* { json2nameValue($EVENT) }\
DVES_2725AE:dimmer/bad/tele/UPTIME:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_2725AE room MQTT2_DEVICE
attr MQTT2_DVES_2725AE setList Dimmer:slider,0,1,100 /dimmer/bad/cmnd/Dimmer\
on dimmer/bad/cmnd/POWER on\
off dimmer/bad/cmnd/POWER off
attr MQTT2_DVES_2725AE webCmd Dimmer:on:off

setstate MQTT2_DVES_2725AE Dimmer
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Dimmer 61
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Fade ON
setstate MQTT2_DVES_2725AE 2019-03-22 21:39:14 FallbackTopic cmnd/DVES_2725AE_fb/
setstate MQTT2_DVES_2725AE 2019-03-22 21:39:14 GroupTopic sonoffs
setstate MQTT2_DVES_2725AE 2019-03-22 21:39:14 Hostname bad-1454
setstate MQTT2_DVES_2725AE 2019-03-22 21:39:14 IPAddress 192.168.1.219
setstate MQTT2_DVES_2725AE 2019-03-22 21:40:35 LWT Online
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 LedTable OFF
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 LoadAvg 999
setstate MQTT2_DVES_2725AE 2019-03-22 21:39:14 Module Generic
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 POWER ON
setstate MQTT2_DVES_2725AE 2019-03-22 21:39:14 RestartReason Power on
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Sleep 0
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 SleepMode Dynamic
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Speed 5
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Time 2019-03-22T21:44:30
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Uptime 0T00:05:24
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Vcc 3.458
setstate MQTT2_DVES_2725AE 2019-03-22 21:39:14 Version 6.4.1(sonoff)
setstate MQTT2_DVES_2725AE 2019-03-22 21:39:14 WebServerMode Admin
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Wifi_AP 1
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Wifi_BSSId 7C:FF:4D:5A:F0:56
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Wifi_Channel 11
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Wifi_RSSI 52
setstate MQTT2_DVES_2725AE 2019-03-22 21:44:30 Wifi_SSId Airport
setstate MQTT2_DVES_2725AE 2019-03-22 21:45:44 state Dimmer

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 22 März 2019, 22:19:40
Hier ist der Shelly-MQTT-Bereich...

Was hat Tasmota damit zu tun?

Hast du schon mal geschaut, ob ein passendes template verfügbar ist?

Wenn du keines findest: es gibt einige Dimmer-Devices im mqtt2.template-file, da mußt du dich nur bedienen ;) .

Bitte an den Rest: Ihr braucht ihm  nicht noch weiter zu helfen, wenn er die Regeln so "sträflich" mißachtet...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 27 April 2019, 09:53:01
Moin moin zusammen,

da ich keine bessere Ecke dafür gefunden habe, mache dies mal hier. Habe 2x Shelly 1PM verbaut und wollte mal die Readings beisteuern. An einem Template bin ich noch nicht dran aber das kann ich ggf. dieses WE beginnen. An sich nutze ich nun noch das normale Shelly1 Template. Das ist soweit auch okay nur die Energie-Werte fehlen eben in diesem Template. Denke die Ansicht kann dadurch etwas schöner werden.


Internals:
   CFGFN     
   CID        shelly1pm_B1D951
   DEF        shelly1pm_B1D951
   DEVICETOPIC sz_deckenlicht
   FUUID      5cc4074e-f33f-fcb4-2a2d-5a4b3c845d1a880d
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 271
   MQTT2_FHEM_Server_TIME 2019-04-27 10:06:37
   MSGCNT     271
   NAME       sz_deckenlicht
   NR         497
   STATE      off
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-04-27 10:06:29   fw_ver          20190423-080637/v1.4.9-switch1pm-hotfix4@f8c51629
     2019-04-27 10:06:29   id              shelly1pm-B1D951
     2019-04-27 10:06:29   input0          0
     2019-04-27 10:06:29   ip              192.168.xxx.xxx
     2019-04-27 10:06:29   mac             840D8EB1D951
     2019-04-27 10:06:29   new_fw          false
     2019-04-27 10:06:29   online          true
     2019-04-27 10:06:29   overtemperature 0
     2019-04-27 10:06:37   relay0          off
     2019-04-27 10:02:55   relay_0_energy  50
     2019-04-27 10:06:29   relay_0_power   0.00
     2019-04-27 10:06:37   state           off
     2019-04-27 10:06:29   temperature     33.73
Attributes:
   IODev      MQTT2_FHEM_Server
   alexaName  Schlafzimmer Deckenlicht
   alias      Schlafzimmer Deckenlicht
   autocreate 1
   model      A_10_shelly1
   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) }
shelly1pm_B1D951:shellies/shelly1pm-B1D951/relay/0/power:.* relay_0_power
shelly1pm_B1D951:shellies/shelly1pm-B1D951/temperature:.* temperature
shelly1pm_B1D951:shellies/shelly1pm-B1D951/overtemperature:.* overtemperature
shelly1pm_B1D951:shellies/shelly1pm-B1D951/relay/0/energy:.* relay_0_energy
shelly1pm_B1D951:shellies/shelly1pm-B1D951/longpush/0:.* longpush_0
shelly1pm_B1D951:shellies/announce:.* { json2nameValue($EVENT) }
   room       MQTT,Schlafzimmer
   setList    relay0:on,off,toggle shellies/shelly1pm-B1D951/relay/0/command $EVTPART1
   webCmd     :relay0


Was wird noch benötigt? Also FHEM-Seitig bekomme ich alle Werte, die auch im Schalter zu sehen sind.

PS: Weiß nicht ob das für jemanden wichtig ist aber einen Shelly hab ich einfach als normalen Schalter in Betrieb und den anderen in einer Wechselschaltung.

EDIT: Der Shelly 1PM kann Wochen, Monats oder Jahresdaten nur in der Cloud speichern. Also müsste man bei Bedarf so etwas selber über ein Reading lösen. Ich selber nutze die Cloud natürlich nicht und will es auch nicht. Weswegen ich mir früher oder später so ein Reading anlegen werde.

Was ich hier nicht verstehe ist warum stateFormat hier kein:
<a href="http://ip" target="_blank">
online
</a>
state

will. Normal könnte ich nun auf online klicken und lande auf dem Webinterface. Anstelle dessen, schaltet er aber nur, so wie als würde ich auf state klicken. Außer man ändert die setList auf "   
relay0:on,off,toggle shellies/shelly1pm-B1D951/relay/0/command $EVTPART1", hätte dann aber ein Dropdown menu.


EDIT2:
Anbei mal mein Vorschlag als Bild... So finde ich es schön und nützlich. Was sagt Ihr?
Grüner Kreis = Online/Offline Status + Webinterface
Lampen-Symbol = An/Aus des Verbrauchers dahinter
Freier Text = Aktuelle Verbrauchsdaten, die vom Shelly 1PM geliefert werden.

devStateIcon: true:10px-kreis-gruen@green false:10px-kreis-rot@red on:light_pendant_light:relay0+off off:light_pendant_light:relay0+on
setList: relay0:on,off,toggle shellies/shelly1pm-B1D951/relay/0/command $EVTPART1
stateFormat:
<a href="http://ip" target="_blank">
online
</a>
relay0
<br>
Aktueller Verbrauch: relay_0_power
webCmd: :relay0
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Hellspawn am 27 April 2019, 16:23:39
Hi,

find ich gut so. Erstellst Du dafür ein Template ?

Gruß
Carsten
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 28 April 2019, 09:42:25
Hab es leider noch nicht geschafft. Aber kann/werde ich machen. Es müsste ja nur eine kleine Abwandlung von shelly 1 sein.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 29 April 2019, 07:47:11
Moin Moin,

anbei mein Vorschlag für einen Shelly1pm:

Template:
# shelly1pm using original firmware.
name:A_10b_shelly1pm
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* relay_0_energy\
  shellies/DEVNAME/longpush/0:.* longpush_0\
  shellies/announce:.* { json2nameValue($EVENT) }
attr DEVICE devStateIcon true:10px-kreis-gruen@green false:10px-kreis-rot@red on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on
attr DEVICE stateFormat <a href="http://ip" target="_blank">\
online\
</a>\
relay0\
<br>\
Aktueller Verbrauch: relay_0_power\
<br>\
Tempertur: temperature °C
attr DEVICE webCmd :relay0
deletereading -q DEVICE [^(associatedWith)]*
attr DEVICE model A_10b_shelly1pm


Bei setList habe ich on/off nochmal einzeln, damit Alexa hier auch mitspielt. Das Symbol bei devStateIcon dient nur der Veranschaulichung.
Ansonsten, wie oben bereits beschrieben....

Bild anbei....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 29 April 2019, 20:21:45
Thx, hab's eingecheckt!

@all: mit den jüngsten Änderungen bei SetExtensions und zigbee2mqtt_devStateIcon255() (https://forum.fhem.de/index.php/topic,99957.0.html) wäre es auch möglich, laufende SetExtensions-Timer bei den Shellys grafisch darzustellen. Wenn jemand sich das nicht selbst zutraut, aber daran Interesse hat und das dann live testen würde, kann ich das gerne irgendwo zur Demo einbauen, hier war es etwas komplizierter, da ja weitere Readings im STATE angezeigt werden sollten...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 April 2019, 08:00:07
Zuerst danke an dieser stelle! Finde es schön zu sehen das man an der Template Entwicklung wirklich mit wirken kann. [emoji5]

Nun ist es so, das ich einen Wunsch hätte. Ich weiß nicht ob ich es überlesen habe oder ob es einfach nicht geht...

Wenn ich ein Template entwickel, welches wie beim shelly 1 zum shelly 1 pm einfach nur ein paar mehr readings hat, würde ich gerne die Möglichkeit haben readings oder sonst was hinzu zu fügen. Also zuerst das shelly1 Template übernehmen und danach die Zusatz readings hinzufügen. Aktuell überschreibt man mit dem setzen von zb Setlist direkt alles was drin steht. Ggf ist das durch ein Zusatz Attribut möglich.

Anstelle von attr Device SetList 1 2 3 und dem damit verbundenem überschreiben des ganzen attributes. Wäre eine Art attr Device +setList 1 2 3 und dann würden diese werte einfach nur hinzugefügt. Habe in einigen templates ähnliche Fälle gesehen und das würde die template Datei um einiges kürzen. Was immer geht ist zb tasmota Befehle ab zu setzen und das über mehrere templates hinweg. Das sieht man zb im Roller shutter invert_0/1.

Was sagst du dazu Beta-User? Was meinem die anderen?

Hoffe man versteht was ich meine... Danke u bis dahin [emoji5]

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 30 April 2019, 09:28:55
Zitat von: 87insane am 30 April 2019, 08:00:07
Zuerst danke an dieser stelle! Finde es schön zu sehen das man an der Template Entwicklung wirklich mit wirken kann. (https://emoji.tapatalk-cdn.com/emoji5.png)
Dank zurück!
Ohne eure Mitwirkung könnte ich an der Stelle (fast) nichts für die community tun - ich habe schließlich nur ganz wenig eigene Hardware, und manchmal braucht man die schon (z.B., wenn man die Änderungen des state nachvollziehen will, wenn SetExtensions ins Spiel kommen) ;) .

ZitatNun ist es so, das ich einen Wunsch hätte. Ich weiß nicht ob ich es überlesen habe oder ob es einfach nicht geht...
[...]
Hmm, "möglich" ist vieles, man kann ja mit "par" Perl nutzen ;) .

ABER:
Schon das "Verschachteln" von attrTemplates (das ist wohl, was du mit "ähnliche Fälle" meinst) macht es für manche user unübersichtlich und ist auch von einem übergeordneten Standpunkt her möglicherweise etwas "unsauber", von daher will ich eigentlich da nicht ohne Not noch weiter (=>par) gehen. Dann wäre der Perlcode für par auch eher komplex; man müßte insbesondere prüfen, ob das, was man reinhaben will schon da ist usw..
Verschachteln darfst du gerne, es sollte nur ein gewisser Standard eingehalten werden; auch die tasmota-templates (da wird es viel genutzt) stellen im Kern nur ein paar Basis-Vorgaben am ESP8266 selbst ein, damit das einheitlich ist. Ansonsten sind es oft Varianten, bei denen weitere Readings vorhanden sind, die dann im stateFormat berücksichtigt werden usw..
Für readingList lohnt sich das m.E. auch nicht wirklich, da könnte man auch einfach autocreate einschalten und die Liste erweitern lassen (mit dem "richtigen" Modus, sonst passen die Readingnamen eventuell nicht zu dem, was z.B. stateFormat erwartet).

(Ich hoffe, das ist verständlich geschrieben...)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 30 April 2019, 09:58:49
Etwas OT, aber gerade im template gesehen:
deletereading -q DEVICE [^(associatedWith)]*loescht vmtl nicht das, was ein Regexp-Unkundiger denken wuerde :)

deletereading packt (notify-ueblich) das letzte Argument in ^$, was als regexp ausgewertet wird.
Mit [^(associatedWith)]* werden nur die Readings geloescht, die keins der im [] erwaehnten Buchstaben enthalten, und ich behaupte, es gibt aktuell kein Reading, was deswegen entfernt wird.
"Alles bis auf" ist im Regexp "hoehere Schule", ich meine (?!associatedWith).* tut das.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 April 2019, 09:59:33
Wer in die Template Datei rein sieht, sieht das in meinen Augen sehr übersichtlich. Doppeleinträge dürften ja ruhig überschrieben werden. Nur zusätzliche Einträge sollten bestehen bleiben. Hier geht es auch nicht um SetList alleine. Gemeint sind alle attr. Finde gerade das Beispiel shelly1 zu shelly1 pm interessant hier.

Ich verstehe was du meinst, bin an der stelle aber anderer Meinung. Mehr Text = mehr sucherei. Perl ist in der tat an der stelle etwas überdimensioniert.
Ein Template macht (so wie ich das verstehe) nichts anderes als luxus für den User, da dieser einfach alles eingestellt bekommt. Wer es anders mag, muss selber hand anlegen. Oder aber kann als Inspiration einfach andere templates testen oder aber in der Datei nachsehen und "klauen"... Sorry für das wort aber mache ich ja genauso.

Es macht natürlich nicht überall Sinn bis ins tiefste zu verschachteln. Aber wie es auch zb in einer AD ist...es wird generell jeder User über Gruppen an seine Berechtigung geführt. So würde ich das hier auch sehen. Ein Grund Template und alles weitere wird quasi für das jeweilige gerät mit übernommen.


Edit: hatte es auch gesehen... Hab mir nix dabei gedacht, da es zuvor deletereading .* war. Dies war auch in diversen anderen templates so. Allerdings aus einem mir unbekannten Grund, wurde das angepasst. Ich habe das so mit übernommen nachdem ich das sah. Quasi ohne drüber mach zu denken. Hier kann Beta-User aber sicher mehr sagen. Leider oder zum Glück stecke ich nicht in allen templates so tief drin wie er.

Gesendet von meinem LG-H850 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 30 April 2019, 10:30:22
Zitat von: rudolfkoenig am 30 April 2019, 09:58:49
"Alles bis auf" ist im Regexp "hoehere Schule", ich meine (?!associatedWith).* tut das.
:o Du hast natürlich reicht, eigentlich hatte ich geglaubt, das erfolgreich getestet zu haben...
update kommt bei nächster Gelegenheit, Danke für den Hinweis :) .

Zitat von: 87insane am 30 April 2019, 09:59:33
Wer in die Template Datei rein sieht, sieht das in meinen Augen sehr übersichtlich.
Danke, ich will mir selbst und anderen ja auch nicht das Leben schwerer machen, sondern es ist ja grade - neben der Vereinfachung für die, die es "schnell und unkompliziert" haben wollen - auch Sinn und Zweck, eine Art "best-practice"-Sammlung zu haben, aus der sich jeder nach Belieben bedienen darf :) . (Dass dann auch mal was "sinnfreies" kopiert wird, kommt leider eben auch vor... ::) )

Es gibt da übrigens noch mehr Dinge, die man verbessern kann; z.B. sind noch einige userreadings drin, die keine Trigger-Angabe haben. Sowas will ich z.B. zukünftig eigentlich nicht mehr einchecken bzw. bei Gelegenheit auch verbessern (braucht aber für mehr als eine Plausibilitätsprüfung Rückmeldung/Hardware, sonst hätte ich das teilweise schon gemacht...)

ZitatFinde gerade das Beispiel shelly1 zu shelly1 pm interessant hier.
Du darfst gerne Verbesserungsvorschläge machen, mir erschließt sich im Moment das Beispiel nicht so ganz; wenn es nur eine oder zwei Zeilen sind, die zudem nicht fehlerträchtig erscheinen, braucht es m.E. aber keine Verschachtelung (da viel schwerer zu durchschauen, wenn sich jemand mal "Bedienen" will).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 April 2019, 11:53:57
Da sich kein anderer dazu äußert, kann ich argumentativ nicht nach legen ;) dann wird es eben so bleiben. An sich komme ich ganz gut klar seit dem Rollo template für tasmota. Weswegen es in meinen Augen besser mit verschachteln wäre.

Man könnte zb diese ganzen devstate Icons auch auslagern. Und wer für Rollo zb die ganzen pct Bilder haben will nimmt in dem fall einfach 99_Rollo_Bilder/Icons. Ich denke du weis worauf ich hinaus will. Es geht mir wirklich nur um sich wiederholende Dinge.

Aber so seie es... Ggf ist das in 1-2 Jahren interessanter, sobald das Konstrukt so nicht mehr übersichtlich sein kann. Immerhin kommen fast jeden Tag irgendwelche neuen LoT geräte raus und dann kann man immer noch weiter sehen. Schaue mir nachher erst mal an wie es eingecheckt ist. Am handy mag ich ungern im SVN wühlen. Alleine wegen der Bildschirm Größe ...

Danke schon mal und bis zum nächsten Template :)

PS: als nächstes kommt bei mir shelly 2.5 Rollo shutter dran. Mal sehen ob es da schon was gutes/schönes gibt.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 30 April 2019, 18:29:37
ZitatPerl ist in der tat an der stelle etwas überdimensioniert.
Pardon, aber das halte ich für Quark - genau dafür wurde Perl nämlich geschaffen.

LG

pah
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 April 2019, 18:38:30
Entschuldige meine dummen Worte. Das man das verstehen kann, wie es gemeint sein könnte, ist aber klar oder? Hinzu, was trägt dein Kommentar ohne Code oder sinnvolle Infos, der Gemeinde bei?

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 08:56:02
Guten Morgen zusammen,

folgendes ist mir aufgefallen und ich finde keine Antwort dafür. Wenn man im StateFormat diesen online/offline Kreis einblendet (siehe z.B. Shelly1pm Template), dann kann man diesen anklicken und man landet auf dem Webinterface des Gerätes. Sobald man in setList aber
off:noArg shellies/shelly1pm-B1D951/relay/0/command off
on:noArg shellies/shelly1pm-B1D951/relay/0/command on


also on und off setzt, damit auch via Alexa gesteuert werden kann, kann man den online/offline Kreis nicht anklicken. Wenn man es macht, wird der Shelly eingeschaltet bzw. sein relay. Sobald man on/off aus setList löscht und nur:
relay0:on,off,toggle shellies/shelly1pm-B1D951/relay/0/command $EVTPART1
einfügt, kann man auch den kleinen Kreis anklicken. Allerdings erkennt Alexa dann das Gerät nicht mehr als Schalter und man kann ihn nicht mehr schalten....

List -r von einem der Shellys:
define sz_deckenlicht MQTT2_DEVICE shelly1pm_B1D951
attr sz_deckenlicht IODev MQTT2_FHEM_Server
attr sz_deckenlicht alexaName Schlafzimmer Deckenlicht
attr sz_deckenlicht alias Schlafzimmer Deckenlicht
attr sz_deckenlicht autocreate 1
attr sz_deckenlicht devStateIcon true:10px-kreis-gruen false:10px-kreis-rot .*SetExtensionsCommand.*:1px-spacer on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on on-.*:on-for-timer:relay0+off off-.*:off-for-timer:relay0+on blink.*:light_toggle:relay0+off
attr sz_deckenlicht event-on-change-reading .*
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 Alexa,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\
<br>\
Aktueller Verbrauch: relay_0_power W\
<br>\
Temperatur: temperature °C
attr sz_deckenlicht webCmd :relay0

setstate sz_deckenlicht <a href="http://192.168.xxx.xxx" target="_blank">\
true\
</a>\
on\
<br>\
Aktueller Verbrauch: 5.61 W\
<br>\
Temperatur: 32.04 °C
setstate sz_deckenlicht 2019-04-30 16:50:34 fw_ver 20190423-080637/v1.4.9-switch1pm-hotfix4@f8c51629
setstate sz_deckenlicht 2019-04-30 16:50:34 id shelly1pm-B1D901
setstate sz_deckenlicht 2019-05-02 08:53:56 input0 0
setstate sz_deckenlicht 2019-04-30 16:50:34 ip 192.168.xxx.xxx
setstate sz_deckenlicht 2019-04-30 16:50:34 mac 840D8EB1D901
setstate sz_deckenlicht 2019-04-30 16:50:34 new_fw false
setstate sz_deckenlicht 2019-04-30 16:49:52 online true
setstate sz_deckenlicht 2019-05-02 08:53:56 overtemperature 0
setstate sz_deckenlicht 2019-05-02 08:54:08 relay0 on
setstate sz_deckenlicht 2019-05-02 08:54:10 relay_0_energy 588
setstate sz_deckenlicht 2019-05-02 08:54:10 relay_0_power 5.61
setstate sz_deckenlicht 2019-05-02 08:54:08 state on
setstate sz_deckenlicht 2019-05-02 08:53:56 temperature 32.04


Ideen?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 09:26:32
Hmm, würde mal vermuten, dass das daher kommt, dass true/1/on und false/0/off häufig synonym verwendet werden. Ergo sollte sich das Problem lösen lassen, wenn man dafür sorgt, dass nicht nur "true" in einer Zeile steht.

Versuche es mal mit einem zusätzlichen "Marker" (hier: c für connection, das ist aber an sich völlig willkürlich):attr sz_deckenlicht devStateIcon c.true:10px-kreis-gruen c.false:10px-kreis-rot .*SetExtensionsCommand.*:1px-spacer on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on on-.*:on-for-timer:relay0+off off-.*:off-for-timer:relay0+on blink.*:light_toggle:relay0+offattr sz_deckenlicht stateFormat <a href="http://ip" target="_blank">\
c:online\
</a>\
relay0\
<br>\
Aktueller Verbrauch: relay_0_power W\
<br>\
Temperatur: temperature °C

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 09:40:34
Hey und guten Morgen,

hilft leider nicht. Egal ob mit [gerät:reading] oder einfach ohne magic gearbeitet wird in stateFormat.
Nehme ich on/off in setList mit auf ist das "Problem" da und lösche ich die beiden Zeilen, ist das Problem weg. Allerdings ist damit dann auch die Alexa Steuerung weg....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 10:40:31
Argh, da ist ein attr verloren gegangen, nur devStateIcon reicht nicht, die zweite Zeile war für stateFormat gedacht...
attr sz_deckenlicht devStateIcon c.true:10px-kreis-gruen c.false:10px-kreis-rot .*SetExtensionsCommand.*:1px-spacer on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on on-.*:on-for-timer:relay0+off off-.*:off-for-timer:relay0+on blink.*:light_toggle:relay0+offattr sz_deckenlicht stateFormat <a href="http://ip" target="_blank">\
attr sz_deckenlicht stateFormat c:online\
</a>\
relay0\
<br>\
Aktueller Verbrauch: relay_0_power W\
<br>\
Temperatur: temperature °C
Kannst du bitte nochmal ein RAW-list liefern, wenn du beide Attribute wie vorgeschlagen geändert hast?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 10:48:49
Hatte ich schon erkannt... Man sieht ja was an welcher Stelle Sinn macht....
Anbei ein List von einem der Geräte....


Internals:
   CFGFN      ./FHEM/Tasmota.cfg
   CHANGED   
   CID        shelly1pm_B1D951
   DEF        shelly1pm_B1D951
   DEVICETOPIC sz_deckenlicht
   FUUID      5cc4074e-f33f-fcb4-2a2d-5a4b3c845d1a880d
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 1129
   MQTT2_FHEM_Server_TIME 2019-05-02 10:47:36
   MSGCNT     1129
   NAME       sz_deckenlicht
   NR         113
   STATE      <a href="http://:ip" target="_blank">
c:online
</a>
off
Aktueller Verbrauch: 0.00 / Temperatur: 31.99 °C
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-05-02 10:47:16   input0          0
     2019-05-02 10:47:16   overtemperature 0
     2019-05-02 10:47:36   relay0          off
     2019-05-02 10:47:36   relay_0_energy  656
     2019-05-02 10:47:36   relay_0_power   0.00
     2019-05-02 10:47:36   state           off
     2019-05-02 10:47:16   temperature     31.99
Attributes:
   IODev      MQTT2_FHEM_Server
   alexaName  Schlafzimmer Deckenlicht
   alias      Schlafzimmer Deckenlicht
   autocreate 1
   devStateIcon c.true:10px-kreis-gruen c.false:10px-kreis-rot .*SetExtensionsCommand.*:1px-spacer on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on on-.*:on-for-timer:relay0+off off-.*:off-for-timer:relay0+on blink.*:light_toggle:relay0+offattr sz_deckenlicht stateFormat <a href="http://ip" target="_blank">
   event-on-change-reading .*
   model      A_10b_shelly1pm
   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) }
   room       Alexa,MQTT,Schlafzimmer
   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
   stateFormat <a href="http://:ip" target="_blank">
c:online
</a>
relay0
Aktueller Verbrauch: relay_0_power / Temperatur: temperature °C
   webCmd     :relay0


List -r:


define sz_deckenlicht MQTT2_DEVICE shelly1pm_B1D951
attr sz_deckenlicht IODev MQTT2_FHEM_Server
attr sz_deckenlicht alexaName Schlafzimmer Deckenlicht
attr sz_deckenlicht alias Schlafzimmer Deckenlicht
attr sz_deckenlicht autocreate 1
attr sz_deckenlicht devStateIcon c.true:10px-kreis-gruen c.false:10px-kreis-rot .*SetExtensionsCommand.*:1px-spacer on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on on-.*:on-for-timer:relay0+off off-.*:off-for-timer:relay0+on blink.*:light_toggle:relay0+offattr sz_deckenlicht stateFormat <a href="http://ip" target="_blank">
attr sz_deckenlicht event-on-change-reading .*
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 Alexa,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">\
c:online\
</a>\
relay0\
Aktueller Verbrauch: relay_0_power / Temperatur: temperature °C
attr sz_deckenlicht webCmd :relay0

setstate sz_deckenlicht <a href="http://:ip" target="_blank">\
c:online\
</a>\
off\
Aktueller Verbrauch: 0.00 / Temperatur: 32.10 °C
setstate sz_deckenlicht 2019-05-02 10:49:06 input0 0
setstate sz_deckenlicht 2019-05-02 10:49:06 overtemperature 0
setstate sz_deckenlicht 2019-05-02 10:49:06 relay0 off
setstate sz_deckenlicht 2019-05-02 10:47:36 relay_0_energy 656
setstate sz_deckenlicht 2019-05-02 10:49:06 relay_0_power 0.00
setstate sz_deckenlicht 2019-05-02 10:49:06 state off
setstate sz_deckenlicht 2019-05-02 10:49:06 temperature 32.10
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 11:16:46
Hmm, der devStateIcon-Code kann kürzer sein, da wir ja das mit den SetExtensions hier nicht benötigen usw..
Dann solltest du den shelly mal neu starten (eigentlich: da steht noch kein setstate zu "online"), erst danach kann man checken, ob das wirklich funktioniert.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 11:19:03
Jo, hatte es zum testen drin gelassen...

Mit dem Neustart, ist klar.. War nach Template setzen natürlich weg und neustart aus der Ferne nur via VPN. Mache ich aber gleich. Das verhalten ist bei einem vorhandenem bzw beschriebenem Reading genau wie wenn es leer ist oder so. Werde ich aber gleich einfach nochmal senden....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 11:35:31
List:


Internals:
   CFGFN      ./FHEM/Tasmota.cfg
   CHANGED   
   CID        shelly1pm_B1D951
   DEF        shelly1pm_B1D951
   DEVICETOPIC sz_deckenlicht
   FUUID      5cc4074e-f33f-fcb4-2a2d-5a4b3c845d1a880d
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 1604
   MQTT2_FHEM_Server_TIME 2019-05-02 11:34:19
   MSGCNT     1604
   NAME       sz_deckenlicht
   NR         113
   STATE      <a href="http://192.168.20.53" target="_blank">
c:true
</a>
off
Aktueller Verbrauch: 0.00 W / Temperatur: 32.15 °C
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-05-02 11:32:16   fw_ver          20190423-080637/v1.4.9-switch1pm-hotfix4@f8c51629
     2019-05-02 11:32:16   id              shelly1pm-B1D951
     2019-05-02 11:34:06   input0          0
     2019-05-02 11:32:16   ip              192.168.20.53
     2019-05-02 11:32:16   mac             840D8EB1D951
     2019-05-02 11:32:16   new_fw          false
     2019-05-02 11:32:16   online          true
     2019-05-02 11:34:06   overtemperature 0
     2019-05-02 11:34:19   relay0          off
     2019-05-02 11:34:19   relay_0_energy  6
     2019-05-02 11:34:19   relay_0_power   0.00
     2019-05-02 11:34:19   state           off
     2019-05-02 11:34:06   temperature     32.15
Attributes:
   IODev      MQTT2_FHEM_Server
   alexaName  Schlafzimmer Deckenlicht
   alias      Schlafzimmer Deckenlicht
   autocreate 1
   devStateIcon c.true:10px-kreis-gruen c.false:10px-kreis-rot .*SetExtensionsCommand.*:1px-spacer on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on on-.*:on-for-timer:relay0+off off-.*:off-for-timer:relay0+on blink.*:light_toggle:relay0+off
   event-on-change-reading .*
   model      A_10b_shelly1pm
   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) }
   room       Alexa,MQTT,Schlafzimmer
   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
   stateFormat <a href="http://ip" target="_blank">
c:online
</a>
relay0
Aktueller Verbrauch: relay_0_power W / Temperatur: temperature °C
   webCmd     :relay0



List -r:
define sz_deckenlicht MQTT2_DEVICE shelly1pm_B1D951
attr sz_deckenlicht IODev MQTT2_FHEM_Server
attr sz_deckenlicht alexaName Schlafzimmer Deckenlicht
attr sz_deckenlicht alias Schlafzimmer Deckenlicht
attr sz_deckenlicht autocreate 1
attr sz_deckenlicht devStateIcon c.true:10px-kreis-gruen c.false:10px-kreis-rot .*SetExtensionsCommand.*:1px-spacer on:light_pendant_light@green:relay0+off off:light_pendant_light:relay0+on on-.*:on-for-timer:relay0+off off-.*:off-for-timer:relay0+on blink.*:light_toggle:relay0+off
attr sz_deckenlicht event-on-change-reading .*
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 Alexa,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">\
c: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">\
c:true\
</a>\
off\
Aktueller Verbrauch: 0.00 W / Temperatur: 32.26 °C
setstate sz_deckenlicht 2019-05-02 11:32:16 fw_ver 20190423-080637/v1.4.9-switch1pm-hotfix4@f8c51629
setstate sz_deckenlicht 2019-05-02 11:32:16 id shelly1pm-B1D951
setstate sz_deckenlicht 2019-05-02 11:34:49 input0 0
setstate sz_deckenlicht 2019-05-02 11:32:16 ip 192.168.20.53
setstate sz_deckenlicht 2019-05-02 11:32:16 mac 840D8EB1D951
setstate sz_deckenlicht 2019-05-02 11:32:16 new_fw false
setstate sz_deckenlicht 2019-05-02 11:32:16 online true
setstate sz_deckenlicht 2019-05-02 11:34:49 overtemperature 0
setstate sz_deckenlicht 2019-05-02 11:34:49 relay0 off
setstate sz_deckenlicht 2019-05-02 11:34:19 relay_0_energy 6
setstate sz_deckenlicht 2019-05-02 11:34:49 relay_0_power 0.00
setstate sz_deckenlicht 2019-05-02 11:34:49 state off
setstate sz_deckenlicht 2019-05-02 11:34:49 temperature 32.26
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 12:12:43
Hmmm, interessanter Effekt: Anscheinend wird alles neben dem Icon mit dem Setter als Befehl zur state-Änderung aufgefaßt; man kann also "irgendwohin" klicken (also auch auf die Temperatur usw.), um den state zu schalten (wobe alles, was nicht on.* ist als off interpretiert zu werden scheint, also nach on geschaltet wird)....

Ich bin da auch mit meinem Latein am Ende.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 12:24:14
Das lustige ist ja wirklich, das beim löschen von on/off aus setList, alles wieder läuft wie es soll.
Bei den Rollos z.B. gibt es auch kein on/off. Da gibt es pct, half usw. Da läuft es auch. Kann man on/off in setList ggf. anders schreiben, damit der "site effect" nicht auftritt?

Aufgrund der Erkenntnisse weiß man ja es muss im Zusammenhang stehen. Ich möchte aber auch nicht auf die Alexa Steuerung verzichten. Leider sieht diese das aber so vor das on/off existieren muss. Ansonsten kann man bei einem Shelly1pm nicht schalten über Alexa. Lustig ist, man kann aber z.B. die Temperatur abfragen.

Mal ganz blöde.... in stateFormat wird dem Online-Status explizit gesagt wo er beginnt und wo er endet. Scheint als würde hier was quer laufen innerhalb von <a> bla bla</a>. Interpretiert wird direkt das alles in stateFormat = der Link ist. Aber der Link wird nicht ausgeführt, da FHEM einfach ON schaltet. Ein OFF via online Anzeiger oder dem anderen Text geht nicht. Off geht wirklich nur über das Lampen Symbol oder aber dem Dropdown Menü (bei mir).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 13:43:52
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:
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.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 14:07:10
Ich habe auch noch ein wenig getestet und kann deine Aussage nur bestätigen.

Hatte versucht via EventMap ein wenig um zu biegen. Allerdings ist es genau wie du sagst. Sobald on/off in setList steht ist das Verhalten so "komisch".
Sobald man anstelle von on/off einfach an/aus nimmt, kann man den online Kreis anklicken. Es sind wohl nur die Worte on/off (ggf. weitere?).

Ich selber kann keinen Patch schreiben oder kenne die Zusammenhänge im Hintergrund. Das ist wirklich etwas zu tief mit meinem aktuellem Kenntnisstand. Kann hier ggf. jemand diese Rolle übernehmen? Für mich ist das ein "bug". Aber auch nur weil man es so sicher nicht gewollt hat.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 14:21:17
Zitat von: 87insane am 02 Mai 2019, 14:07:10
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 ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 14:36:01
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?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 14:49:50
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...?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Mai 2019, 14:53:27
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?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 02 Mai 2019, 15:29:05
Thema "ShellyBulb" (nutzt den überhaupt jemand außer mir?)

Beta-User schrieb im anderen Thread
ZitatNur 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?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 15:49:55
Zitat von: gvzdus am 02 Mai 2019, 15:29:05
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:
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:
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):
userReadings rgb:red {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 03 Mai 2019, 07:27:01
Zitat von: Beta-User am 02 Mai 2019, 13:43:52
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:
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....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Mai 2019, 07:44:54
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.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 03 Mai 2019, 09:07:30
Zitatda 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:
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 :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 03 Mai 2019, 09:52:38
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:
<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.


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!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Mai 2019, 10:09:10
@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?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 03 Mai 2019, 10:50:07
@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.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 03 Mai 2019, 11:00:44
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:
<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.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Mai 2019, 11:02:38
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.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 03 Mai 2019, 11:11:41
ZitatABER 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.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 03 Mai 2019, 11:29:37
Okay - Also ist es eher ein Fehler das es überhaupt geht. Fand die Idee damals so gut von Beta-User. Naja gut..

Diese Variante in Perl hat nicht zufällig jemand fertig? Ich selber würde vermutlich 10 Jahre brauchen dafür.
Oder eine Idee posten mit der man bzw. ich testen kann. In Sachen Perl muss ich noch viel lernen....

Müsste man hier dann nicht sogar stateFormat in Perl umwandeln? Oder genügt devStateIcon?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Mai 2019, 11:46:10
devStateIcon mit Perl ist die richtige Adresse, nicht stateFormat! Das ganze ist weniger kompliziert, wie es dir im Moment erscheinen mag ;) . Einfach den html-Code zusammenbauen, das geht mit schlichten Textmanipulationen.

Du kannst dich z.B. hier bedienen: https://forum.fhem.de/index.php/topic,97430.0.html
Zur Erläuterung: "$ret .= ..." fügt jeweils hinten was an ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 03 Mai 2019, 19:33:03
Hi Beta-User und Freunde des ShellyBulbs (wohl ein übersichtlicher Kreis).

Ich habe "mein" Template "A_15_shellybulb" überarbeitet. Vor allem wollte ich es mit alexa-fhem optimieren. Jetzt läuft es sauber: Von "rot" über "gelb" rüber zum "Weißmodus" mit "warm weiß" und "hell weiß" und zurück.

Rumtricksen musste ich vor allem, damit die Helligkeit in beiden Modi einstellbar bleibt: "rgb" muss im Weißmodus Werte zurückliefern, die alexa-fhem wiederum über die Helligkeit zu spekulieren erlauben.

Ich hänge mal eben an
- DeviceList
- Template

Kommentare?

Viele Grüße, Georg

Internals:
   CFGFN     
   CID        shellybulb_3CC533
   DEF        shellybulb_3CC533
   DEVICETOPIC MQTT2_shellybulb_3CC533
   FUUID      5ccc76ea-f33f-8d06-0279-a2cddb67dbab22f3
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 50
   MQTT2_FHEM_Server_TIME 2019-05-03 19:29:47
   MSGCNT     50
   NAME       MQTT2_shellybulb_3CC533
   NR         219
   STATE      rgb
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-05-03 19:14:18   announce_fw_ver 20190402-134156/v1.4.9@9be72c7e
     2019-05-03 19:14:18   announce_id     shellybulb-3CC533
     2019-05-03 19:14:18   announce_ip     192.168.0.5
     2019-05-03 19:14:18   announce_mac    DE4F223CC533
     2019-05-03 19:14:18   announce_new_fw false
     2019-05-03 19:29:47   blue            0
     2019-05-03 19:29:47   brightness      45
     2019-05-03 19:18:18   color_0         on
     2019-05-03 19:29:47   ct              3000
     2019-05-03 19:29:47   effect          0
     2019-05-03 19:29:47   gain            100
     2019-05-03 19:29:47   green           115
     2019-05-03 19:29:47   ison            true
     2019-05-03 19:29:47   mode            white
     2019-05-03 19:14:18   online          true
     2019-05-03 19:29:47   red             115
     2019-05-03 19:29:47   rgb             727272
     2019-05-03 19:18:18   state           rgb
     2019-05-03 19:29:47   temp            3000
     2019-05-03 19:29:47   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   alexaName  Licht Kinderzimmer
   genericDeviceType light
   icon       light_control
   model      A_15_shellybulb
   readingList shellies/shellybulb-3CC533/color/0/status:.* {json2nameValue($EVENT)}
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* color_0
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shellybulb-3CC533/color/0/command off
  on:noArg shellies/shellybulb-3CC533/color/0/command on
  pct:colorpicker,BRI,0,1,100 shellies/shellybulb-3CC533/color/0/set {"turn":"on","gain":"$EVTPART1","brightness":"$EVTPART1"}
  ct:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3){"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
   userReadings ct {ReadingsVal($name,"temp",3000)}, rgb {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
   webCmd     on:off:pct:ct:rgb


# shellybulb using original firmware
name:A_15_shellybulb
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellybulb using original firmware <br>Tested with 1.49
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/color/0/command off\
  on:noArg shellies/DEVNAME/color/0/command on\
  pct:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","gain":"$EVTPART1","brightness":"$EVTPART1"}\
  ct:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3){"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
deletereading -q DEVICE status_.*
attr DEVICE readingList shellies/DEVNAME/color/0/status:.* {json2nameValue($EVENT)}
attr DEVICE userReadings ct {ReadingsVal($name,"temp",3000)}, rgb {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
attr DEVICE webCmd on:off:pct:ct:rgb
attr DEVICE genericDeviceType light
attr DEVICE icon light_control
attr DEVICE model A_15_shellybulb
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Mai 2019, 05:09:56
Moin Georg,

Danke für die Aktualisierung.

Um das nochmal aufzugreifen:
Zitat von: Beta-User am 02 Mai 2019, 15:49:55
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):
userReadings rgb:red {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
Kannst du mal testen, ob die Einschränkung der trigger so paßt:
attr DEVICE userReadings ct:temp {ReadingsVal($name,"temp",3000)}, rgb:(mode|red|brightness) {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 04 Mai 2019, 08:44:12
Nee, das klappt nicht. Hier nochmal ein Versuch (siehe Zeitstempel der userReadings):
Internals:
   CFGFN     
   CID        shellybulb_3CC533
   DEF        shellybulb_3CC533
   DEVICETOPIC MQTT2_shellybulb_3CC533
   FUUID      5ccc76ea-f33f-8d06-0279-a2cddb67dbab22f3
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 1685
   MQTT2_FHEM_Server_TIME 2019-05-04 08:42:56
   MSGCNT     1685
   NAME       MQTT2_shellybulb_3CC533
   NR         219
   STATE      ct
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-05-03 19:54:10   announce_fw_ver 20190402-134156/v1.4.9@9be72c7e
     2019-05-03 19:54:10   announce_id     shellybulb-3CC533
     2019-05-03 19:54:10   announce_ip     192.168.0.5
     2019-05-03 19:54:10   announce_mac    DE4F223CC533
     2019-05-03 19:54:10   announce_new_fw false
     2019-05-04 08:42:56   blue            0
     2019-05-04 08:42:56   brightness      0
     2019-05-04 08:42:28   color_0         on
     2019-05-04 08:41:26   ct              3000
     2019-05-04 08:42:56   effect          0
     2019-05-04 08:42:56   gain            100
     2019-05-04 08:42:56   green           0
     2019-05-04 08:42:56   ison            true
     2019-05-04 08:42:56   mode            white
     2019-05-03 19:54:10   online          true
     2019-05-04 08:42:56   red             28
     2019-05-04 08:41:26   rgb             001E00
     2019-05-04 08:42:28   state           ct
     2019-05-04 08:42:56   temp            6500
     2019-05-04 08:42:56   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   alexaName  Licht Kinderzimmer
   genericDeviceType light
   icon       light_control
   model      A_15_shellybulb
   readingList shellies/shellybulb-3CC533/color/0/status:.* {json2nameValue($EVENT)}
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* color_0
shellybulb_3CC533:shellies/shellybulb-3CC533/online:.* online
shellybulb_3CC533:shellies/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shellybulb-3CC533/color/0/command off
  on:noArg shellies/shellybulb-3CC533/color/0/command on
  pct:colorpicker,BRI,0,1,100 shellies/shellybulb-3CC533/color/0/set {"turn":"on","gain":"$EVTPART1","brightness":"$EVTPART1"}
  ct:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3){"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
   userReadings ct:temp {ReadingsVal($name,"temp",3000)}, rgb:(mode|red|green|blue|brightness) {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
   webCmd     on:off:pct:ct:rgb
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Mai 2019, 09:17:37
Ergänze beides bitte mit .*(Kurz, da mobil)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 04 Mai 2019, 09:23:04
ct:.* {ReadingsVal($name,"temp",3000)}, rgb:.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}

funktioniert, Updates kommen rein.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Mai 2019, 09:34:23
Mit temp bzw. blue natürlich....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 04 Mai 2019, 09:37:23
ct:temp.* {ReadingsVal($name,"temp",3000)}, rgb:(mode|brightness|red).* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}

aktualisiert auch.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Mai 2019, 09:45:49
 :) Sehr schön. Kannst du jetzt noch checken, ob du in der 2. reges alles brauchst? Oder ob wir kürzen können...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 04 Mai 2019, 09:55:26
Egal, was man ändert, der Shelly published immer den gesamten Parametervektor. Insofern reicht auch:
ct:temp.* {ReadingsVal($name,"temp",3000)}, rgb:temp.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
Aber mal angenommen, jeder hat wie ich eine Bitcoin-Schürfschleuder in Form des Raspberry Pi 3: Bringen diese Pattern so viel?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Mai 2019, 10:00:51
Es bringt bei besser konzipierten firmwares korrekte Zeitstempel und korrekte Darstellungen. So jedenfalls bei den MiLights mit der sidoh-firmware  :) .
Von daher werde ich die letzte Version, die 2. regex dann wohl nur mit blue, einchecken, oder?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 04 Mai 2019, 10:02:14
Gerne. Mich reizt ja auch, die set-Terme noch zu verkürzen - aber das geht dann zulasten der Leserlichkeit...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 Mai 2019, 13:25:18
Thema Shelly1PM:

Hallo nochmal - ich habe nun zwar gefudelt aber es ist einfacher so als ich dachte. Um der Sache mit der Interpretation von FHEM aus dem Weg zu gehen aber trotzdem on/offline Status und Webinterface zu bekommen, gleichzeitig mit Alexa Steuerung habe ich mal ein wenig angepasst.

Das Template muss nur wie folgt aussehen:
# shelly1pm using original firmware.
name:A_10b_shelly1pm
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* relay_0_energy\
  shellies/DEVNAME/longpush/0:.* longpush_0\
  shellies/announce:.* { json2nameValue($EVENT) }
attr DEVICE devStateIcon true:10px-kreis-gruen false:10px-kreis-rot on:on:relay0+off off:off:relay0+on
attr DEVICE genericDeviceType switch
attr DEVICE homebridgeMapping On=state,valueOff=relay0+off,valueOn=relay0+on,cmdOff=relay0+off,cmdOn=relay0+on
attr DEVICE stateFormat <a href="http://ip" target="_blank">\
online\
</a>\
relay0\
Aktuell: relay_0_power W / Temperatur: temperature °C
attr DEVICE webCmd :relay0
deletereading -q DEVICE [^(associatedWith)]*
attr DEVICE model A_10b_shelly1pm


Entscheidend ist hier das HomebridgeMapping. So wird Alexa mitgeteilt, dass on/off hier eben andere Befehle sind. Fhem interpretiert nun state nicht mehr wegen on/off anders und es geht.
Die on/off Readings in setList können also rauß. Hinzu habe ich mal attr DEVICE genericDeviceType switch hinzugefügt da dies zum Gerät passt. Einen Alexa Namen würde ich an dieser Stelle nicht im Template vergeben sondern manuell über den User machen lassen. Da jeder andere Namen nutzt um seine Geräte an zu sprechen.... Deckenlicht, Deckenlampe usw.....

@Beta-User: Was sagst du - Kannst du es einchecken?
PS: Anbei ein Bild wie es nun bei mir aussieht. Denke so kann man damit arbeiten :) (Den Rechtschreibfehler bei Temperatur habe ich im Template natürlich nicht drin gelassen)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Mai 2019, 13:42:08
Zitat von: 87insane am 04 Mai 2019, 13:25:18
@Beta-User: Was sagst du - Kannst du es einchecken?
Ich habe vorhin erst eine etwas andere Fassung eingecheckt ??? ::) . Sollte die IP im Klartext anzeigen, mit etwas Glück ist es sogar klickbar (ich glaube aber nicht daran).

Das "Problem" mit deinem Vorschlag ist, dass manche Attribute erst verfügbar sind, wenn das Umfeld paßt (genericType habe ich eben mal erfolglos bei mir gesucht...). Das kann ich so also nicht einchecken, weil es mit einiger Sicherheit Fehler wirft.

Neulich gab es an anderer Stelle eine Diskussion, ob es Sinn machen würde, sowas wie "sprachsteurungs-spezifische" Zusatztemplates zu generieren, die dann intern erst das Basistemplate verwenden, und dann die Zusätze so machen, dass homebridge usw. damit klarkommen. Das würde aber in diesem Rahmen zu weit führen, und ich kann/will das auch nicht intensiver begleiten. Bitte daher ggf. das mal suchen (3-6 Wochen zurück, Stichwort template).

Ansonsten: Perl lernen ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 Mai 2019, 13:45:24
Das muss nicht zwangsläufig mit rein. Jemand der Alexa nutzt weiß das aber auch ... Steht alles im Wiki. Wenn du dieses Attribut weg lässt geht es immer noch.

Wichtig ist nur das Homebridgemapping und die setList OHNE on/off. Also es erfüllt alles :)

Die Perl Sache wird so oder so in Angriff genommen. Ich heule deswegen schon viel zu oft. Immer alles ergooglen bei den einfachsten Sachen macht auch keinen Spaß.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 08 Mai 2019, 15:13:33
Zitat von: 87insane am 04 Mai 2019, 13:45:24
Ich heule deswegen schon viel zu oft. Immer alles ergooglen bei den einfachsten Sachen macht auch keinen Spaß.
Damit du die Suchmaschine deiner Wahl nicht kaputtmachen mußt... Versuch' mal das:attr sz_deckenlicht devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","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 / Temp: $temp</div>"}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 08 Mai 2019, 16:42:39
Hey - Danke!

Hab es mal schnell rein geworfen. stateFormat und webcmd gelöscht.
Er zeigt nur noch das normale Lampen Symbol an. Kein Verbrauch, kein online/offline icon und schalten kann man über das Symbol auch nicht. Die Syntax meckert er so nicht an wobei mich beim überfliegen wundert (aber dafür hast du sicher einen Grund), dass einmal ein Icon Name in ' ist und einmal in ". Aber das zu ändern brachte auch nichts.
In STATE steht nur noch off (soll vermutlich auch so sein, wenn man das so macht).

Anbei mal ein Bild wie es dann aussieht. Interessant ist ja schon mal das du die Lampe gewählt hast, welche ich auch immer genommen hatte, da es ein Deckenlicht ist. Aber selbst das wandelt er so leider nicht um. Leider kann ich aktuell auch nicht viel testen. Diese Woche ist zu bis oben hin :(
Wenn ich am WE eine Sekunde Zeit habe, versuche ich mal mit deinem Code ein wenig zu spielen. Immerhin meckert er die Syntax nicht an.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 08 Mai 2019, 16:57:16
Hmm, ich hatte deinen RAW-Code von neulich genommen, aber natürlich mit on/off in der setList. Sind die noch drin?

defmod sz_deckenlicht MQTT2_DEVICE shelly1pm_B1D951
attr sz_deckenlicht IODev MQTT2_FHEM_Server
attr sz_deckenlicht alias Schlafzimmer Deckenlicht
attr sz_deckenlicht autocreate 1
attr sz_deckenlicht devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","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 / Temp: $temp °C</div>"}
attr sz_deckenlicht event-on-change-reading .*
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 Alexa,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\
online shellies/shelly1pm-B1D951/relay/n/command $EVTPART1
attr sz_deckenlicht webCmd :

setstate sz_deckenlicht off
setstate sz_deckenlicht 2019-05-02 11:32:16 fw_ver 20190423-080637/v1.4.9-switch1pm-hotfix4@f8c51629
setstate sz_deckenlicht 2019-05-02 11:32:16 id shelly1pm-B1D951
setstate sz_deckenlicht 2019-05-02 11:34:49 input0 0
setstate sz_deckenlicht 2019-05-02 11:32:16 ip 192.168.20.53
setstate sz_deckenlicht 2019-05-02 11:32:16 mac 840D8EB1D951
setstate sz_deckenlicht 2019-05-02 11:32:16 new_fw false
setstate sz_deckenlicht 2019-05-02 11:53:53 online false
setstate sz_deckenlicht 2019-05-02 11:34:49 overtemperature 0
setstate sz_deckenlicht 2019-05-02 11:34:49 relay0 off
setstate sz_deckenlicht 2019-05-02 11:34:19 relay_0_energy 6
setstate sz_deckenlicht 2019-05-02 11:34:49 relay_0_power 0.00
setstate sz_deckenlicht 2019-05-08 15:15:58 state off
setstate sz_deckenlicht 2019-05-02 11:34:49 temperature 32.26

Das mit den Hochkommatas solltest du nochmal nachlesen... Das mit den einfachen war nur, um zu verhindern, dass _evtl._ wg. des "@" Perl-seitig gemeckert wird...

Das mit dem Symbol hätte ich für das template noch geändert, war nur zu Demo-Zwecken...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 08 Mai 2019, 17:09:15
setList hatte ich so gelassen und einfach auf mein relay0+on/off angepasst.
Das mit dem Lampen-Symbol ist zum testen ja sogar gut um zu wissen ob er es machen würde oder nicht.

Gemeckert wird da nur mit " anstelle von '. Also alles richtig von dir :) Er müsste aber ja zumindest irgendwas anzeigen. Anstelle dessen eben nur ein off/on und daraus resultierend die Lampe. Nur mal eben was rein kopieren und ein Ergebnis mitteilen kann ich natürlich immer mal nebenbei.

Wenn in devStateIcon ein Perl Code gepackt wird und dieser nur "halb" geht aber die Syntax nicht bemängelt wird, dann sollte ich mit der Aussage "Er müsste aber ja zumindest irgendwas anzeigen" richtig liegen. Wenn dem nicht so ist, bitte hier kurz eine Info. Damit ich diesen Test korrekt für dich/alle die davon profitieren durchführen kann, sind solche Infos natürlich wichtig.  Hatte bisher keinen Perl-Code in devStateIcon benötigt und weiß es deswegen nicht. Bitte nicht falsch verstehen....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 08 Mai 2019, 17:33:33
Die RAW-Def hatte ich - allerdings ohne Hardware... - getestet, das hat soweit was sinnvolles angezeigt. Also Vorschlag: mach erst mal die setList wieder komplett.

Alternative: du paßt das für die Relay-Anweisung an (wenn du weißt, wie ;) ).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 08 Mai 2019, 17:54:10
Mit einem "fast" fertigen Code kann ich eigentlich viel. Ich meine wenn er schon da steht muss man nur lesen, verstehen, testen.

Ich hoffe ich verstehe die fhem Abhängigkeit mit dem Perl in Devstateicon. Nicht das ich das was falsch machte.
Stateformat gelöscht, webcmd (einfach mal mit) gelöscht. Und wie ich den code verstehe, sollte er alles machen. Kann leider heute nicht mehr testen aber das schaffe ich ggf irgendwie morgen. Geht ja schneller als dieser Beitrag am handy hier.

Das ich das umgestellt hatte, schrieb ich aber oben. Also zu deiner alternative. Mache aber mal ne Copy und mache es in der einfach komplett neu. Dann ist der Test auch zu 100% und nicht halb meins und halb deins usw.

Melde mich....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 09 Mai 2019, 09:43:07
Moin moin....

So ist es perfekt. Du hattest nur ein \ zu viel drin. Habe es den anderen Schaltern vom Abstand her angepasst (On/Offline Icon zu Lampe zu Text.). Also nur kleine Dinge geändert.
Untereinander, muss ich leider gestehen ist doof. Hab es wieder nebeneinander gemacht. Finde ich um Längen besser.

# shelly1pm using original firmware.
name:A_10b_shelly1pm
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* relay_0_energy\
  shellies/DEVNAME/longpush/0:.* longpush_0
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"<div><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> Aktuell: $cons W / Temperatur: $temp °C</div>"}
attr DEVICE webCmd :
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model A_10b_shelly1pm


Das hier hast du gepostet (hinter dem folgendem Teil ist das \ zu viel ...ReadingsVal($name,"temperature","-100");;):
attr sz_deckenlicht devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","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 / Temp: $temp</div>"}

Danke an der Stelle, dass du den Code gepostet hast :)
Anbei ein Bild für die Nachwelt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 15 Mai 2019, 11:29:40
@All / Beta-User: Habe bei mir in allen Shellys folgendes in setList hinzugefügt:
update:noArg shellies/DEVNAME/command update_fw

So kann man beim Vorhandensein einer neuen FW über FHEM den Befehl an den Shelly senden.
Quelle: https://shelly-api-docs.shelly.cloud/#mqtt-configuration (https://shelly-api-docs.shelly.cloud/#mqtt-configuration)

Man könnte nun sogar wenn das Reading new_fw true anzeigt eine Art autoupdate=1 setzen. Das habe ich aus verschiedenen Gründen nicht gemacht - aber es ginge (in FHEM).

Was sagt ihr dazu? Würde das in zukünftige Templates mit aufnehmen.
Anbei ein Bild. Nicht wundern, da steht natürlich aktuell new_fw = false.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 15 Mai 2019, 11:58:02
Hallo,

klar muss das mit in ein Template.
Hatte das letzte Woche auch auf der Seite gelesen und wunderte mich über pahs Bemerkung unter den Gegenargumenten zu MQTT  im Wiki, dacht mir dann aber kam sicher irgendwann die letzte Zeit mit einem update.

Ich wäre für eine Option autoupdate.

Gruß

Thomas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 15 Mai 2019, 12:03:30
Habe im Shelly Forum mal in der Wunschliste, die Funktion in der Firmware der Sehllys gewünscht.
Also ein AutoUpdate an/aus. In FHEM würde ich das manuell machen, wie ich oben schrieb. Wer mag kann sich das ja ganz einfach als notify basteln. Ich gehe davon aus, dass es so oder so bald in der neuen FW sein wird. Dort werden auch ON/OFF URLs unterstützt in Zukunft. So kann man z.B. sagen ShellyABC an und dann bitte auch immer ShellyXYZ mit an.

Hier ging es mir hauptsächlich darum, dass einige vermutlich kein AutoUpdate wollen (wie ich). Ich teste neue FWs erst immer auf einem Gerät.
Ein Update Button an sich, für manuelle Updates würde ich gerne mit aufnehmen und das könnte Beta-User bei gefallen einchecken :)

EDIT: Das ist schon längere Zeit drin. Solche Kommentare ignoriere ich aber gern, da ich nicht als Besserwisser dar stehen will. Gerne wird sowas ja falsch verstanden. Der Code für setList steht ja schon mal oben und kann so übernommen werden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Mai 2019, 12:39:43
...ist ja gut, ihr bekommt den update-setter mit dem nächsten update der templates ::) ...

(einen Automatismus via template halte ich aber nicht für sinnvoll).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 15 Mai 2019, 12:42:34
Nicht direkt so störrisch :-P

Halte ich auch für überflüssig da dies in die FW gehört. Maximal noch ein an/aus setter....
Je nachdem wann du updatest, ich werde nachher den Shelly 2.5 verbauen und mit dem Template beginnen. Ich weiß nicht wie schnell ich sein werde aber ich würde versuchen ggf. schon was zu liefern am Abend.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Mai 2019, 13:19:33
Zitat von: 87insane am 15 Mai 2019, 12:42:34
Je nachdem wann du updatest, ich werde nachher den Shelly 2.5 verbauen und mit dem Template beginnen. Ich weiß nicht wie schnell ich sein werde aber ich würde versuchen ggf. schon was zu liefern am Abend.
Gerne; vermutlich kommt das von meiner Seite eher morgen früh. Ansonsten gibt es eben 2 updates...

(Und wenn es Diskussionsbedarf "geben sollte", wird's eh' später :P )
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Mai 2019, 07:46:31
Leider muss ich nachliefern. Hab es zu 95% fertig aber muss nun erstmal arbeiten ;)
Spiele noch mit der letzten Sache. Das Icon das bei laufendem Motor die Fahrtrichtung anzeigt ist in meinen Augen noch nicht so gut. Da ich aber keinen Müll (absichtlich) posten will, geht es nach der Arbeit weiter.

SORRY

@Beta-User: Wie soll das am Ende heißen? Oder korrigierst du dann selber? Hab aktuell nur einen blabla Namen.

EDIT:
Jetzt doch noch ganz schnell. Ist getestet aber nur sehr kurz.... Bei mir geht so alles. (0% = Rollo oben / 100% Rollo unten)
Was habe ich gemacht?
- Template an ROLLO Modul angepasst (Habe alle Rollos so).
- Man erkennt hoch / runter anhand des Icons
- PCT wird vom Rollo/Shelly auf den PCT Slider wiedergegeben und kann gesteuert werden
- Update Button für Shelly hinzugefügt
- Eigenen Button um selber noch andere Befehle ab zu setzen
- "Funktion" half hinzugefügt
- Grüner Punkt / Roter Punkt in STATE zeigt online/offline und ist klickbar. Man landet dann auf dem Webinterface vom Shelly


# shelly25 using original firmware in roller mode.
name:A_11z_shelly25_roller
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shelly25 using original firmware. <br>NOTE: shelly25 roller operated, change settings first!
par:DEVNAME;Shellyswitch25 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment shelly25 roller operated
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command open\
  close:noArg shellies/DEVNAME/roller/0/command close\
  half:noArg shellies/DEVNAME/roller/0/command/pos 50\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pct:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1\
  x_recalibration:noArg shellies/DEVNAME/roller/0/command rc\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/roller/0/pos:.* pct\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/shellyswitch25-007FC8/roller/0:.* current\
  shellies/shellyswitch25-007FC8/roller/0:open {{'state' => 'opening'}}\
  shellies/shellyswitch25-007FC8/roller/0:close {{'state' => 'closing'}}\
  shellies/shellyswitch25-007FC8/roller/0/pos:.* state\
  shellies/shellyswitch25-007FC8/input/1:.* input1\
  shellies/shellyswitch25-007FC8/input/0:.* input0\
  shellies/shellyswitch25-007FC8/relay/power:.* power\
  shellies/shellyswitch25-007FC8/relay/energy:.* energy\
  shellies/shellyswitch25-007FC8/temperature:.* temperature\
  shellies/shellyswitch25-007FC8/overtemperature:.* overtemperature
attr DEVICE devStateIcon opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 100:fts_shutter_100 0:fts_shutter_10 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 \b\d\b.*:fts_shutter_10 set_.*:fts_shutter_updown
attr DEVICE cmdIcon open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
attr DEVICE webCmd :open:close:half:stop:pct
attr DEVICE stateFormat <a href="http://ip" target="_blank">\
online\
</a>\
state
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE setStateList open close half stop pct
attr DEVICE model A_11z_shelly25_roller



Bitte Namen anpassen wenn du eincheckst.... Normal dürfte es hier nichts zu meckern geben... (Gucke nachher aber nochmal ob ich in der Eile nichts vergessen habe.)
Ist in diesem Fall eh zusammengewürfelt aus Tasmota Rollo Template / Shelly 2 Rollo Template und ein wenig eigenes + Anpassungen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Mai 2019, 15:25:31
Habe nun mal ein wenig getestet. Alles ok soweit.

Man könnte noch die Werte power und temperature nutzen. Diese liefert der Shelly 2.5 ja. Allerdings weiß ich nicht wofür bei einem Rollo. Dazu habe ich das Template so gebaut, wie auch bereits das Tasmota Template für Rollos. Ich lasse es bei mir so.


Wünsche und Anregungen erwünscht :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Mai 2019, 15:30:51
Moin,

das shelly25-er template ist im svn verfügbar, habe es als nahen Verwandten den 2-er Rollo-templates einfach mit einem Index dazu versehen, ansonsten (fast - da waren noch ein paar "undynamische" readingList-Einträge drin -) nicht verändert.

Bitte dann trotzdem nochmal die template-Version testen und ggf. Rückmeldung geben, ob man das einfach so auch für den "alten" 2-er nehmen könnte.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 16 Mai 2019, 16:05:46
Zitat von: 87insane am 16 Mai 2019, 07:46:31
(0% = Rollo oben / 100% Rollo unten)

Hallo

Ist das wirklich beim 2.5er anders als beim 2er Shelly?

Ist für den Betrieb mit ASC ja nicht unerheblich. Bisher hab ich nur einen Shelly 2 am Rolladen zum testen und wollte mir 2.5er nachbestellen.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Mai 2019, 16:17:16
@kabanett, das sollte sich so parametrieren lassen, dass es klappt: https://shelly-api-docs.shelly.cloud/#shelly-switch-settings-roller-index

Ich nehme mal an, dass hier der "swap" parameter gesetzt war?
@87insane (oder wer auch immer das dann liefert):
wenn möglich, bitte ggf. wieder (wie bei dem tasmota-roller) zwei templates liefern; das erste sollte OHNE Änderung der ausgelieferten Parameter sein, das andere (nur mit verdrehtem devStateIcon, denke ich?) dann mit gesetztem swap.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Mai 2019, 17:47:31
Hatte in dem Moment ne PN an Dich gesendet. Hatte immer getestet aber nicht vor Ort (Rollo nicht gesehen). Das hat mir jetzt im Nachhinein das Genick gebrochen. Entschuldige Beta-User für die fehlende Info bzw. diese Fehl-Erkenntnis. Und Sorry an kabanett, dass ich dich nun um sonst gefreut habe.

@kabanett: Ist wie beim shelly2 - leider genau umgekehrt zu dem wie ich es mag.
Die Invertierung gibt es auch nicht wie bei Tasmota. Wenn man im Shelly die Invertierung wählt, dann schaltet er nur anders rum. Also rauf/runter. Die PCT, die FHEM bekommt sind immer "falsch" rum oder wie die HM Freunde sagen, richtig rum ;)

Ich suche gerade nach einer Lösung den PCT Slider richtig rum zu bekommen....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Mai 2019, 17:54:42
Zitat von: 87insane am 16 Mai 2019, 17:47:31
Die Invertierung gibt es auch nicht wie bei Tasmota. Wenn man im Shelly die Invertierung wählt, dann schaltet er nur anders rum. Also rauf/runter. Die PCT, die FHEM bekommt sind immer "falsch" rum oder wie die HM Freunde sagen, richtig rum ;)
Wenn es dazu (auch in der Web-Oberfläche der shellys direkt) keine Option zum Einstellen gibt, sollte man das dem Herstellter melden (bitte aber vorher tripple-Checken!), dann ist es m.E. ein bug.

Ansonsten bitte ggf. um Einstellen einer Fassung, die funktional ist und bei der FHEM-Darstellung und Rollo übereinstimmen ;D . Ist ja noch nicht bei vielen im Einsatz, korrigieren wir eben baldmöglichst ;D ;D ;D ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 16 Mai 2019, 17:57:26
Ach... also eine Gewohnheitsfrage! ;) Dann ist doch bei richtigem Anschluß das WEB-IF des Shelly verkehrt. Oder?
Außerdem wird im ASC darauf hingewiesen den Shelly als ASC 2 zu konfigurieren.
Na mal schauen wann die ersten Nachfragen kommen ;D


Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Mai 2019, 18:12:48
Wie meinst du das mit dem Web-IF vom Shelly?

Ich nehme gleich nochmal das Ding aus der Wand. Nicht das ich der Fehler bin. Die Option im Webinterface vom Shelly existiert ja.
REVERSE CONTROLS
Check if you want to reverse the OPEN and CLOSE controls for the Shelly roller.


Bei mir dreht er nur die Tasten um. Also hoch=runter usw. Wenn ich nun aber vom Motor die Kabel am Shelly tausche sollte es ja gehen. Hmmm.. Ich bin gerade verwirrt !
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Mai 2019, 18:21:46
Zitat von: Beta-User am 16 Mai 2019, 16:17:16
@kabanett, das sollte sich so parametrieren lassen, dass es klappt: https://shelly-api-docs.shelly.cloud/#shelly-switch-settings-roller-index (https://shelly-api-docs.shelly.cloud/#shelly-switch-settings-roller-index)

Ich nehme mal an, dass hier der "swap" parameter gesetzt war?
@87insane (oder wer auch immer das dann liefert):
wenn möglich, bitte ggf. wieder (wie bei dem tasmota-roller) zwei templates liefern; das erste sollte OHNE Änderung der ausgelieferten Parameter sein, das andere (nur mit verdrehtem devStateIcon, denke ich?) dann mit gesetztem swap.
Bitte mit swap befassen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Mai 2019, 19:04:35
Jetzt mal ehrlich... ich sehe über json das es auf false steht aber wie mache ich das an? In den Shellys gibt es keine Konsole oder so.
Also dachte ich mir ich sende das via http oder mqtt.
shellies/DEVNAME/settings/roller/0/swap 1 - geht z.B. nicht. Hat irgendjemand eine Ahnung wie man dem Ding nun Testweise sagen kann, das es bitte swap auf true stellt? Erlaubt wäre 1,t,T,true. Gleiches gilt natürlich umgekehrt. Wenn man den Shelly via IP/settings/roller/0 aufruft, bekommt man eine JSON Ausgabe, die wie folgt aussieht:

{"maxtime":25.00,"default_state":"stop","swap":false,"input_mode":"openclose","button_type":"momentary","btn_reverse":0,"state":"stop","power":0.00,"is_valid":true,"safety_switch":false,"schedule":false,"schedule_rules":[],"obstacle_mode":"disabled","obstacle_action":"stop","obstacle_power":200,"obstacle_delay":1,"safety_mode":"while_opening","safety_action":"stop","safety_allowed_on_trigger":"none","off_power":2,"positioning":true}

Ich bitte hier echt um Hilfe! Wenn Swap wirklich klappen sollte, habe ich morgen beide Templates fertig (so zumindest mein Plan :))
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: DasQ am 16 Mai 2019, 19:40:12
Zitat von: 87insane am 16 Mai 2019, 19:04:35
shellies/DEVNAME/settings/roller/0/swap 1


Ich hoff du hast das nicht mit dem devname im topic versucht.
Wie heißt denn das device richtig? Und Schneid mal das topic ab

DEVNAME/settings/roller/0/swap 1
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Mai 2019, 19:48:20
Geht leider nicht...Wenn ich shellyswitch25-007FC8/settings/roller/0/swap 1 sende bleibt es auf false.
Senden mache ich in diesem Fall direkt über den MQTT Server via FHEM: set MQTT2_FHEM_Server publish und dann eben die Befehle die man braucht zum testen.

Hab nur DEVNAME eingesetzt da ich das besser finde wenn man sucht im Forum.

Normale auf und ab Kommandos funktionieren z.B.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Mai 2019, 19:53:45
Vermutlich braucht man einen json-blob, so wie die Daten auch rückwärts geliefert werden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: dkreutz am 16 Mai 2019, 19:55:49
Bei mir sind zwei ShellyPlug-S angekommen. Die sind ähnlich dem ShellyPlug (ohne "S"), unterscheiden sich in der Bauform (ähnlich Fibaro Plug), maximale Schaltleistung (2400W statt 3600W) und haben einen Temperatursensor (für "Notabschaltung" bei Überlastung). Hier die Readingslist:

shellies/shellyplug-s-DEVID/relay/0:.* state
shellies/shellyplug-s-DEVID/relay/0:.* relay0
shellies/shellyplug-s-DEVID/input/0:.* input0
shellies/shellyplug-s-DEVID/online:.* online
shellies/shellyplug-s-DEVID/announce:.* { json2nameValue($EVENT) }
shellyplug_s_DEVID:shellies/shellyplug-s-DEVID/relay/0/power:.* relay_0_power
shellyplug_s_DEVID:shellies/shellyplug-s-DEVID/temperature:.* temperature
shellyplug_s_DEVID:shellies/shellyplug-s-DEVID/overtemperature:.* overtemperature
shellyplug_s_DEVID:shellies/announce:.* { json2nameValue($EVENT) }
shellyplug_s_DEVID:shellies/shellyplug-s-DEVID/relay/0/energy:.* relay_0_energy
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Mai 2019, 20:00:07
Zitat von: Beta-User am 16 Mai 2019, 19:53:45
Vermutlich braucht man einen json-blob, so wie die Daten auch rückwärts geliefert werden.

Ideen nehme ich gerne an :)

@dkreuz: dann hast du ja was zu tun :-P ich erfreue mich jedes mal wenn man mal wieder vor ein Problem läuft 😂
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 16 Mai 2019, 20:39:32
Hallo

Zitat von: 87insane am 16 Mai 2019, 18:12:48
Wie meinst du das mit dem Web-IF vom Shelly?!
Sorry, ich meine das Webinterface ;)

Zitat von: Beta-User am 16 Mai 2019, 18:21:46
Bitte mit swap befassen...
ZitatWhether to swap Open and Close directions

Ich schnall gerade nicht worauf du hinaus willst?! Wenn ich meinen Shelly umstelle, habe ich im Webinterface zwar Close angefahren aber der Rollladen ist offen.
Ich denke die Option ist für z.B. Markisen sinnvoll?!

Noch dazu kommt es auf die Ansteuerung an. Einfacher Taster, zweifacher Taster, zweifacher Schalter, normal oder invers betrieben.....
Wie gesagt, ich habe nur ein Shelly2 und der funktioniert mit dem Template von euch perfekt. Danke dafür!!!
Mehr würde ich persönlich auch nicht brauchen. Nicht Böse gemeint ;)

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: DasQ am 16 Mai 2019, 20:49:35
shellies/DEVNAME/roller/0/command swap,1

oder ggf mit set?

quelle (https://shelly-api-docs.shelly.cloud/#rgbw2-overview)
Zitatshellies/shellyrgbw2-<deviceid>/color/0/set accepts a json payload described below:

{
    "turn": "on",    /* bool, can be set with on and off commands */
    "red": 0,        /* red brightness, 0..255, applies in mode="color" */
    "green": 0,      /* green brightness, 0..255, applies in mode="color" */
    "blue": 255,     /* blue brightness, 0..255, applies in mode="color" */
    "white": 0,      /* white brightness, 0..255, applies in mode="color" */
    "gain": 100,     /* gain for all channels, 0..100, applies in mode="color" */
    "effect": 0      /* applies an effect when set */
}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 09:08:25
Zitat von: kabanett am 16 Mai 2019, 20:39:32
Hallo
Sorry, ich meine das Webinterface ;)

Ich schnall gerade nicht worauf du hinaus willst?! Wenn ich meinen Shelly umstelle, habe ich im Webinterface zwar Close angefahren aber der Rollladen ist offen.
Ich denke die Option ist für z.B. Markisen sinnvoll?!

Noch dazu kommt es auf die Ansteuerung an. Einfacher Taster, zweifacher Taster, zweifacher Schalter, normal oder invers betrieben.....
Wie gesagt, ich habe nur ein Shelly2 und der funktioniert mit dem Template von euch perfekt. Danke dafür!!!
Mehr würde ich persönlich auch nicht brauchen. Nicht Böse gemeint ;)

Gruß

Bei dir sind die Icons nicht korrekt. (webcmd). Das es läuft ist schön und freut mich. An sich geht auch alles nur würde ich hier, wie schon von Beta-User beschrieben, zwei Templates haben. Einmal invert und einmal ohne. Das Web-IF ist an sich ja korrekt. Es dreht einfach die Richtungen um. Allerdings nicht die % der PCT. Da ich swap aber auch nicht aktiv bekomme kann ich das nicht testen. Der Shelly 2 ist identisch bis auf Temperatur usw. Deswegen würden auch beide Templates funktionieren (Shelly2 und Shelly25).

@Das@: Werde ich nachher testen (wenn ich zuhause bin). Die Beschreibung von Shelly sagt ja diverse Einstellungen an, die auch via MQTT laufen müssen. Die Struktur ist eigentlich einfach aber aus einem mir unbekanntem Grund, interessiert es den Shelly nicht. Ich bin aber auch kein Profi was das angeht. Bei Tasmota usw bekomme ich das hin und da ergibt es auch Sinn. Danke aber schon mal!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Mai 2019, 10:13:27
Zitat von: 87insane am 16 Mai 2019, 20:00:07
Ideen nehme ich gerne an :)
Versuch's mal so (nach Anpassung auf deine Daten, versteht sich):

set <io-device> publish shellies/<shellymodel>-<deviceid>/settings/roller/0 { "swap": true }


Zitat von: dkreutz am 16 Mai 2019, 19:55:49
Bei mir sind zwei ShellyPlug-S angekommen. Die sind ähnlich dem ShellyPlug (ohne "S"), unterscheiden sich in der Bauform (ähnlich Fibaro Plug), maximale Schaltleistung (2400W statt 3600W) und haben einen Temperatursensor (für "Notabschaltung" bei Überlastung). Hier die Readingslist:
Die readingList scheint (hab's nur kurz überflogen) identisch zu sein wie bei A_10b_shelly1pm. Vielleicht magst du das mal testen, dann können wir das gerne als Modelhinweis in die desc packen?

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: willibutz am 17 Mai 2019, 10:20:54
ich habe gestern einen ShellyPlug-S als A_10b_shelly1pm konfiguriert. Scheint gut zu funktionieren.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 10:41:18
ZitatDie readingList scheint (hab's nur kurz überflogen) identisch zu sein wie bei A_10b_shelly1pm. Vielleicht magst du das mal testen, dann können wir das gerne als Modelhinweis in die desc packen?
Macht ggf. Sinn eine Übersicht der Templates zu erschaffen und dann wofür sie sind. Ohne in die Template Datei rein zu sehen, weiß man das anhand des Namens sonst leider nicht. Außer du würdest für den PlugS und andere in dieses Schema passende Geräte einfach mit anlegen aber als set dann das Template. Denke das zweite ist sogar besser. Dann hat man in der Liste namentlich das richtige und hinten rum, stellt er das ein über ein anderes Template.

Zitatset <io-device> publish shellies/<shellymodel>-<deviceid>/settings/roller/0 { "swap": true }
Auch das werde ich nachher testen. Hab zudem auch alle anderen Quellen angeschrieben ob das nicht einfach in die FW mit einfließen kann als klickbare aber auch MQTT Option. Bisher waren die Kollegen (Shelly selber) immer sehr kooperativ.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Mai 2019, 11:06:55
Zitat von: 87insane am 17 Mai 2019, 10:41:18
Macht ggf. Sinn eine Übersicht der Template [...]
Schöner Hinweis, wird gerne übersehen:

Schon mal das "?" nach "set <device> attrTemplate" genutzt ;) ?



Die Beschreibung auf der shelly-Seite dazu ist sehr spärlich (imo), aber da man solche Konfigurationsaufgaben nur einmalig macht (und auch nur dann, wenn man wie du unbedingt die ROLLO-Darstellugnsvariante haben will :P ), ist das m.E. keine Sache, die unbedingt in der firmware verbessert werden muß. Eine Verbesserung der Doku (mit ein, zwei Beispielen) würde es auch tun...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 11:24:02
Ich weiß das es da ist. Aber meinst du nicht das die Lösung mit dem anlegen und verweiß auf ein anderes Template in der Datei selber ist nicht besser? Grund ist der, dass es ggf. durch Updates dazu kommen kann, das man früher oder später doch ein eigenes machen muss.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: DasQ am 17 Mai 2019, 11:27:11
@beta-user, ich werd wieder OT, aber es bezieht sich auf dein letztes posting.

ich find die stelle wo man das "attribut" für die templates setzt, eh unglücklich. wie auch des fragezeichen (das schnallt da kein neuling).
das setzten des TemplateAttribut, gehört in mein augen unten zum dropdown "attr" und nicht zu "set".
wärs da unten, könnte man wie bei den vielen andern attributen auch, den infotext drunter einblenden (haben nicht alle attribute, aber viele, zumindest beim ersten mal).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 11:30:14
Ich finde es da oben ganz gut. Hatte ich sofort gefunden. Nur eben "?" ist aus meiner Sicht auch naaaaaja. Deswegen die Idee..Deine Idee ist aber auch gut. Also zwei Wege die man in eine Überlegung einbeziehen könnte. :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Mai 2019, 11:37:23
Zitat von: DasQ am 17 Mai 2019, 11:27:11
@beta-user, ich werd wieder OT, aber es bezieht sich auf dein letztes posting.

ich find die stelle wo man das "attribut" für die templates setzt, eh unglücklich. wie auch des fragezeichen (das schnallt da kein neuling).
das setzten des TemplateAttribut, gehört in mein augen unten zum dropdown "attr" und nicht zu "set".
wärs da unten, könnte man wie bei den vielen andern attributen auch, den infotext drunter einblenden (haben nicht alle attribute, aber viele, zumindest beim ersten mal).
Na ja, darüber kann man möglicherweise streiten, aber funktional ist AttrTemplate an SetExtensions angedockt, will heißen: das ginge nur mit massiven Eingriffen in den Code...

Und: Hat man das _einmal_ gesehen, vergisst man das vermutlich nicht so gründlich, dass man es nicht bei Bedarf wiederfindet; da das feature auch für andere Module vorhanden ist, ist es ein "Einmal-Lerneffekt", durch den man halt "durch muß".

Wenn es konkrete Vorschläge gibt, wo man das in der Doku verbessern kann: da freut sich Rudi über patches zur cref (zu MQTT2_DEVICE), dto für mich und daas Wiki (insbes. bei den "Praxisbeispielen).



Mehrere templates machen die Sache nicht zwangsläufig übersichtlicher, ich würde lieber den Namen etwas generischer gestalten, dann lesen die Leute evtl. tfm (aka "?"). Vorschlag:
A_10b_shelly_w_energy_meassuring
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 11:46:40
ZitatA_10b_shelly_w_energy_meassuring

Da würde ich mich zB fragen ob das nun ein oder zwei Relays sind. Übersichtlich ist die Template Datei für frische User eh nicht. Weswegen ich jedes Gerät einzeln anlegen würde. Aus den o.g. Gründen. Klar man kann die Namen bis aufs unermessliche versuchen für alles zu missbrauchen aber ist das Zielführend? MQTT in Fhem ist ja gerade wegen den Templates so eine geile Kiste. Wenn das nun komplizierter würde (und das würde es aus meiner Sicht) dann hat es wenig Sinn. Der Frischling wird gucken ob sein Gerät da ist und wenn er es nicht finden wird es einen Post geben....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 17 Mai 2019, 11:52:35
Zitat von: 87insane am 17 Mai 2019, 09:08:25
Bei dir sind die Icons nicht korrekt. (webcmd).

Nee, das ist so korrekt! Deshalb frug ich ja auch ob es beim 2.5 anders wäre.
Original Einstellung im Shelly und am Device hab ich nichts geändert. Einfach das Template ausgewählt.
Im ASC- WIKI steht es auch so und es funktioniert auch so!
ZitatDie 2 steht für ein umgekehrtes Verhalten und den Befehlsteil pct, also offen für set <name> pct 100. Typischer Vertreter dieses Typs sind HomeMatic (CUL_HM-) Geräte oder die Shelly2-Aktoren.

Nur zur Info!! Ihr macht das schon!!!

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 11:56:10
Das es so geht ist gut! Ging nur um die fehlenden Icons. Normal sieht das ein wenig anders aus. Jap das mit der 2 im ASC habe ich gesehen. Genau so wollte ich das auch erst umdrehen aber (leider) hat Beta-User da Recht. Es macht Sinn es richtig zu machen und an den Hersteller zu schreiben damit er das mit in der FW einbringt. Das tat ich auch bereits auf diversen Wegen. Bin mal gespannt wann ich eine Antwort bekomme.

Danke für deine Infos!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Mai 2019, 12:04:46


Zitat von: kabanett am 17 Mai 2019, 11:52:35
Deshalb frug ich ja auch ob es beim 2.5 anders wäre.
Ohne jetzt im Detail da verglichen zu haben: Besteht jetzt hinsichtlich des (vorhandenen) 2.5-er Roller-Templates Handlungsbedarf oder nicht?





Zitat von: 87insane am 17 Mai 2019, 11:46:40
Da würde ich mich zB fragen ob das nun ein oder zwei Relays sind.
Also für ein Relay so:
A_10b_shelly1_w_energy_meassuring

ZitatÜbersichtlich ist die Template Datei für frische User eh nicht.
Das mag stimmen, aber für fortgeschrittene User ist es so noch erträglich. Der "frische User" soll sich an FHEMWEB orientieren, und da hat Rudi mit dem "?" und den Filteroptionen, mit denen man auch nur das angezeigt bekommt, was grade relevant ist, was tolles gebastelt. Da der html-Text dann auch noch durchsuchbar sein sollte, ist es m.E. hinreichend, wenn man nach "seinem Modell" suchen kann (wenn einem die Reihenfolge usw. nicht schon genug Fingerzeige gibt).

ZitatWeswegen ich jedes Gerät einzeln anlegen würde. Aus den o.g. Gründen. Klar man kann die Namen bis aufs unermessliche versuchen für alles zu missbrauchen aber ist das Zielführend? MQTT in Fhem ist ja gerade wegen den Templates so eine geile Kiste. Wenn das nun komplizierter würde (und das würde es aus meiner Sicht) dann hat es wenig Sinn. Der Frischling wird gucken ob sein Gerät da ist und wenn er es nicht finden wird es einen Post geben....
Du must es auch nicht dauerhaft pflegen ;) , und eine "beschreibende" Namensgebung finde ich durchaus zielführend (denk' mal an die ganzen Zigbee-Leuchtmittel!) - ist aber zugegebenermaßen Geschmackssache.

Und Frischlings-Posts finde ich nicht tragisch; hat sich bisher im Rahmen gehalten. Wer die attrTemplates an sich findet, findet häufig auch "sein" template - oder fragt dann. Bisher gab's dazu doch in der Regel eine nette Antwort, oder?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 12:23:41
ZitatOhne jetzt im Detail da verglichen zu haben: Besteht jetzt hinsichtlich des (vorhandenen) 2.5-er Roller-Templates Handlungsbedarf oder nicht?
Ich hätte es gerne mit invertierter PCT Anzeige. Ansonsten gibt es da nichts zu meckern. Es geht ja auch alles. Jetzt stellt sich die Frage wie schnell der Support da handelt oder ob swap nachher klappt. Wenn swap nicht klappt, würde ich übergangsweise gerne ein Template haben, welches die Anzeige so zu sagen umrechnet für die, die es gerne so haben wollen wie ich.
Da weiß ich aber nicht wie das genau geht. Da wäre Hilfe super...zumindest Hinweise.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 17 Mai 2019, 12:29:28
Zitat von: Beta-User am 17 Mai 2019, 12:04:46

Ohne jetzt im Detail da verglichen zu haben: Besteht jetzt hinsichtlich des (vorhandenen) 2.5-er Roller-Templates Handlungsbedarf oder nicht?




Da bin ich raus! Im Grunde wollte ich nur darauf hinweisen, mehr nicht. Jemand wie ich, der das Gerät original verkabelt und die Einstellung belässt, hat im Device (Template) den falschen Status.
87insane hat ja geschrieben
Zitat@kabanett: Ist wie beim shelly2 - leider genau umgekehrt zu dem wie ich es mag.
Die Invertierung gibt es auch nicht wie bei Tasmota. Wenn man im Shelly die Invertierung wählt, dann schaltet er nur anders rum. Also rauf/runter. Die PCT, die FHEM bekommt sind immer "falsch" rum oder wie die HM Freunde sagen, richtig rum ;)
Ich kann nicht sagen wer oder was hier RICHTIG oder FALSCH ist! Man müsste den anderen genannten Hersteller dann auch noch bitten es zu ändern ;)

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 12:39:33
Es gibt kein richtig oder falsch. Ist Ansichtssache... Bei fast allen Geräten kann man das aber einstellen.
Der Status ist so gesehen auch nicht falsch sondern wie bei Homematic z.B.

Da aber alle meine Rollos anders rum fahren bzw. die PCT senden, macht es ja auch Sinn das hier zu haben. Es ist das einzige Rollo bei dem ich einen 2.5er einbauen musste, da z.B. ein Sonoff T1 da nicht hin passt (kein Platz an der Stelle).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: DasQ am 17 Mai 2019, 12:48:37
dann statt ? (fragezeichen)
etwas in der art

!!!!!!!!!!!!!!!! --->README <---- !!!!!!!!!!!!!!!!11111einseinseinselfelf 
;) :o
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2019, 18:31:12
Hey zusammen.... Ich behaupte mal ich hab es. Bitte mal einer von denen die wirklich Ahnung haben, drüber schauen. Bin mir nicht sicher ob es ggf. Seiteneffekte geben könnte.
Es sind vom Prinzip her nur 3 Dinge anders als beim Original.
- setList pct Slider
- readingList beide pos´s

@Beta-User: Wie du das am Ende einbaust in die Datei ist mir egal. Ich persönlich würde es wie bereits beim Tasmota Rollo Template machen. Quasi über das eigentliche Template set nur die Dinge austauschen, die anders sind bzw. in dem Fall reading.- und setList + devStateIcons. Danke auch nochmal an Dich!

Template für invert_1 (100=zu / 0%=offen) - Ich hoffe die bauen das schön in die FW ein. Aber solange das nicht so ist...
# shelly25 using original firmware in roller mode.
name:A_11b1_shelly25_roller_invert_1
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shelly25 using original firmware. <br>NOTE: shelly25 roller operated, change settings first!
par:DEVNAME;Shellyswitch25 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment  Shelly 2.5 in Roller-Mode. 0=opened / 100=closed
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command open\
  close:noArg shellies/DEVNAME/roller/0/command close\
  half:noArg shellies/DEVNAME/roller/0/command/pos 50\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pct:slider,0,1,100 {"shellies/DEVNAME/roller/0/command/pos ".(100-$EVTPART1)}\
  x_recalibration:noArg shellies/DEVNAME/roller/0/command rc\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/roller/0/pos:.* {'pct' => 100-$EVENT}\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/roller/0:.* current\
  shellies/DEVNAME/roller/0:open {{'state' => 'opening'}}\
  shellies/DEVNAME/roller/0:close {{'state' => 'closing'}}\
  shellies/DEVNAME/roller/0/pos:.* {'state' => 100-$EVENT}\
  shellies/DEVNAME/input/1:.* input1\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/relay/power:.* power\
  shellies/DEVNAME/relay/energy:.* energy\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature
attr DEVICE devStateIcon opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 100:fts_shutter_100 0:fts_shutter_10 9\d:fts_shutter_90 8\d:fts_shutter_80 7\d:fts_shutter_70 6\d:fts_shutter_60 5\d:fts_shutter_50 4\d:fts_shutter_40 3\d:fts_shutter_30 2\d:fts_shutter_20 1\d:fts_shutter_10 0\d.*:fts_shutter_10 set_.*:fts_shutter_updown
attr DEVICE cmdIcon open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
attr DEVICE webCmd :open:close:half:stop:pct
attr DEVICE stateFormat <a href="http://ip" target="_blank">\
online\
</a>\
state
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE setStateList open close half stop pct
attr DEVICE model A_11b1_shelly25_roller



Das gleiche Teil dann nochmal umgekehrt. Hier ist die Anzeige HM like:
# shelly25 using original firmware in roller mode.
name:A_11b1_shelly25_roller_invert_0
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shelly25 using original firmware. <br>NOTE: shelly25 roller operated, change settings first!
par:DEVNAME;Shellyswitch25 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment Shelly 2.5 in Roller-Mode. 100=opened / 0=closed
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command open\
  close:noArg shellies/DEVNAME/roller/0/command close\
  half:noArg shellies/DEVNAME/roller/0/command/pos 50\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pct:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1\
  x_recalibration:noArg shellies/DEVNAME/roller/0/command rc\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/roller/0/pos:.* pct\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/roller/0:.* current\
  shellies/DEVNAME/roller/0:open {{'state' => 'opening'}}\
  shellies/DEVNAME/roller/0:close {{'state' => 'closing'}}\
  shellies/DEVNAME/roller/0/pos:.* state\
  shellies/DEVNAME/input/1:.* input1\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/relay/power:.* power\
  shellies/DEVNAME/relay/energy:.* energy\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature
  attr DEVICE devStateIcon opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0:fts_shutter_100 100:fts_shutter_10 9\d:fts_shutter_10 8\d:fts_shutter_20 7\d:fts_shutter_30 6\d:fts_shutter_40 5\d:fts_shutter_50 4\d:fts_shutter_60 3\d:fts_shutter_70 2\d:fts_shutter_80 1\d:fts_shutter_90 0\d:fts_shutter_100 set_.*:fts_shutter_updown
attr DEVICE cmdIcon open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
attr DEVICE webCmd :open:close:half:stop:pct
attr DEVICE stateFormat <a href="http://ip" target="_blank">\
online\
</a>\
state
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE setStateList open close half stop pct
attr DEVICE model A_11b1_shelly25_roller


Zu invert_1
Man sollte aber beachten - Es geht hier NUR UM DIE ANZEIGE DER PCT. Die Steuerung habe ich im invert_1 Template einfach "verarscht". Der Shelly hat weiterhin die Werte, die er brauch bzw. haben will.
FHEM sagt z.B. 20% und sendet an den Shelly 80%. Das ist aktuell nicht leichter möglich (für mich).

Danke für Eure zahlreichen Antworten und die Unterstützung!

PS: Für die, die auf Temperatur und Power Werte stehen könnte man stateFormat wie folgt anpassen:
<a href="http://ip" target="_blank">
online
</a>
state
<br>
Aktuell: power W / Temperatur: temperature °C


Ich selber brauche das nicht, da ich es bei einem Rollo unnötig finde. Für anders denkende -> Siehe Bild (<br> weg lassen wenn es daneben stehen soll).

FRAGE: Was ich mich frage ist, warum in devStateIcon, bei eindeutigen Werten, immer noch alle z.B. 3\d.* schreiben. Reicht doch 3\d als Regex. Also zumindest bei diesen Geräten. Das ist keine pauschal auf alle Geräte bezogene Aussage!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 18 Mai 2019, 13:33:15
Zitat von: DasQ am 17 Mai 2019, 12:48:37
dann statt ? (fragezeichen)
etwas in der art
Das "?" ist doch in der IT weit verbreitet, um für alles mögliche Hilfe zu bekommen... Sehe wirklich keine Veranlassung, da um Rudi's Zeit zu betteln :P .



Das "pm"-template habe ich umbenannt und eine desc eingefügt (=> "?"); würde sich für die roller auch gut machen, die ich ansonsten erst mal fast so übernommen habe...

@87insane:
M.E. ist das "inverted" noch nicht "fertig" - weniger wegen des templates, aber m.E. kann man so Rollläden nicht sinnvoll auf 50% kalibrieren (Achse wird dicker...). Es wäre besser, das mit dem swap nochmal zu checken (es gab keine Rückmeldung zu meinem publish-Vorschlag;.das könnte man - wenn es funktioniert - auch via template machen ;) (ähnlich wie die Kleinschriebung für on/off bei den tasmotas).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 Mai 2019, 14:09:29
Da die FW in meinen augen noch nicht fertig. Eine neue Version ist auch schon angekündigt. In der neuen FW sollte sich einiges ändern. Habe das erst mal so gemacht damit man es schön nutzen kann. Optionen zu aktivieren von denen keiner weiß, finde ich an der stelle mit der FW nicht gut. Hier würde ich ab der neuen FW direkt weiter machen. Alles was man vorher macht könnte Verschwendung sein.

Zum Thema Swap werde ich noch testen müssen. Hatte nur erstmal den Garten usw fertig zu machen. Meine fresse dieses Unkraut bringt mich noch zum ausrasten :-P

Man kann die Rollos zwar kalibrieren aber in der aktuellen FW ist es so das diese nur rauf und runter messen. Es gibt keine 50% sind in echt nur 30% oder so Option. Da es aber auch keine richtige Option für half gibt ist dort im Template eine 50 eingetragen. Kann jeder auf seine Bedürfnisse anpassen..

Ich selber bin zufrieden mit der schnellen Lösung und es war ein schönes Training. Auch wenn das nur 3 kleine Dinge waren habe ich wichtige Dinge gelernt.

Also...wünsche oder Verbesserungen nehme ich gern auf aber bearbeitet werden die ab FW 1.5. außer die Funktion wäre beeinträchtigt. Dann natürlich sofort. Swap teste ich aber noch.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 22 Mai 2019, 18:28:18
Sooooo FW 1.5 ist raus.
Brav wie sie sind wurde Swap mit eingebaut in der FW. Am WE teste ich es den wert über mqtt zu ändern.

An der stelle möchte ich erwähnen das gute Ideen mit Begründung sofort in die neuen FW mit einfließen. Selten habe ich das so erlebt. Super :)

Hinzu sind im 2.5er shelly 2 neue readings. Würde am we also eine neue Version des templates abgeben. Ist alles nix Welten bewegendes.
Anbei ein Screenshot und das was die changelog nennen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 22 Mai 2019, 19:58:41
ZitatEs gibt keine 50% sind in echt nur 30% oder so Option

Das wäre ein wenig viel verlangt - der Zusammenhang ist alles Andere als linear und sehr stark vom individuellen Rollladen abhängig.

LG

pah
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 22 Mai 2019, 21:25:35
Ja das ist "viel" aber in tasmota geht das. Sogar sehr gut. Man muss hoch/runter einstellen und danach das Rollo auf die gewünschte 50% Position fahren. Danach setzt man diesen Prozent Satz als 50% ... Das ist für mich schon sehr gut gelöst. So ist man komplett individuell und hat auch vernünftige Fahrten.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 22 Mai 2019, 21:32:16
 ;D
Einen nichtlinearen Zusammenhang mit einer Stützstelle einrichten ?
Ich lach mich scheckig...

LG

pah
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 22 Mai 2019, 21:35:41
Du bist ja sehr gut in Perl und programmieren an sich. Schau dir mal den Rollo fork an, in der anleitung für tasmota Rollo mit Sonoff T1 Schaltern. Du wirst im Code sicherlich entdecken warum es so gut geht. Es ist sicher nicht so gut wie als würde der Stromverbrauch ende und Anfang markieren usw. Dazu speziell auf das Rollo angepasst.... Aber es geht gut.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 23 Mai 2019, 06:42:18
ZitatDu bist ja sehr gut in Perl und programmieren an sich
Danke, allerdings bin ich eher "gut" in mathematisch-physikalischen Fragestellungen, und darum finde ich das nach wie vor lustig.

In meinen Rollladensteuerungen ist das übrigens wirklich mit Hilfe nichtlinearer Funktionen gelöst, die auch die unterschiedliche Dicke des Rollladenpaketes beim Abrollen mit einbeziehen.

LG

pah
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 23 Mai 2019, 07:16:13
Zitat von: Prof. Dr. Peter Henning am 23 Mai 2019, 06:42:18
In meinen Rollladensteuerungen ist das übrigens wirklich mit Hilfe nichtlinearer Funktionen gelöst, die auch die unterschiedliche Dicke des Rollladenpaketes beim Abrollen mit einbeziehen.
Was da in dem Code steckt, den von 87insane da im Einsatz hat, sieht für mich auch nicht nach einer linearen Funktion aus:

"shuttercoeff" in https://github.com/stefanbode/Sonoff-Tasmota/blob/master/sonoff/xdrv_97_shutter.ino

Kann mich aber auch täuschen ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 23 Mai 2019, 07:25:28
Egal wie es gemacht wurde. Es ist ja lauffähig. Ich selber brauche 50% nicht mal. Hab es eingestellt aber nutze es nicht. Fahre die rollos eh meist komplett oder so das nur spalten offen sind.

Sooo erst mal einen schönen Tag [emoji5]

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Mai 2019, 11:19:03
Soooooooooo

Also swap geht nicht über MQTT. Ich habe nun alle möglichen Versuche gemacht....

Egal wie bescheuert die waren...
shellies/shellyswitch25-007FC8/settings/roller/0 { "swap": true }
shellyswitch25-007FC8/settings/roller/0/swap 1
shellies/shellyswitch25-007FC8/roller/0/command swap,1
shellies/shellyswitch25-007FC8/settings/roller {swap: false}
shellyswitch25-007FC8/settings/roller swap 0
shellies/shellyswitch25-007FC8/roller/command swap,0
shellies/shellyswitch25-007FC8/settings swap 0
shellies/shellyswitch25-007FC8/settings/roller/0 swap 0
shellies/shellyswitch25-007FC8/settings/roller/0/swap false
shellies/shellyswitch25-007FC8/settings/roller/0 {"swap": false}
shellies/shellyswitch25-007FC8/settings/roller/0/command {"swap": false}
shellies/shellyswitch25-007FC8/settings/roller/0/command {swap,false}
shellies/shellyswitch25-007FC8/settings/roller/0/{swap,false}


Geht alles nicht. Man kann es aber über das WEB-IF einstellen. Leider habe ich keinen anderen Weg gefunden :-\ - Bastle mal das Template
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Mai 2019, 12:02:24
Okay !!! Sowas peinliches habe ich noch nicht gesehen.

INFO: In der neuen FW für die Shellys (Version 1.5), haben die Programmierer so einige Dinge übersehen.
- Funktion swap inputs wechselt einfach nur den Schalter. Das ist soweit okay. Aber bringt auch nur was bei falsch angeschlossenem Schalter.
- REVERSE CONTROLS
Check if you want to reverse the OPEN and CLOSE controls for the Shelly roller.
Das ist so ziemlich die schlechteste Version von umgekehrter PCT Anzeige, die ich je sah! Die PCT kommen mit dieser Option korrekt an (also für mich - 100%=geschlossen / 0%=offen). ABER - So wie es auch die Beschreibung sagt... Die Befehle und auch Ausgaben sind nun invertiert. open ist nun = close. Ich habe das betroffene Template angepasst, nur glücklich bin ich damit nicht. Es würde ohne die Funktion zu aktivieren auch mit dem alten Template weiter laufen. Ist also fragwürdig ob man das nun tauschen will:
name:A_11b1b_shelly25_roller_invert_1
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shelly25 using original firmware. <br>NOTE: shelly25 roller operated, change settings first!
par:DEVNAME;Shellyswitch25 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment  Shelly 2.5 in Roller-Mode. 0=opened / 100=closed
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command close\
  close:noArg shellies/DEVNAME/roller/0/command open\
  half:noArg shellies/DEVNAME/roller/0/command/pos 50\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pct:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1\
  x_recalibration:noArg shellies/DEVNAME/roller/0/command rc\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/roller/0/pos:.* pct\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/roller/0:.* current\
  shellies/DEVNAME/roller/0:open {{'state' => 'closing'}}\
  shellies/DEVNAME/roller/0:close {{'state' => 'opening'}}\
  shellies/DEVNAME/roller/0/pos:.* {'state' => 100-$EVENT}\
  shellies/DEVNAME/input/1:.* input1\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/relay/power:.* power\
  shellies/DEVNAME/relay/energy:.* energy\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature
attr DEVICE devStateIcon opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 100:fts_shutter_100 0:fts_shutter_10 9\d:fts_shutter_90 8\d:fts_shutter_80 7\d:fts_shutter_70 6\d:fts_shutter_60 5\d:fts_shutter_50 4\d:fts_shutter_40 3\d:fts_shutter_30 2\d:fts_shutter_20 1\d:fts_shutter_10 0\d.*:fts_shutter_10 set_.*:fts_shutter_updown
attr DEVICE cmdIcon open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
attr DEVICE webCmd :open:close:half:stop:pct
attr DEVICE stateFormat <a href="http://ip" target="_blank">\
online\
</a>\
state
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE setStateList open close half stop pct
attr DEVICE model A_11b1b_shelly25_roller_invert_1


Ich musste nur close gegen open und umgekehrt einsetzen. Dafür muss aber im WEB-IF die o.g. Funktion aktiviert werden. Mit dem alten Template musste man das nicht und konnte einfach so über die Anzeige entscheiden. Ich denke, für mich ist das hier Müll! (Entscheide du @Beta-User).

Es gibt nun neue Readings im Shelly 2.5 als Rollo:
shellyswitch25_007FC8:shellies/shellyswitch25-007FC8/roller/0/power:.* roller_0_power
shellyswitch25_007FC8:shellies/shellyswitch25-007FC8/roller/0/energy:.* roller_0_energy


Diese sind nun auch wieder mit "_". Genau wie auch schon shellyswitch25_007FC8:shellies/announce:.* { json2nameValue($EVENT) }, sind diese für das Template, in meinen Augen komplett egal. Sie laufen automatisch rein wenn man autocreate an hat, aber man brauch sie auch nicht in meinen Augen. Zumindest nicht in diesem Template.

Also ist dieser Beitrag hier eigentlich nur ne Info. Habe aber auch schon ne Mail geschrieben an die Kollegen. In der Mail stehen noch einige Dinge mehr drin. Bin mal gespannt wie schnell die diesmal sind^^

@Beta-User: Kannst du bei allen shellys bitte noch x_mqttcom einbringen? Das wäre super und man kann immer direkt Befehle aus dem Device absetzen. Danke!
PS: Im Shelly 1 und Shelly 1PM habe ich keine Veränderungen erkennen können. Es gibt nichts neues was FHEM interessieren könnte.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Mai 2019, 12:38:36
Zitat@Beta-User: Kannst du bei allen shellys bitte noch x_mqttcom einbringen?
Mit dem nächsten update sollten dann bei allen Shelly-templates für sämtliche Admin-Befehle die "x_"-Präfixe verwendet werden (auch update und doRecalibration). Kommt irgenwann am WE ins svn, hoffe ich doch.

@all: Bitte ggf. nach einem update beachten, aber ich gehe mal davon aus, dass diese Befehle sowieso in der Regel "händisch" genutzt werden.

Zitat von: 87insane am 24 Mai 2019, 12:02:24- REVERSE CONTROLS
Check if you want to reverse the OPEN and CLOSE controls for the Shelly roller.
Kannst du die ggf. nochmal anpingen? Ich würde mal annehmen, dass das beim Anpassen der firmware schlicht übersehen wurde. Da das aber ggf. sehr verwirrend wird, wenn wir das hier via Template (voräufig?) drehen, würde ich das gerne erst dann anpassen, wenn die Firmware einen endgültigen Stand hat.

Die Power- und Energy-Readings lasse ich erst mal raus, die werden ja sowieso bei aktiviertem autocreate automatisch erstellt...

Grüße, Beta-User
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Mai 2019, 13:01:18
Zitat von: Beta-User am 24 Mai 2019, 12:38:36
Kannst du die ggf. nochmal anpingen? Ich würde mal annehmen, dass das beim Anpassen der firmware schlicht übersehen wurde. Da das aber ggf. sehr verwirrend wird, wenn wir das hier via Template (voräufig?) drehen, würde ich das gerne erst dann anpassen, wenn die Firmware einen endgültigen Stand hat.

Hab denen schon eine Mail gesendet. Sagte ja, das es mit Abstand die billigste Umsetzung der PCT-Invertierung war, die ich je sah.
Es ist in meinen Augen so beabsichtigt von denen aber ich finde es auch eher schlecht als recht...

Die FW wird wohl in den nächsten 6-9 Monaten keinen richtigen Stand haben. Da die ja noch in relativ kleinen Kinderschuhen steckt, wird weiter und weiter entwickelt. Ich werde aber ein Auge darauf haben und berichten. Du siehst es also genauso? Also das alte Temp lassen und erst ändern wenn es korrekt implementiert wurde...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Mai 2019, 13:17:37
Na ja, in dem Fall, mag ich keine wirkliche Bewertung abgeben; ich kenne eben zwei hier geläufige Konventionen, die eine ist die HomeMatic-Variante, also offen=100% und geschlossen =0%, die andere die ROLLO-Lesart (das, was du invertiert nennst, also zu=100% und offen = 0%).
Das heißt aber nicht, dass es nicht eine weitere Variante geben könnte, ich habe allerdings noch nicht intensiv darüber nachgedacht, und m.E. sollten für unsere Zwecke (=FHEM-intern gedacht) diese zwei Sichtweisen genügen, daher werde ich das auch vorläufig lassen.
Jedenfalls solange die Shellys keine Kalibrierung (aka nicht-lineare Fahrbefehle) kennen, ist es m.E. erst mal nicht so wichtig, und evtl. haben die da auch nicht gleich verstanden, wie es gemeint war. Ist ja alles auch nicht ganz so einfach, und man hat auch nicht immer gleich viel Geduld (oder um die Ohren).

Grundsätzlich machen die Jungs da m.E. einen ganz ordentlichen Job, ist ja auch alles nicht ganz so einfach und entwickelt sich sehr schnell, da kann man schon mal einen Nebenaspekt erst mal vernachlässigen (die Invertierung in ROLLO ist aus meiner Sicht schon ein Sonderfall, zumindest HM und ZWave (Fibaro) scheinen da ein anderes Verständnis zu haben). Vielleicht solltest du darüber nachdenken, einfach insgesamt zukünftig die HM-Lesart anzuwenden? Solange es einheitlich ist, ist der WAF schnell wieder herzustellen :) . Tip noch: nimm noch einen brightness-slider für die Bedienung her, dann ist es auch für DAG's verständlich: heller = offener :) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Mai 2019, 13:22:42
Ne neee... Soll schon so sein wie ich das mag. Es wird eben nur noch ein wenig dauern bis die das so haben, wie das sein sollte. Deswegen sagte ich ja, am besten einfach lassen wie es war. Hatte nur um es auch zu erklären mal angehangen was ich meine. So ist es etwas verständlicher...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: dkreutz am 29 Mai 2019, 19:46:14
Ich habe an einem Template für den Shelly RGBW2 im "color mode" gebastelt. Basiert auf dem Template für ShellyBulb mit Modifikation (RGBW2 hat keine regelbare  Farbtemperatur, dafür "Effects", etc.):

# shellyrgbw2 color mode
name:A_17a_shelly2rgbw_color
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellyrgbw2 color mode <br>Tested with 1.5.0-rgbw2-hotfix1
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/color/0/command off\
  on:noArg shellies/DEVNAME/color/0/command on\
  white:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","white":"$EVTPART1"}\
  gain:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","gain":"$EVTPART1"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/DEVNAME/color/0/set{\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  effect:select,0,1,2,3 shellies/DEVNAME/color/0/set {"effect":"$EVTPART1"}\
  update:noArg shellies/DEVNAME/command update_fw
deletereading -q DEVICE status_.*
attr DEVICE readingList shellies/DEVNAME/color/0/status:.* {json2nameValue($EVENT)}
attr DEVICE userReadings rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
attr DEVICE webCmd on:off:white:gain:rgb:effect
attr DEVICE genericDeviceType light
attr DEVICE icon light_control
attr DEVICE model A_17a_shelly2rgbw_color


Vielleicht mag jemand mit einem RGB2 und Farb-LED-Strip das mal testen?
Todos: "online" Anzeige wie bei dem Shelly1PM-Template, Leistungsanzeige
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 29 Mai 2019, 19:51:59
Schaue ich mir gerne morgen an. Hab selber nicht das Teil aber den online stati kenne ich ja schon. Hab mich so viel damit geärgert. Gerne mache ich damit weiter :) schön das du dabei bist :)

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 30 Mai 2019, 08:22:36
Moin zusammen,

hab's eben als "A_17" ins svn geschoben, ohne genericType, aber mit dem Versuch eines devStateIcons.(Nur on/off; das muß aber nicht passen, Rückmeldung wäre nett...)
Wer es noch netter haben will, könnte den erweiterten 255-er-code verwenden (kann on-for-timer usw. abbilden); wer nicht umrechnen will, könnte in Color.pm schauen, da gibt es auch Dimmer-devStateIcon-Code.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 Mai 2019, 09:32:51
Da war er schneller.... Danke !

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 30 Mai 2019, 11:02:55
ZitatDie FW wird wohl in den nächsten 6-9 Monaten keinen richtigen Stand haben. Da die ja noch in relativ kleinen Kinderschuhen steckt,

Wieso das denn ? Dieses Gemaule kann ich nicht nachvollziehen, die Leute bei Allterco sind allen sinnvollen Vorschlägen gegenüber sehr aufgeschlossen und reagieren sogar innerhalb von Stunden, wenn ich einen Fehler entdeckt habe.

pah
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 Mai 2019, 11:11:29
Dem wieder sprach ich mit der Aussage auch nicht. Im Gegenteil. Trotz allem bauen die aktuell noch sehr viel ein und um. Deswegen und auch nur deswegen die kinderschuhe.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 30 Mai 2019, 13:12:16
"kleine" Kinderschuhe war der Ausdruck - und das ist eine vollkommen unnötige Abwertung. Ebenso wie "billigste".

Beide Bemerkungen sind innovationsfeindlich.

pah
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: DasQ am 30 Mai 2019, 13:51:02
hat er sicherlich nicht so gemeint.

ansonsten bitte ich um eine harte, aber gerechte strafe ;-P
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 30 Mai 2019, 14:19:27
Ist es zu viel verlangt, wenn wir bei Gelegenheit wieder diese OT-Diskussion beenden könnten?

Es macht imo irgendwie nicht den großen Sinn, aus Anlaß einer unterschiedlichen Bewertung dessen, was eine firmware in einem speziellen Einsatzmodus unter Invertierung der vom Autor gedachten Vorgaben an Infos liefert und sich damit (möglicherweise!) nicht gleich so verhält, wie einzelne sich das vorstellen, seitenweise über als unpassend empfundene Begrifflichkeiten zu diskutieren.

Wen es interessiert hat, wird sich dazu vermutlich jetzt eine Meinung gebildet haben, wie das einzuordnen ist...

Viel eher würde mich interessieren, ob a) das devStateIcon für die rgbw-Variante funktioniert und b) ob es bessere Vorschläge gibt, die das ganze gleich in Farbe und gedimmt machen :P .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 Mai 2019, 14:38:23
Ich habe leider noch keinen von denen. Hätte auch nur ohne Test helfen können. Wollte mir aber noch einen bestellen.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: dkreutz am 02 Juni 2019, 19:32:04
Zitat von: Beta-User am 30 Mai 2019, 14:19:27
... würde mich interessieren, ob a) das devStateIcon für die rgbw-Variante funktioniert und b) ob es bessere Vorschläge gibt, die das ganze gleich in Farbe und gedimmt machen :P .

Das devStateIcon hat bei mir ein rotes Ausrufezeichen und funktioniert nur wenn über die FHEM-Weboberfläche geschaltet wird. Schalten über die Shelly-Weboberfläche ändert den "state" nicht (nur Readings "color_0" und "is_on").
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Juni 2019, 19:50:45
Zitat von: dkreutz am 02 Juni 2019, 19:32:04
Das devStateIcon hat bei mir ein rotes Ausrufezeichen und funktioniert nur wenn über die FHEM-Weboberfläche geschaltet wird. Schalten über die Shelly-Weboberfläche ändert den "state" nicht (nur Readings "color_0" und "is_on").
Hmm, kannst du mal ein list einstellen? Insbesondere würde mich interessieren, was es mit "is_on" auf sich hat; das hatten wir bisher noch nicht...
Den devStateIcon-Code muß ich mir dann mal ansehen. Allerdings klingt das so, als würde der Befehl nicht ankommen würde (bzw. die Rückmeldung nicht zum Erwarteten paßt und daher auf "set on" bleibt). Vielleicht kannst du mal "mithören", was da an Messages hin- und hergeht?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Juni 2019, 20:03:37
Mithören: mqtt auf log Level 5 und mal schauen. Hatte damit selber auch zu kämpfen. Die mqtt messages vom sehlly kommen teilweise mit - aber auch mit _ rein. Viel Erfolg! Macht das Template bitte schön. Mein rgw kommt noch :) danke an euch!

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Juni 2019, 20:04:40
Mithören: mqtt auf log Level 5 und mal schauen. Hatte damit selber auch zu kämpfen. Die mqtt messages vom sehlly kommen teilweise mit - aber auch mit _ rein. Viel Erfolg! Macht das Template bitte schön. Mein rgw kommt noch :) danke an euch!

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: dkreutz am 02 Juni 2019, 23:29:22
Zitat von: Beta-User am 02 Juni 2019, 19:50:45
Hmm, kannst du mal ein list einstellen? Insbesondere würde mich interessieren, was es mit "is_on" auf sich hat; das hatten wir bisher noch nicht...
Den devStateIcon-Code muß ich mir dann mal ansehen. Allerdings klingt das so, als würde der Befehl nicht ankommen würde (bzw. die Rückmeldung nicht zum Erwarteten paßt und daher auf "set on" bleibt). Vielleicht kannst du mal "mithören", was da an Messages hin- und hergeht?

Hier schon mal das List - "mithören" folgt später...


Internals:
   CID        shellyrgbw2_ABCDEF
   DEF        shellyrgbw2_ABCDEF
   DEVICETOPIC LED
   FUUID      5ce4933a-f33f-617b-870f-781a5111cc2c66e0
   FVERSION   10_MQTT2_DEVICE.pm:0.194810/2019-05-29
   IODev      m2s
   LASTInputDev m2s
   MSGCNT     16
   NAME       LED
   NR         437
   STATE      set_off
   TYPE       MQTT2_DEVICE
   m2s_MSGCNT 16
   m2s_TIME   2019-06-03 19:56:06
   READINGS:
     2019-06-03 19:56:06   blue            246
     2019-06-03 19:55:57   color_0         off
     2019-06-03 19:56:06   effect          2
     2019-06-03 19:54:06   fw_ver          20190531-080138/v1.5.0-hotfix2@022ec015
     2019-06-03 19:56:06   gain            8
     2019-06-03 19:56:06   green           255
     2019-06-03 19:54:06   id              shellyrgbw2-ABCDEF
     2019-06-03 19:54:06   ip              192.168.100.119
     2019-06-03 19:56:06   ison            false
     2019-06-03 19:54:06   mac             3C71BFABCDEF
     2019-06-03 19:56:06   mode            color
     2019-06-03 19:54:06   new_fw          false
     2019-06-03 19:54:06   online          true
     2019-06-03 19:56:06   overpower       false
     2019-06-03 19:56:06   power           0.00
     2019-06-03 19:56:06   red             255
     2019-06-03 19:54:06   rgb             FFFFF6
     2019-06-03 19:55:57   state           set_off
     2019-06-03 19:56:06   white           0
Attributes:
   IODev      m2s
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; "<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>"}
   event-min-interval .*:900
   event-on-change-reading .*
   genericDeviceType light
   icon       light_control
   model      A_17_shelly2rgbw_color
   readingList shellies/shellyrgbw2-ABCDEF/color/0/status:.* {json2nameValue($EVENT)}
shellyrgbw2_ABCDEF:shellies/shellyrgbw2-ABCDEF/color/0:.* color_0
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shellyrgbw2-ABCDEF/color/0/command off
  on:noArg shellies/shellyrgbw2-ABCDEF/color/0/command on
  white:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-ABCDEF/color/0/set {"turn":"on","white":"$EVTPART1"}
  gain:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-ABCDEF/color/0/set {"turn":"on","gain":"$EVTPART1"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-ABCDEF/color/0/set{\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  effect:select,0,1,2,3 shellies/shellyrgbw2-ABCDEF/color/0/set {"effect":"$EVTPART1"}
  update:noArg shellies/shellyrgbw2-ABCDEF/command update_fw
   setStateList on off
   userReadings rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
   webCmd     on:off:white:gain:rgb:effect
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: DasQ am 03 Juni 2019, 06:26:47
Da ist aber kein ,,is_on" dabei  ;)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: dkreutz am 03 Juni 2019, 07:06:54
Ups, Tippfehler: ,,ison" war gemeint....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Juni 2019, 07:16:56
Bitte trotzdem erst mal das update auf die aktuellste Version durchführen ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: dkreutz am 03 Juni 2019, 20:06:24
FHEM aktualisiert, AttrTemplate erneut auf Device angewendet, ShellyRGBW2 Firmware aktualisiert.
List ist im Beitrag oben (https://forum.fhem.de/index.php/topic,94060.msg945543.html#msg945543) aktualisiert

Schalten im FHEMWeb wird nun auch in der Shelly-Weboberfläche aktualisiert und umgekehrt (Änderung in Shelly-Web in FHEMWeb sichtbar). DevStateIcon hat immer noch ein rotes Ausrufezeichen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Juni 2019, 07:38:26
Hmm, also:

color_0 scheint die Antwort auf "on/off" zu sein. Demnach müßte statt
shellyrgbw2_ABCDEF:shellies/shellyrgbw2-ABCDEF/color/0:.* color_0
folgendes passen:
shellyrgbw2_ABCDEF:shellies/shellyrgbw2-ABCDEF/color/0:.* state

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: dkreutz am 10 Juni 2019, 23:11:57
Passt! Bei mir laufen jetzt drei ShellyRGBW2 mit dem Template (Stand 8.6.).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Juni 2019, 09:21:22
Zitat von: dkreutz am 10 Juni 2019, 23:11:57
Passt! Bei mir laufen jetzt drei ShellyRGBW2 mit dem Template (Stand 8.6.).
Danke für die Rückmeldung!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Mr. P am 12 Juni 2019, 22:00:04
Hej folks,

nachdem das aktuelle Template bei mir zwei Unterschiedliche Effekte brachte, hab ich es mir mal näher angesehen und zwei Fehler gefunden.
@Beta-User - wäre fein, wenn du das mqtt2.template mit folgendem Patch versehen könntest:

--- mqtt2.template_origin 2019-06-12 21:44:05.730601818 +0200
+++ mqtt2.template 2019-06-12 21:46:56.098829022 +0200
@@ -1085,7 +1085,7 @@
   on:noArg shellies/DEVNAME/color/0/command on\
   white:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","white":"$EVTPART1"}\
   gain:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","gain":"$EVTPART1"}\
-  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/DEVNAME/color/0/set{\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
+  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
   effect:select,0,1,2,3 shellies/DEVNAME/color/0/set {"effect":"$EVTPART1"}\
   update:noArg shellies/DEVNAME/command update_fw
deletereading -q DEVICE status_.*


Thx a lot! :-)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 13 Juni 2019, 09:50:00
Zitat von: Mr. P am 12 Juni 2019, 22:00:04
@Beta-User - wäre fein, wenn du das mqtt2.template mit folgendem Patch versehen könntest:
Thx, ist seit eben im svn.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Mr. P am 17 Juni 2019, 22:35:57
So gefällt mir das. :-)
Einen hab ich noch für dich:
--- mqtt2.template_origin 2019-06-17 22:19:57.610684304 +0200
+++ mqtt2.template 2019-06-17 22:24:08.630973185 +0200
@@ -1083,9 +1083,9 @@
attr DEVICE setList\
   off:noArg shellies/DEVNAME/color/0/command off\
   on:noArg shellies/DEVNAME/color/0/command on\
-  white:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","white":"$EVTPART1"}\
-  gain:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","gain":"$EVTPART1"}\
-  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
+  white:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"white":"$EVTPART1"}\
+  gain:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"gain":"$EVTPART1"}\
+  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/DEVNAME/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
   effect:select,0,1,2,3 shellies/DEVNAME/color/0/set {"effect":"$EVTPART1"}\
   update:noArg shellies/DEVNAME/command update_fw
deletereading -q DEVICE status_.*
@@ -1110,7 +1110,7 @@
   shellies/DEVNAME/online:.* online
attr DEVICE setList off:noArg shellies/DEVNAME/white/0/command off\
   on:noArg shellies/DEVNAME/white/0/command on\
-  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/0/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}\
+  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/0/set {"mode":"white","brightness":"$EVTPART1"}\
   x_update:noArg shellies/DEVNAME/command update_fw\
   x_mqttcom shellies/DEVNAME/command $EVTPART1
deletereading -q DEVICE (?!associatedWith).*
@@ -1129,7 +1129,7 @@
   shellies/DEVNAME/online:.* online
attr DEVICE_CH2 setList off:noArg shellies/DEVNAME/white/1/command off\
   on:noArg shellies/DEVNAME/white/1/command on\
-  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/1/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
+  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/1/set {"mode":"white","brightness":"$EVTPART1"}
attr DEVICE_CH2 setStateList on off
copy DEVICE DEVICE_CH3
setreading DEVICE_CH3 associatedWith DEVICE,DEVICE_CH2,DEVICE_CH4
@@ -1139,7 +1139,7 @@
   shellies/DEVNAME/online:.* online
attr DEVICE_CH3 setList off:noArg shellies/DEVNAME/white/2/command off\
   on:noArg shellies/DEVNAME/white/2/command on\
-  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/2/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
+  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/2/set {"mode":"white","brightness":"$EVTPART1"}
attr DEVICE_CH3 setStateList on off
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVNAME/white/3/status:.* {json2nameValue($EVENT)}\
@@ -1148,7 +1148,7 @@
shellies/DEVNAME/online:.* online
attr DEVICE_CH4 setList off:noArg shellies/DEVNAME/white/3/command off\
   on:noArg shellies/DEVNAME/white/3/command on\
-  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/3/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
+  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/3/set {"mode":"white","brightness":"$EVTPART1"}
setreading DEVICE_CH4 associatedWith DEVICE,DEVICE_CH2,DEVICE_CH3
attr DEVICE_CH4 setStateList on off


Damit wird beim Ändern der Helligkeit oder Einstellen der Farbe nicht auch automatisch das Licht (bei RGB sogar mit voller Stärke) eingeschalten. Nachträglich hab ich die Änderungen auch noch mit dem Verhalten aus der Shelly-App geprüft: Das Verhalten deckt sich damit auch mit dem Original. ;-)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 18 Juni 2019, 19:18:27
Thx, hab's mal (mit den alten Einschaltoptionen als .*_on) eingecheckt.
Dass das Einschalten so stattfindet, war mal ein ausdrücklicher Vorschlag hier gewesen; bin immer etwas unschlüssig, wie mit sowas zu verfahren ist (finde aber die Kompabilität mit anderen Einbindungen wichtiger).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 22 Juni 2019, 10:44:29
Hey und guten Morgen...

Danke an den/die ersteller des shelly rgbw 2 Templates. Mal eine einfache frage dazu...
Wie sagt ihr Alexa, das sie die Stripes, Lampen weiß schalten soll? Wenn ich sage, sie soll alles blau, grün... Machen geht das. Wenn ich sage weiß, schaltet sie auf rot.
Verbaut sind led Stripes die sowohl Farbe als auch weiß können.

Danke :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Mr. P am 23 Juni 2019, 23:08:30
Zitat von: Beta-User am 18 Juni 2019, 19:18:27
Thx, hab's mal (mit den alten Einschaltoptionen als .*_on) eingecheckt.
Dass das Einschalten so stattfindet, war mal ein ausdrücklicher Vorschlag hier gewesen; bin immer etwas unschlüssig, wie mit sowas zu verfahren ist (finde aber die Kompabilität mit anderen Einbindungen wichtiger).

Hej again,

danke für das Aktualisieren des Templates. So macht das Sinn. :-)

Habe heute wieder ein Update für den RGBW-Shelly.

Mir hat die Einbindung mit dem Verbrauch für den Shelly1PM sehr gut gefallen - weshalb ich es für den RGBW übernommen habe (auch wenn dieser nur den Verbrauch liefert). :-)

Deshalb:
--- /tmp/mqtt2.template_origin 2019-06-20 22:12:48.564811047 +0200
+++ /tmp/mqtt2.template 2019-06-23 23:00:49.985475887 +0200
@@ -1099,7 +1099,7 @@
attr DEVICE webCmd on:off:white:gain:rgb:effect
attr DEVICE setStateList on off
attr DEVICE icon light_control
-attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; "<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>"}
+attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"power","unknown");; "<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>"}
attr DEVICE model A_17_shelly2rgbw_color

#contributed by user sledge
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Juni 2019, 07:30:02
Kurze Frage, bevor das in's svn geht und sich jemand mit einem "alten" RGBW beschwert...

Ist das Reading "power" bei allen Hardware-Revisionen vorhanden (und nur ggf. erst nach einem firmware-update verfügbar)?
(Wenn nein, brauchen wir evtl. zwei Templates oder wenigstens einen entsprechenden comment mit dem "abgespeckten" Code).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Juni 2019, 09:08:17
Guten Morgen,

da ich auch 2 x Shelly RGBW2 habe, habe ich eh mal ne Frage.
Woher bekommt ihr die ganzen Readings? Bei mir gibt es kein Reading das z.B. IP heißt.

Anbei mal ein List von einem RGBW2 nachdem er via autocreate in FHEM angelegt wurde und danach ein Neustart des RGBW2. Hinzu habe ich noch ein paar Minuten gewartet.
Internals:
   CFGFN     
   CID        shellyrgbw2_66138D
   DEF        shellyrgbw2_66138D
   DEVICETOPIC wz_regal
   FUUID      5d106f6e-f33f-fcb4-8727-f4a3723c5ad6045e
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 57
   MQTT2_FHEM_Server_TIME 2019-06-24 09:05:07
   MSGCNT     57
   NAME       wz_regal
   NR         882
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-06-24 09:05:07   blue            0
     2019-06-24 09:05:07   effect          0
     2019-06-24 09:05:07   gain            100
     2019-06-24 09:05:07   green           255
     2019-06-24 09:05:07   ison            false
     2019-06-24 09:05:07   mode            color
     2019-06-24 08:54:37   online          true
     2019-06-24 09:05:07   overpower       false
     2019-06-24 09:05:07   power           0.00
     2019-06-24 09:05:07   red             0
     2019-06-24 09:05:07   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   autocreate 1
   readingList shellyrgbw2_66138D:shellies/shellyrgbw2-66138D/color/0/status:.* { json2nameValue($EVENT) }
shellyrgbw2_66138D:shellies/shellyrgbw2-66138D/online:.* online
   room       MQTT2_DEVICE


Vergleich zu einem Shelly1 PM:
Internals:
   CHANGED   
   CID        shelly1pm_B1D901
   DEF        shelly1pm_B1D901
   DEVICETOPIC wz_deckenlicht
   FUUID      5ccd7540-f33f-fcb4-6b9f-63366162edfb7874
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 24879
   MQTT2_FHEM_Server_TIME 2019-06-24 09:09:00
   MSGCNT     24879
   NAME       wz_deckenlicht
   NR         122
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-06-22 15:45:03   fw_ver          20190612-090006/FW1.5.0_hotfix-HT-PM@5ea70469
     2019-06-22 15:45:03   id              shelly1pm-B1D901
     2019-06-24 09:09:00   input0          1
     2019-06-22 15:45:03   ip              192.168.20.52
     2019-06-23 13:04:39   longpush_0      1
     2019-06-22 15:45:03   mac             840D8EB1D901
     2019-06-22 15:45:03   new_fw          false
     2019-06-22 15:45:03   online          true
     2019-06-24 09:09:00   overtemperature 0
     2019-06-24 09:09:00   relay0          off
     2019-06-23 19:34:20   relay_0_energy  3237
     2019-06-24 09:09:00   relay_0_power   0.00
     2019-06-24 09:09:00   state           off
     2019-06-24 09:09:00   temperature     25.76
Attributes:
   IODev      MQTT2_FHEM_Server
   alexaName  Wohnzimmer Deckenlicht
   alias      Wohnzimmer Deckenlicht
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"<div><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> Aktuell: $cons W / Temperatur: $temp °C</div>"}
   event-on-change-reading .*
   genericDeviceType light
   group      Licht
   model      A_10b_shelly1pm
   readingList shellies/shelly1pm-B1D901/relay/0:.* state
  shellies/shelly1pm-B1D901/relay/0:.* relay0
  shellies/shelly1pm-B1D901/input/0:.* input0
  shellies/shelly1pm-B1D901/online:.* online
  shellies/shelly1pm-B1D901/announce:.* { json2nameValue($EVENT) }
  shellies/shelly1pm-B1D901/relay/0/power:.* relay_0_power
  shellies/shelly1pm-B1D901/temperature:.* temperature
  shellies/shelly1pm-B1D901/overtemperature:.* overtemperature
  shellies/shelly1pm-B1D901/relay/0/energy:.* relay_0_energy
  shellies/shelly1pm-B1D901/longpush/0:.* longpush_0
shelly1pm_B1D901:shellies/announce:.* { json2nameValue($EVENT) }
   room       Alexa,FHEM / Info,MQTT,Wohnzimmer
   setList    relay0:on,off,toggle shellies/shelly1pm-B1D901/relay/0/command $EVTPART1
  off:noArg shellies/shelly1pm-B1D901/relay/0/command off
  on:noArg shellies/shelly1pm-B1D901/relay/0/command on
  update:noArg shellies/shelly1pm-B1D901/command update_fw
   webCmd     :relay0


Ich selber vermute ja, dass es an der aktuellen FW liegt. Was sagt ihr dazu?
Ach ja.. der json output im Zweig ip/color/0/status bietet diese Ausgabe auch nicht. Diese Infos stehen nur im Zweig des shellys direkt unter ip/status.

@Beta-User: Bei meinen RGBW2 gibt es das Reading. Was sagen die Kollegen mit der älteren Version?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Juni 2019, 11:01:21
Nochmal guten Morgen,

warum es nicht alleine angelegt wird, weiß ich nicht ABER @ Beta-User, es ist wie bei den anderen Shellys auch. Das eine Reading, was normal automatisch kommt, muss man sich manuell anlegen. In meinem Fall:
shellyrgbw2_66138D:shellies/announce:.* { json2nameValue($EVENT) }

Wir hatten das in den anderen Templates ausgenommen, da dies das einzige Reading mit "_" ist und komplett am Standard vorbei geht. Das gute "früher" - Es wurde automatisch angelegt nach einem Neustart des Shellys. Bei den RGBW2 Geräten, mit aktueller FW leider nicht. Über das Template könnte man es anlegen ABER bitte beachten, dass hier wirklich "_" anstelle von "-" im DEV-Name ist.

Das announce Reading geht auch nur so wie oben beschrieben. Ein Reading im normalem Stiel geht NICHT.
Bitte mit einbauen, wenn möglich.

Da ich zwei Shellys neu aus der Verpackung (Freitag bekommen) habe, und beide das gleiche Verhalten zeigen, auch nach Reset usw., denke ich es wird nicht an mir liegen....

Nach dem anlegen dieses Readings, sieht es dann so aus:


Internals:
   CID        shellyrgbw2_66138D
   DEF        shellyrgbw2_66138D
   DEVICETOPIC wz_regal
   FUUID      5d106f6e-f33f-fcb4-8727-f4a3723c5ad6045e
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 111
   MQTT2_FHEM_Server_TIME 2019-06-24 11:00:34
   MSGCNT     111
   NAME       wz_regal
   NR         378
   STATE      ???
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-06-24 11:00:34   blue            0
     2019-06-24 11:00:34   effect          0
     2019-06-24 10:52:33   fw_ver          20190531-080138/v1.5.0-hotfix2@022ec015
     2019-06-24 11:00:34   gain            100
     2019-06-24 11:00:34   green           255
     2019-06-24 10:52:33   id              shellyrgbw2-66138D
     2019-06-24 10:52:33   ip              192.168.20.55
     2019-06-24 11:00:34   ison            false
     2019-06-24 10:52:33   mac             B4E62D66138D
     2019-06-24 11:00:34   mode            color
     2019-06-24 10:52:33   new_fw          false
     2019-06-24 10:52:33   online          true
     2019-06-24 11:00:34   overpower       false
     2019-06-24 11:00:34   power           0.00
     2019-06-24 11:00:34   red             0
     2019-06-24 11:00:34   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   autocreate 1
   readingList shellies/shellyrgbw2-66138D/color/0/status:.* { json2nameValue($EVENT) }
shellies/shellyrgbw2-66138D/online:.* online
shellyrgbw2_66138D:shellies/announce:.* { json2nameValue($EVENT) }
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Juni 2019, 11:23:19
Hmm, da alle Shellys diesen topic nutzen, geht das m.E. via template nicht so einfach:

Das template muß nämlich auch dann passen, wenn MQTT2_CLIENT als IODev genutzt wird. Da kommen dieselben Daten aber unter einer anderen CID rein (das war wohl der wahre Grund, warum das rausgeflogen ist)...

Jetzt könnte man zwar abfragen, welcher IO-Typ verwendet wird und das Reading dann nur setzen, wenn das der Fall ist (oder ggf. den JSON immer analysieren und nur auswerten, wenn die richtige ID dabei ist), aber ganz ehrlich: ersteres ist sehr viel Aufwand, für letzteres würde ich ein paar Rohdaten benötigen und kann noch nicht sagen, wann das was wird... Einfacher wäre es, wenn man den announce-Pfad umbiegen könnte.

(Wenn jemand sich berufen fühlt: den JSON bedingt auszuwerten ist Teil der tasmota-IR und -RF-templates; vielleicht findet jemand eine "einfache" Lösung, die man dann ausrollen kann?).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Juni 2019, 15:13:10
ZitatDas template muß nämlich auch dann passen, wenn MQTT2_CLIENT als IODev genutzt wird. Da kommen dieselben Daten aber unter einer anderen CID rein (das war wohl der wahre Grund, warum das rausgeflogen ist)...
Den Teil verstehe ich nicht...

Habe mir den Teil nun manuell eingefügt und kann damit leben. Ggf. ein Hinweis im Template, würde ja schon reichen. Nicht jeder braucht diese Readings. ABER wenn jemand dieses Template nutzt, wird dieser sich wundern warum er niemals z.B. ein ip Reading bekommt und somit auch nicht über den grünen Kreis auf das WEB-IF kommt. Ich wusste bzw dachte mir das nun auch nur aufgrund der anderen Templates. Hätte ich da nicht selber mitgewirkt, wäre ich erstmal nicht darauf gekommen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Juni 2019, 15:18:40
Zitat von: 87insane am 24 Juni 2019, 15:13:10
Den Teil verstehe ich nicht...
Einfach: Wer mosquitto+MQTT2_CLIENT nutzt, hat keine CID mehr, die Rückschlüsse auf den ursprünglichen Sender (den Shelly) zuläßt; es landet alles (erst mal) an derselben Stelle. Das Verhalten ist (in etwa) so, wie wenn du die CID ganz wegläßt: dann bekommen auch alle deine Shellys die announce-Messages von allen anderen...

Dass es nicht funzt mit dem Punkt ist ärgerlich, aber wie gesagt: Ohne eine RAW-Message kann ich nichts tun, sonst könnte ich ggf. mit regex und etwas Perl filtern bzw. die jeweils richtigen Messages auch erkennen, wenn keine (korrekte/noch auf die ursprüngliche Datenquelle verweisende) CID da ist...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Juni 2019, 16:07:55
Danke für die Erklärung!

Reicht dir einfach via verbose 5 und die Nachricht eintrudeln lassen? Wenn ja kann ich dir diese bereit stellen...(Shelly RGBW 2)

EventMonitor (vermutlich unnütz):
2019-06-24 15:58:43 Global global ATTR wz_regal readingList shellies/shellyrgbw2-66138D/color/0/status:.* {json2nameValue($EVENT)}   shellies/shellyrgbw2-66138D/color/0:.* state   shellies/shellyrgbw2-66138D/color/0:.* relay0   shellyrgbw2_66138D:shellies/announce:.* { json2nameValue($EVENT) } shellyrgbw2_66138D:shellies/shellyrgbw2-66138D/online:.* online

LOGFILE (Mal den ganzen Block genommen und natürlich PW + Benutzer entfernt.):
2019.06.24 15:58:43 4: Connection accepted from MQTT2_FHEM_Server_192.168.20.55_24196
2019.06.24 15:58:43 5: CONNECT: (16).(0)(4)MQTT(4)(194)(0)<(0)(18)shellyrgbw2-66138D(0)(2)BENUTZERNAME(0)(10)PASSWORT
2019.06.24 15:58:43 4: MQTT2_FHEM_Server_192.168.20.55_24196 shellyrgbw2-66138D CONNECT V:4 keepAlive:60 usr:BENUTZERNAME
2019.06.24 15:58:43 5: PUBLISH: 0((0)"shellies/shellyrgbw2-66138D/onlinetrue
2019.06.24 15:58:43 4: MQTT2_FHEM_Server_192.168.20.55_24196 shellyrgbw2-66138D PUBLISH shellies/shellyrgbw2-66138D/online:true
2019.06.24 15:58:43 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000shellyrgbw2_66138D\000shellies/shellyrgbw2-66138D/online\000true
2019.06.24 15:58:43 5: PUBLISH: 0(155)(1)(0)(17)shellies/announce{"id":"shellyrgbw2-66138D","mac":"B4E62D66138D","ip":"192.168.20.55","new_fw":false, "fw_ver":"20190531-080138/v1.5.0-hotfix2@022ec015"}
2019.06.24 15:58:43 4: MQTT2_FHEM_Server_192.168.20.55_24196 shellyrgbw2-66138D PUBLISH shellies/announce:{"id":"shellyrgbw2-66138D","mac":"B4E62D66138D","ip":"192.168.20.55","new_fw":false, "fw_ver":"20190531-080138/v1.5.0-hotfix2@022ec015"}
2019.06.24 15:58:43 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000shellyrgbw2_66138D\000shellies/announce\000{"id":"shellyrgbw2-66138D","mac":"B4E62D66138D","ip":"192.168.20.55","new_fw":false, "fw_ver":"20190531-080138/v1.5.0-hotfix2@022ec015"}
2019.06.24 15:58:43 5: PUBLISH: 0(165)(1)(0)*shellies/shellyrgbw2-66138D/color/0/status{"ison":false,"mode":"color","red":0,"green":255,"blue":0,"white":0,"gain":100,"effect":0,"power":0.00,"overpower":false}
2019.06.24 15:58:43 4: MQTT2_FHEM_Server_192.168.20.55_24196 shellyrgbw2-66138D PUBLISH shellies/shellyrgbw2-66138D/color/0/status:{"ison":false,"mode":"color","red":0,"green":255,"blue":0,"white":0,"gain":100,"effect":0,"power":0.00,"overpower":false}
2019.06.24 15:58:43 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000shellyrgbw2_66138D\000shellies/shellyrgbw2-66138D/color/0/status\000{"ison":false,"mode":"color","red":0,"green":255,"blue":0,"white":0,"gain":100,"effect":0,"power":0.00,"overpower":false}


Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Juni 2019, 19:12:05
Zitat von: Mr. P am 17 Juni 2019, 22:35:57
So gefällt mir das. :-)
Einen hab ich noch für dich:
--- mqtt2.template_origin 2019-06-17 22:19:57.610684304 +0200
+++ mqtt2.template 2019-06-17 22:24:08.630973185 +0200
@@ -1083,9 +1083,9 @@
attr DEVICE setList\
   off:noArg shellies/DEVNAME/color/0/command off\
   on:noArg shellies/DEVNAME/color/0/command on\
-  white:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","white":"$EVTPART1"}\
-  gain:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","gain":"$EVTPART1"}\
-  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
+  white:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"white":"$EVTPART1"}\
+  gain:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"gain":"$EVTPART1"}\
+  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/DEVNAME/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/DEVNAME/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
   effect:select,0,1,2,3 shellies/DEVNAME/color/0/set {"effect":"$EVTPART1"}\
   update:noArg shellies/DEVNAME/command update_fw
deletereading -q DEVICE status_.*
@@ -1110,7 +1110,7 @@
   shellies/DEVNAME/online:.* online
attr DEVICE setList off:noArg shellies/DEVNAME/white/0/command off\
   on:noArg shellies/DEVNAME/white/0/command on\
-  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/0/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}\
+  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/0/set {"mode":"white","brightness":"$EVTPART1"}\
   x_update:noArg shellies/DEVNAME/command update_fw\
   x_mqttcom shellies/DEVNAME/command $EVTPART1
deletereading -q DEVICE (?!associatedWith).*
@@ -1129,7 +1129,7 @@
   shellies/DEVNAME/online:.* online
attr DEVICE_CH2 setList off:noArg shellies/DEVNAME/white/1/command off\
   on:noArg shellies/DEVNAME/white/1/command on\
-  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/1/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
+  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/1/set {"mode":"white","brightness":"$EVTPART1"}
attr DEVICE_CH2 setStateList on off
copy DEVICE DEVICE_CH3
setreading DEVICE_CH3 associatedWith DEVICE,DEVICE_CH2,DEVICE_CH4
@@ -1139,7 +1139,7 @@
   shellies/DEVNAME/online:.* online
attr DEVICE_CH3 setList off:noArg shellies/DEVNAME/white/2/command off\
   on:noArg shellies/DEVNAME/white/2/command on\
-  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/2/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
+  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/2/set {"mode":"white","brightness":"$EVTPART1"}
attr DEVICE_CH3 setStateList on off
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVNAME/white/3/status:.* {json2nameValue($EVENT)}\
@@ -1148,7 +1148,7 @@
shellies/DEVNAME/online:.* online
attr DEVICE_CH4 setList off:noArg shellies/DEVNAME/white/3/command off\
   on:noArg shellies/DEVNAME/white/3/command on\
-  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/3/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
+  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/white/3/set {"mode":"white","brightness":"$EVTPART1"}
setreading DEVICE_CH4 associatedWith DEVICE,DEVICE_CH2,DEVICE_CH3
attr DEVICE_CH4 setStateList on off


Damit wird beim Ändern der Helligkeit oder Einstellen der Farbe nicht auch automatisch das Licht (bei RGB sogar mit voller Stärke) eingeschalten. Nachträglich hab ich die Änderungen auch noch mit dem Verhalten aus der Shelly-App geprüft: Das Verhalten deckt sich damit auch mit dem Original. ;-)

Hey - Das habe ich persönlich wegen Alexa wieder umgeändert. Sage ich "Alexa, Wohnzimmer grün" macht sie das. Ohne das ON bei der Farbe, macht sie das nicht. Das ist aber auch nur ein Hinweis und kein meckern. Ich möchte mir eben nicht den Mund fusselig reden bevor die feine Dame reagiert :-P

ZitatThx, hab's mal (mit den alten Einschaltoptionen als .*_on) eingecheckt.
Dass das Einschalten so stattfindet, war mal ein ausdrücklicher Vorschlag hier gewesen; bin immer etwas unschlüssig, wie mit sowas zu verfahren ist (finde aber die Kompabilität mit anderen Einbindungen wichtiger).

Die Antwort habe ich dann doch noch gefunden...
An sich macht es ja Sinn - Warum sollte man an den Farbwerten spielen, wenn man diese nicht auch sehen will bzw. einschaltet? Also für Alexa und andere Systeme ist es einfacher (besser will ich nicht sagen), es mit dem sofortigem an zu nutzen.




Was mich aber wundert... Ich habe nun ein paar Seiten zurück geblättert aber nirgends eine Antwort gefunden auf folgendes:
white_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-66138D/color/0/set {"turn":"on","white":"$EVTPART1"}
  gain_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-66138D/color/0/set {"turn":"on","gain":"$EVTPART1"}
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-66138D/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-66138D/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}


Wofür sind die .*_on Befehle in setList hinzu gekommen? Hab mal ein wenig gespielt aber keinen Grund oder Sinn gefunden...

Und auch das ist mit der Antwort für mich erledigt und zufriedenstellend gelöst ;)

Anbei mal ein Bild, wie das bei mir nun aussieht... Nix besonderes, aber so können sich ggf. später lesende User das einfach ansehen :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 Juni 2019, 07:42:27
 :)
Schön, dass du das noch gefunden hast, warum die .*_on jetzt da sind. Dabei hatte ich irgendwo im Hinterkopf die Idee, dass man das ggf. für das mapping für die Sprachsteuerung entsprechend "umbiegen" könnte?
Also du nennst eine Farbe, es wird aber per Sprachsteuerung nicht das rgb-Reading gemappt, sondern rgb_on.

So kann jeder die templates nutzen, es braucht "nur" passende Attribute für die Sprachsteuernung... (Aber da ich sowas nicht nutze, kann ich eben nur die Idee hierher schreiben, testen/umsetzen können/müssen andere ;) ).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Juni 2019, 08:01:52
Hey und guten Morgen,

ja das würde auch gehen. Thema wäre hier "homebridgemapping". Würde ich mich dran hängen aber auch nur zuhause. Aus der Ferne finde ich Tests mit Alexa eher semi.
Ich habe in meinem Hinterkopf das ein sehr freundlicher Kollege hier, mal gegen das Umbiegen war und deswegen habe ich das nicht mal mehr angefasst, da man es ja in der setlist anpassen kann mit zwei Klicks.

Aber gut :) Hänge ich mich dran. Sollte in dem Fall auch nicht sooo schwer sein. Aber mal anders rum.... Warum werden nicht einfach die normalen Befehle für Alexa genommen (werden ja automatisch angenommen/gemappt) und die .*_on Befehle für FHEM? So spart man sich das homebridgemapping. Oder habe ich da was übersehen?

Sagt mal, ich hatte die Frage bereits gestellt aber keine Antwort bekommen. Wenn man Alexa sagt, sie soll Wohnzimmer "weiß" machen (für jede wirkliche Farbe geht das so), schaltet sie rot ein. Nun habe ich mich bisher noch nie mit den RGB/BRI usw beschäftigt und kann mir das nur so halb erklären. Getestet habe ich mit zwei verschiedenen Stripes an zwei verschiedenen RBGW2. Der eine Stripe ist mit W verbunden und der andere hat kein weiß. Beide springen im aber auf rot.
Also die Frage - Wie schalte ich nun einfach weiß ein? Muss ich sowas sagen wie - Schalte rgb ab? Bin gespannt was ihr sagt.

Ansonsten habe ich für mich das Template leicht angepasst. Die Schiebregler müssen in meinen Augen untereinander oder weg. Diese nehmen in der automatischen Ansicht von FHEM zu viel Platz ein und verschieben alles andere. Kann mir jemand sagen wie ich die Schiebregler untereinander bekomme? Wie es bei mir aktuell aussieht, seht ihr im Post zuvor. An sich finde ich das gut so aber es ist doof, dass ich nicht sehen kann welches Dropdown, für was ist (außer mit mouseover). Ich weiß das dieses Template echt viel Arbeit war aber hier können wir alle bestimmt noch etwas dran schrauben :)

Danke @ ALL
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Mr. P am 25 Juni 2019, 13:15:40
Zitat von: Beta-User am 24 Juni 2019, 07:30:02
Kurze Frage, bevor das in's svn geht und sich jemand mit einem "alten" RGBW beschwert...

Ist das Reading "power" bei allen Hardware-Revisionen vorhanden (und nur ggf. erst nach einem firmware-update verfügbar)?
(Wenn nein, brauchen wir evtl. zwei Templates oder wenigstens einen entsprechenden comment mit dem "abgespeckten" Code).
Hello again,
das kann ich dir leider nicht sagen. Ich hab auch gerade Manuals der beiden Geräte gewälzt - aber hätte bei beiden nichts dazu gefunden.
Ist natürlich deine Entscheidung, aber sofern keiner hier mit liest, der einen von der ersten Generation hat, könnte man es nur darauf an kommen lassen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Juni 2019, 13:22:14
Wenn die älteren auch Power messung haben, haben die auch ein Power Reading.

Beispiel: shelly 1 OHNE PM = keine Messung und somit kein Reading.
Mit PM = mit Power Meter und auch dem Reading.

Im schlimmsten Fall, muss der User sein devstate anpassen.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Mr. P am 25 Juni 2019, 13:35:24
Zitat von: 87insane am 25 Juni 2019, 13:22:14
Wenn die älteren auch Power messung haben, haben die auch ein Power Reading.

Beispiel: shelly 1 OHNE PM = keine Messung und somit kein Reading.
Mit PM = mit Power Meter und auch dem Reading.

Im schlimmsten Fall, muss der User sein devstate anpassen.

Gesendet von meinem LG-H850 mit Tapatalk
Das ist schon klar - nur haben wir keinen Älteren zum Testen. ;-)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 Juni 2019, 13:40:09
Zitat von: Mr. P am 25 Juni 2019, 13:15:40
[...] aber sofern keiner hier mit liest, der einen von der ersten Generation hat, könnte man es nur darauf an kommen lassen.
:) . In die Richtung hatte ich das dann auch überlegt, nachdem es hier so ruhig dazu war...

Also @all: letzte Gelegenheit zu Gegenmaßnahmen ;) .



Zitat von: 87insane am 24 Juni 2019, 16:07:55
Reicht dir [...]
Probier mal (in einem oder mehreren der templates) die readingList vorne mit dieser Zeile zu ergänzen (oder die rL direkt zu bearbeiten, dann DEVICE entsprechend ersetzen):
shellies/announce:.* { $EVENT =~ m,..id...DEVICE...mac.*, ? json2nameValue($EVENT) : undef }\


Zitat von: 87insane am 25 Juni 2019, 08:01:52
[...] Ich habe in meinem Hinterkopf das ein sehr freundlicher Kollege hier, mal gegen das Umbiegen war
Kann ich nachvollziehen; was direkt geht, sollte man auch direkt machen, ABER:
Wenn der (vermeintlich) direkte Weg zu Nebenwirkungen führt bei anderen Nutzern, die mit den defaults arbeiten oder dort zu Verbiegungen an anderer Stelle führt, muß man eben eine Abwägung treffen. Da ich jetzt vernommen habe, dass das mit dem mapping recht einfach einzurichten ist, sehe ich überhaupt keine Probleme mit diesem "Umweg", sondern fühle mich ganz wohl mit der Bauchentscheidung (gegen deinen ursprünglichen und auch nachvollziehbaren Vorschlag).

Würde auch empfehlen, das mit den .*-on-Befehlen zu mappen und nicht manuell einzugreifen. Wie es aussieht, hat justme1968 das template-Thema "auf dem Schirm", so dass wir uns irgendwann mal über Standards zu diesem Thema Gedanken machen müssen. (und ich hatte jüngst auch eine ähnliche Diskussion mit gleichzeitigem Anschalten (bzw. Abdimmen) bei den MiLights).
Wenn also jemand bessere Ideen für eine standardisierte Benennung der setter hat: Her damit, je eher, desto besser ::) .
Ist halt das Los, das wir jeweils gezogen haben, weil wir auf unterschiedlichen Seiten des svn sitzen ;D .


Zitat von: 87insane am 25 Juni 2019, 13:22:14
Im schlimmsten Fall, muss der User sein devstate anpassen.
...mit so einer Aussage disqualifizierst du dich für den Anfängerbereich im Forum :P ...

Im Ernst: War vielleicht etwas mißverständlich gefragt, aber mir ging es nur um die Revisionen der RGBW-Devices, oder hatte ich da was mißverstanden?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Juni 2019, 14:34:32
ZitatProbier mal (in einem oder mehreren der templates) die readingList vorne mit dieser Zeile zu ergänzen (oder die rL direkt zu bearbeiten, dann DEVICE entsprechend ersetzen):
shellies/announce:.* { $EVENT =~ m,..id...DEVICE...mac.*, ? json2nameValue($EVENT) : undef }\
Und hiermit qualifiziere ich mich wieder für den Anfänger-Bereich. -> Sicherlich hattest du was im Kopf aber das kam bei mir nicht an. Ich soll rL anpassen zum testen. Das verstehe ich. Aber was ich da einsetzen soll geht für mich nicht daraus hervor. Du meinst bestimmt, das ich quasi ein ganzes Ereignis in den Bereich {} schiebe. Da brauche ich aber leider Starthilfe :-\

ZitatKann ich nachvollziehen; was direkt geht, sollte man auch direkt machen, ABER:
Wenn der (vermeintlich) direkte Weg zu Nebenwirkungen führt bei anderen Nutzern, die mit den defaults arbeiten oder dort zu Verbiegungen an anderer Stelle führt, muß man eben eine Abwägung treffen. Da ich jetzt vernommen habe, dass das mit dem mapping recht einfach einzurichten ist, sehe ich überhaupt keine Probleme mit diesem "Umweg", sondern fühle mich ganz wohl mit der Bauchentscheidung (gegen deinen ursprünglichen und auch nachvollziehbaren Vorschlag).

Würde auch empfehlen, das mit den .*-on-Befehlen zu mappen und nicht manuell einzugreifen. Wie es aussieht, hat justme1968 das template-Thema "auf dem Schirm", so dass wir uns irgendwann mal über Standards zu diesem Thema Gedanken machen müssen. (und ich hatte jüngst auch eine ähnliche Diskussion mit gleichzeitigem Anschalten (bzw. Abdimmen) bei den MiLights).
Wenn also jemand bessere Ideen für eine standardisierte Benennung der setter hat: Her damit, je eher, desto besser ::) .
Ist halt das Los, das wir jeweils gezogen haben, weil wir auf unterschiedlichen Seiten des svn sitzen ;D .
Ich habe auch nichts gegen den Weg es direkt aktiv zu schalten, wenn man an der z.B. Farbe spielt. Ohne das die LED leuchtet, weiß ich ja nicht wie diese dann genau aussehen... Selbst wenn ich das bei einigen Farbwerten weiß - WARUM sollte jemand die Farbe einstellen aber das Licht nicht? Aber gut, auch ohne Begründung schaue ich in jedem Fall mal nach dem Mapping. Das wird aber erst am WE oder in der folge Woche geschehen. Konnte bisher leider, nicht mal mehr in den Thread schauen, in dem es um das erlernen von PERL geht :-\

Was ich verstanden habe dazu:
Du würdest die _on Befehle (nicht die Standard on Befehle) nutzen, für das Mapping. Grund, den ich verstanden habe: Ggf. Probleme mit anderen Kompatibilitäten. (Bester Grund!) - Werde mich nochmal einlesen und der Sache annehmen. Hatte ja in einem anderen Template schon daran gebastelt...

Was die Benamung der setter angeht, ist vermutlich einfach an statt on nicht erlaubt, da es wohl Wechselwirkung geben wird.
Es dürfte eigentlich kein Gerät geben, welches zwei (oder mehrfach) on benötigt. Wenn man das via Mapping "global" lösen kann, wäre das ja schon der gute Weg. Hier geht es ja tatsächlich nur darum, dass Verhalten anzupassen. Wenn man Alexa sagt "Mach das Wohnzimmer grün" und sie sagt okay, stellt die Farbe ein aber macht nichts an, macht es keinen Sinn. Das gibt es in der Art ja kaum für andere Geräte. Bei einem normalem Gerät sage ich "Mach das und das an". Dann macht sie das auch direkt.

Was ist beim MiLight Thema rauß gekommen? Hab im Bad seit x Jahren welche. Aber bisher noch nicht eingebunden, da ich das mit der Bridge so doof finde. Da warte ich mal bis es irgendwann so geht oder belasse es so wie es ist (offline mit Fernbedienung).

Zitat...mit so einer Aussage disqualifizierst du dich für den Anfängerbereich im Forum :P ...

Im Ernst: War vielleicht etwas mißverständlich gefragt, aber mir ging es nur um die Revisionen der RGBW-Devices, oder hatte ich da was mißverstanden?
Hey - da gibt es aber leider die meisten Antworten :) Den müsst ihr mir schon sperren, damit ich da nicht mehr rum weine :-P

Es gibt (soweit ich weiß) den alten RGBW1 und eben den neuen RGBW2. Der 1er wurde meines Wissens nach aber nur 2 Chargen lang verkauft. Danach wieder aus dem Programm genommen, da der 2er um einiges kleiner und besser ist. Soweit ich das verstehe (macht aber auch Sinn), sollten beide Versionen das eigentlich können. Die Technik muss ja die LEDs mit der richtigen Spannung versorgen. Aber das ist nur geraten, da (wie bereits gesagt wurde) NICHTS erkennbares im Katalog oder den Tech-Speks steht.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 Juni 2019, 14:57:21
Zitat von: 87insane am 25 Juni 2019, 14:34:32
Und hiermit qualifiziere ich mich wieder für den Anfänger-Bereich. -> Sicherlich hattest du was im Kopf aber das kam bei mir nicht an. Ich soll sL anpassen zum testen. Das verstehe ich. Aber was ich da einsetzen soll geht für mich nicht daraus hervor. Du meinst bestimmt, das ich quasi ein ganzes Ereignis in den Bereich {} schiebe. Da brauche ich aber leider Starthilfe :-\
...wilkommen zurück :P ...
Vorab: die {} sind "nur dazu da, um dem Modulcode zu sagen, dass jetzt Perl kommt. Da wird dann erst eine Regex geprüft. Da mein Code für attrTemplate war, wäre "DEVICE" durch den falschen Parameter ersetzt worden; es muß "DEVNAME" sein, also z.B. "shellyrgbw2-66138D" (aus deinem list/Eventmonitor).
Zitat
Ich habe auch nichts gegen den Weg es direkt aktiv zu schalten, wenn man an der z.B. Farbe spielt. [...]
Sorry, dass ich das Farbthema immer ignoriere, aber ich kann da schlicht nicht helfen...
Vielleicht hat jemand anderes eine Idee?

Zitat
Du würdest die _on Befehle (nicht die Standard on Befehle) nutzen, für das Mapping.
Ja, so war's angedacht. Für FHEM-intern "normale" Funktionsweise, für das Sprachsteuerungs-mapping (wo erforderlich) der .*_o(n|ff)-Teil :) .
Zitat
Was die Benamung der setter angeht, ist vermutlich einfach an statt on nicht erlaubt, da es wohl Wechselwirkung geben wird.
Zum einen finde ich deutsche Benennungen in einem Softwareumfeld nicht optimal, zum anderen finde ich es einleuchtender, wenn der "eigentliche" Befehl (hier: Farbe) gut zu erkennen ist und vorne steht.
ZitatWas ist beim MiLight Thema rauß gekommen? Hab im Bad seit x Jahren welche. Aber bisher noch nicht eingebunden, da ich das mit der Bridge so doof finde. Da warte ich mal bis es irgendwann so geht oder belasse es so wie es ist (offline mit Fernbedienung).
Du könntest mit Basteln anfangen und eine sidoh-Bridge bauen; wenn du Glück hast, erkennt die auch Fernbedienungssignale... (ansonsten imo: Warnung! MiLights sind Müll, nicht kaufen...)

In der Sache: es geht darum, dass man z.B. Farbverläufe über der Zeit vogeben können soll. Das kann WifiLight (auch mit der sidoh-Bridge, aber eben über UDP) schon lange, aber WifiLight kann (noch) nicht "zusammen" mit MQTT2_DEVICE. Die Kombi bzw. eine ähnliche Erweiterung für MQTT2_DEVICE wäre auch für die anderen Bulbs interessant, die via MQTT2_DEVICE eingebunden werden können, und den WifiLight-Autor interessiert auch, wie es ggf. geht (uU. aber direkt über die firmware der sidoh-Bridge :P ).

Das kann aber alles dauern, das ist alles andere als trivial...
Zitat
Es gibt (soweit ich weiß) den alten RGBW1 und eben den neuen RGBW2. Der 1er wurde meines Wissens nach aber nur 2 Chargen lang verkauft.
Ok, also kurz gesagt: bei einer verschwindenden Minderheit klappt das vielleicht nicht. Dann müssen die Betroffenen eben ggf. wirklich nacharbeiten... :P
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Juni 2019, 15:14:27
Zitat...wilkommen zurück :P ...
Vorab: die {} sind "nur dazu da, um dem Modulcode zu sagen, dass jetzt Perl kommt. Da wird dann erst eine Regex geprüft. Da mein Code für attrTemplate war, wäre "DEVICE" durch den falschen Parameter ersetzt worden; es muß "DEVNAME" sein, also z.B. "shellyrgbw2-66138D" (aus deinem list/Eventmonitor).
Jetzt hätte ich fast ein böses Wort verloren beim lachen :-P
Das mit den Klammern usw weiß ich mittlerweile ja auch. Das wäre echt peinlich zum jetzigem Zeitpunkt, nach deinen x Erklärungen....

Bin nur etwas verwundert gewesen weil:
shellies/announce:.* { $EVENT =~ m,..id...DEVICE...mac.*, ? json2nameValue($EVENT) : undef }
DEVICE oder DEVNAME ist klar. Finde die ganzen "..." etwas komisch. Hier dachte ich, wolltest du sowas sagen wie "usw". Aber genau das usw, kenne ich leider nicht. Hab mit den JSON bisher ja noch nie basteln müssen. Habe ja immer ein schönes Extrakt bekommen. Wie diese von innen aussehen, weiß ich, brauchte ich aber nie aktiv. Höchstens mal lesen was drin steht um ggf. Fehler zu finden.
Muss hier nur der name oder aber auch der Rest rein oder hattest du was bestimmtes im Sinn?

ZitatSorry, dass ich das Farbthema immer ignoriere, aber ich kann da schlicht nicht helfen...
Vielleicht hat jemand anderes eine Idee?
Da bin ich mal gespannt auf eine Antwort :)

Zitat.*_o(n|ff)-Teil
Hatte da jemand zu wenig bit über? :-P Süßes regex

ZitatDu könntest mit Basteln anfangen....
Tatsächlich schon getan. Nur nicht mit den MiLights oder für diese. Finde die auch eher schlecht. Weswegen die keine Rolle bisher spielten. Dachte ich springe mal auf den Zug auf und frage mal. Aber meine Meinung festigte sich nur, durch deine Antwort. Wenn die durch sind, kommen andere da rein.

Bin gleich erstmal unterwegs aber habe meine Augen auf dem Thema hier. Danke @ All!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Juni 2019, 15:35:47
Ich nochmal... Habe gerade in den anderen Templates gesehen, du meinst das wirklich so mit den "..."
Verstehe ich das richtig, du willst gucken was rein läuft und wenn der Name passt, soll er alles was er findet für das Gerät einfach als Reading fest halten. Aber nur dann, wenn genau das JSON Paket rein kommt, indem auch die id, mac usw steht. Gute Idee!

Teste ich ....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 Juni 2019, 15:46:21
Zitat von: 87insane am 25 Juni 2019, 15:14:27
Hier dachte ich, wolltest du sowas sagen wie [...]
...eigentlich wollte ich mal wieder sagen: teste es doch selbst aus, wie es gemeint war, dann hast du wieder was gelernt ;) .

Scheint funktioniert zu haben, genau das soll passieren :) .

ZitatHatte da jemand zu wenig bit über? :-P Süßes regex
;D ;D 8)

Zitat
Tatsächlich schon getan. Nur nicht mit den MiLights oder für diese. Finde die auch eher schlecht.
(Ganz heimlich: ich bin mit den Dingern nicht unzufrieden, habe knapp 20 von denen im Einsatz (über eine sidoh-Bridge@MQTT2). Da ich die Einschränkungen kenne, geht das in Ordnung, nur gibt's eben zwischenzeitlich zu ähnlichen Konditionen bessere Optionen.
ABER: Wenn du z.B. "einfach nur ein Input-Device" suchst, sind die Fernbedienungen kaum schlagbar ;) . Die gibt's auch zum "an-die Wand-schrauben", in der Regel mit 4 Kanälen (bzw. eigentlich 5), die neben on/off jeweils Brightness und Farbe (als Slider oder Drehrad) und ein paar Sonderkommandos liefern (aber nur über diese Bridge!), das ganze für 20 Steine (der hier sollte z.B. funktionieren: https://smile.amazon.de/Touchscreen-Controller-Angetrieben-Batterien-Scheinwerfer/dp/B07BVTQRNN/ref=sr_1_7?keywords=milight&qid=1561469989&s=gateway&sr=8-7). 
Über die Optik mag man streiten, aber das geht eigenlich auch; bräuchte man nur noch einen Anwendungsfall für (z.B. Lautstärke in unterschiedlichen Zonen kontrollieren, Rollos fahren..., einen Montageort und Zeit und Lust ;) ))
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Juni 2019, 16:17:02
Ob es klappt oder nicht konnte ich erst jetzt testen. Geht aber! Die readings sind nach Neustart sofort (wie gewohnt) rein gelaufen. Somit kann man das ja bei allen shellys nutzen.

Was es genau macht habe ich erst gesehen, beim ansehen der json. Gut getrixt!

Kurz, weil Handy. Morgen geht es weiter. Bin nun im Off. Aber schon mal einen Teil für alle shellys wieder gefunden. Geil!

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 Juni 2019, 17:14:33
Ab morgen sollte dann via update dann

- diese regex für alle shellys kommen (ausgenommen die templates, die (noch) keine readingList hatten);
- noch mehr der .*_on-setter da sein;
- das devStateIcon für die RGBW's power beinhalten.

Frage zum ersten Punkt: da war früher mal ein announce auch auf den Device-Zweig drin. Ist der weggefallen bzw. fällt nach einem firmwareupate weg? (Dann würde ich das auch beizeiten mal rausnehmen).


Zitat von: 87insane am 25 Juni 2019, 16:17:02
Gut getrixt!
;D Man lernt ja schließlich nie aus; hoffe das paßt jetzt auch tatsächlich überall wie ausgerollt... ;D



OT-EDIT: In der Bucht habe ich ein paar von den Wand-MiLight-FBs gefunden, die noch günstiger waren; da konnte ich nicht widerstehen, die von mir genannten Einsatzmöglichkeiten haben mich überzeugt, und Dimmen über einen HM-Taster geht zwar, ist aber auch nicht optimal :P

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Juni 2019, 18:46:05
Nur kurz, da Handy...

Noch mehr von den .*_on settern. Nur im rgw2 oder wo anders? Wenn du wo anders meinst, haben wir uns Miss-verstanden. Zumindest bei den "mit mir mit erstellten" templates wird das nirgends gebraucht. Da haben wir überall eine bessere Lösung gefunden.

Den Rest muss ich leider auf morgen vertagen und beantworten.

Aber geil - danke!

Geht nicht anders... Edit: den Befehl, den du nun vermisst, checke ich morgen. Leider melden sich solche readings nicht wenn die nicht mehr kommen. [emoji44][emoji13]


Gesendet von meinem LG-H850 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 26 Juni 2019, 13:04:48
Hey zusammen,

habe nun beim Shelly1PM getestet und das announce Reading gibt es nicht mehr... Vermutlich echt durch Update weg gefallen.
Folgende Readings bekommt man für den 1er PM:
shellies/shelly1pm-B1D901/relay/0:.* relay_0
shellies/shelly1pm-B1D901/input/0:.* input_0
shellies/shelly1pm-B1D901/relay/0/power:.* relay_0_power
shellies/shelly1pm-B1D901/relay/0/energy:.* relay_0_energy
shellies/shelly1pm-B1D901/temperature:.* temperature
shellies/shelly1pm-B1D901/overtemperature:.* overtemperature
shellies/shelly1pm-B1D901/online:.* online
shelly1pm_B1D901:shellies/shelly1pm-B1D901/longpush/0:.* longpush_0

shellies/shelly1pm-B1D901/relay/0:.* state
shellies/announce:.* { $EVENT =~ m,..id...shelly1pm-B1D901...mac.*, ? json2nameValue($EVENT) : undef }


Das letzte hatte ich natürlich selber eingefügt am Ende (damit ich IP usw bekomme).
relay/0 zu state ist auch manuell, wegen dem Template.
Hinzu sind alle relay0 zu relay_0 geworden. Das muss im Template für z.B. den 1er PM angepasst werden. (ist hier nur für setList relevant.)

Anbei auch mal ip/status JSON:
{"wifi_sta":{"connected":true,"ssid":"HierStehtDieSSID","ip":"192.168.20.52","rssi":-56},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"12:57","serial":1,"has_update":false,"mac":"840D8EB1D901","relays" :[{"ison":false, "has_timer":false,"overpower":false}],"meters":[{"power":0.00,"is_valid":true,"timestamp":1561553873,"counters":[0.000, 15.038, 0.000],"total":15}],"temperature":29.49,"overtemperature":false,"update":{"status":"idle","has_update":false,"new_version":"20190612-090006/FW1.5.0_hotfix-HT-PM@5ea70469","old_version":"20190612-090006/FW1.5.0_hotfix-HT-PM@5ea70469"},"ram_total":50856,"ram_free":39216,"fs_size":233681,"fs_free":169927,"uptime":206}

Hinzu ip/relay/0/status JSON:
{"ison":false, "has_timer":false,"overpower":false}

Man könnte noch mehr rauß ziehen ^^ (Die Frage ist ob man das brauch).

EDIT:
Anbei die Readinglist für Shelly1 OHNE PM:
shellies/shelly1-93ABF9/relay/0:.* relay_0
shellies/shelly1-93ABF9/input/0:.* input_0
shellies/shelly1-93ABF9/online:.* online
shellies/shelly1-93ABF9/relay/0:.* state
shellies/announce:.* { $EVENT =~ m,..id...shelly1-93ABF9...mac.*, ? json2nameValue($EVENT) : undef }


Anbei die Readinglist für Shelly 2.5 im Roller Mode:
shellies/shellyswitch25-007FC8/online:.* online
shellies/shellyswitch25-007FC8/roller/0:.* roller_0
shellies/shellyswitch25-007FC8/roller/0/pos:.* pct
shellies/shellyswitch25-007FC8/roller/0/pos:.* state
shellies/shellyswitch25-007FC8/roller/0/power:.* roller_0_power
shellies/shellyswitch25-007FC8/relay/power:.* power
shellies/shellyswitch25-007FC8/roller/0/energy:.* roller_0_energy
shellies/shellyswitch25-007FC8/relay/energy:.* energy
shellies/shellyswitch25-007FC8/input/1:.* input_1
shellies/shellyswitch25-007FC8/input/0:.* input_0
shellies/shellyswitch25-007FC8/temperature:.* temperature
shellies/shellyswitch25-007FC8/overtemperature:.* overtemperature
shellies/shellyswitch25-007FC8/roller/0:open {{'state' => 'closing'}}
shellies/shellyswitch25-007FC8/roller/0:close {{'state' => 'opening'}}
shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-007FC8...mac.*, ? json2nameValue($EVENT) : undef }


Anbei auch nochmal Shelly 2.5 ip/status JSON:
{"wifi_sta":{"connected":true,"ssid":"HierSSID","ip":"192.168.20.34","rssi":-62},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"13:47","serial":1,"has_update":false,"mac":"2462AB007FC8","relays":[{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true},{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true}],"rollers":[{"state":"stop","power":0.00,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"open","current_pos":85,"calibrating":false,"positioning":true}],"meters":[{"power":0.00,"is_valid":true,"timestamp":1561556859,"counters":[0.000, 0.000, 0.000],"total":15},{"power":0.00,"is_valid":true,"timestamp":1561556859,"counters":[0.000, 0.000, 0.000],"total":11}],"temperature":74.61,"overtemperature":false,"update":{"status":"idle","has_update":false,"new_version":"20190531-075825/v1.5.0-hotfix2@022ec015","old_version":"20190531-075825/v1.5.0-hotfix2@022ec015"},"ram_total":49600,"ram_free":36712,"fs_size":233681,"fs_free":153612,"uptime":1879}


Anbei die Readinglist für Shelly RGBW 2 im Color Mode:
shellies/shellyrgbw2-66138D/online:.* online
shellies/shellyrgbw2-66138D/color/0/status:.* { json2nameValue($EVENT) }
shellies/shellyrgbw2-66138D/color/0:.* state
shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-66138D...mac.*, ? json2nameValue($EVENT) : undef }


Anbei auch nochmal RGBW2 ip/status JSON:
{"wifi_sta":{"connected":true,"ssid":"HierSSID","ip":"192.168.20.54","rssi":-90},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"13:31","serial":1,"has_update":false,"mac":"B4E62D661CD3","mode":"color","input":0,"lights":[{"ison":false,"mode":"color","red":72,"green":255,"blue":237,"white":0,"gain":100,"effect":0,"power":0.00,"overpower":false}],"meters":[{"power":0.00,"is_valid":true}],"update":{"status":"idle","has_update":false,"new_version":"20190531-080138/v1.5.0-hotfix2@022ec015","old_version":"20190531-080138/v1.5.0-hotfix2@022ec015"},"ram_total":50464,"ram_free":37776,"fs_size":233681,"fs_free":156122,"uptime":181046}

Und RGBW2 ip/color/0/status JSON:
{"ison":false,"mode":"color","red":72,"green":255,"blue":237,"white":0,"gain":100,"effect":0,"power":0.00,"overpower":false}

Also ist in allen Shellys das Template minimal an zu passen. Das sind aber wirklich nur Kleinigkeiten. Denke mal das machst du so @Beta-User. Aber schön das die Shelly Kollegen mal aufgeräumt haben :)




Zum Thema MiLight, melde ich mich ggf. mal so - Ist hier aber ja eh OT




Zitat- noch mehr der .*_on-setter da sein
Wo denn überall?

Gruß,
Kai
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 Juni 2019, 13:47:09
Hmm, dann also:

Die alten announce-Pfade fliegen wohl zeitnah überall raus... (? bitte "wehren", wenn das jemand anders haben will!)
Die regex für die neuen sollte schon passen (wen's im Detail interessiert: bitte im svn nachsehen; da steht auch, welche .*_on eingefügt wurden (sollten die letzten 2 oder 3 commits auf das file sein) :P ). Wenn ich da (regex) falsch liegen sollte: bitte zeitnah um Info...

Was das Format relay_0 usw. angeht: "Muß" ist vielleicht etwas stark formuliert, aber vielleicht macht das Sinn (nur ziemlich sicher nicht "gleich"):- Funktionieren wird das auch mit den seitherigen Reading-Namen (die neuen werden seit einiger Zeit durch autocreate anders erstellt als früher);- Ändere ich die jetzt, bekommen alle, die "nur" an den neuen "announces" interessiert sind, ihre "alten" Readingnamen nicht mehr befüllt, sondern die neuen... MaW: das wäre für diese Nutzergruppe ein "breaking change";
- Für alle, die ab jetzt (bzw. eigentlich seit längerem) in das Thema einsteigen, ist es grade anders rum: Da wurde bisher anders benannt, als autocreate das seit einiger Zeit macht, was bedeutet, dass ggf. deren ältere Daten besser verwertbar bleiben, wenn man's jetzt umstellt.
- Was relay_0_power etc. angeht, finde ich diese Benennung unschön (autocreate macht das aus guten Gränden (!) aber so...).

MaW.: hier wäre insgesamt die Frage, was gewünscht wird (ich habe die Dinger nicht, mir im Prinzip egal, ob wir da eben die autocreate-Benennung nehmen oder eine Kurzbezeichnung und damit das bisherige System beibehalten...)
Meine Tendenz: eigentlich finde ich die Kurzbezeichnungen ganz ok, und das Mittel attrTemplate ist zwischenzeitlich auch soweit geläufig, dass es von der Mehrheit als Teil der Ersteinrichtung genutzt werden dürfte. Damit hat man keine/wenig Inkonsistenzen (und wenn, ist derjenige "selber schuld"  :P ) => würde es einfach lassen, wie es (jetzt in den templates) ist!?


Bitte um zeitnahe Info und Argumente (außer: autocreate verfährt anders), wenn jemand das anders sieht...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 26 Juni 2019, 14:03:35
Hey Beta-User,

habe meinen Beitrag nochmal editiert und alles was ich bieten kann, rein geschoben.

Ich bin der Meinung, dass die autocreate Namen verwendet werden sollten. So ist es immer sauber und es fällt im Fehlerfall eher auf. Hinzu werden diese ja bei Inbetriebnahme direkt so auch angelegt (autocreate). Es ist für neue User aus meiner Sicht, einfacher zu verstehen. Warum einen Namen ändern der eigentlich alles sagt. Man weiß nicht wie sich Shelly entwickeln wird aber im schlimmsten Fall belegen wir mit einer kurz-Bezeichnung nur einen Slot und haben am Ende eine Wechselwirkung (dein liebstes Argument :-P).

Die Regex passt bei mir, für jeden Shelly (FW 1.5.0). Super das Ding :)

Zitatda steht auch, welche .*_on eingefügt wurden
Ist das wieder das Los, welches ich gezogen habe bezüglich der Seite des SVN? Ich suche hier alles zusammen und du kopierst, dass was du auf deinem Desktop hast, nicht eben hier rein... Wo ist der heulende Smilie :(

Für alle die ein aktuelles Template über einen alten Shelly bügeln (FW Version), macht das eh keinen Sinn. Ich würde wenn dann:
A: Gerät sauber neu anlegen
oder
B: In die Template Datei sehen und den benötigten Teil rauß kopieren.

Generell würde ich mir das immer vorher einmal ansehen. Es ändert sich fast täglich etwas und ich kann ja nicht immer alle Threads durch blättern.

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 Juni 2019, 14:31:09
Vorab mal Danke für deinen Eifer!

Was die jeweilige "Seite von svn" angeht: Woher willst du wissen, was ich auf meinem Desktop habe?!? Wenn ich Änderungen "von irgendwo" her bei irgendeinem FHEM-Ding nachvollziehen will, nutze ich häufig https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/. Da kommt man mit ein paar Klicks von fhem.de her hin und kann alles möglich an Änderungen nachsehen ;) .

Und weil es eigentlich so sein sollte, dass man neue template-Versionen "einfach so" über bereits mit diesem Mittel konfigurierte Devices anwenden können sollte, ändere ich da ungern was so grundlegendes wie die sich ergebenden Readingnamen. Als autocreate da geändert wurde, gab's schon mal Überlegungen, diese (neuen) Namen zu nutzen. Das Ergebnis war, dass die autocreate-Readings schlicht gelöscht wurden, damit sie niemanden mehr verwirren 8) .
Davor war - soweit ich mich entsinne -  die letzte grundlegende Änderung, die Kanäle binär zu mappen (ursprünglich war das, was über "0" kam auf "relay1" gemappt), und alle mehrkanaligen Devices haben auch eindeutige Readingnamen (nur eben kürzere), aus denen abzulesen ist, wozu sie gehören. Das Konsistenzargument scheint mir damit ein wenig schlagkräftiges zu sein.

Anders gesagt: Du bist seit mehreren Monaten der erste, der sich daran stört, dass autocreate und die templates hier nicht dasselbe tun.

Wenn jetzt mehrere kommen und sagen, dass sie das schon immer nicht gut fanden, denke ich ernsthaft über eine Änderung nach, ansonsten bewerte ich die weitere Ruhe als Zustimmung zu meiner Tendenz ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 26 Juni 2019, 15:17:02
Gucke auch oft ins svn... Ist einfach, das stimmt. Dachte du hättest es aufgrund der frische noch parat.

Was die Namen angeht...
... Hier melden sich sehr selten andere User zu Wort (mein empfinden). Viele werden vermutlich bei Neuinstallation oder Problemen nur hier rein sehen. Also mir soll es egal sein. Ich bin mittlerweile weit genug um mir nur die benötigten teile aus den templates zu ziehen oder eben an zu passen.
Ich finde es eben nicht sonderlich sinnvoll... Auf einer seite wird durch autocreate was erzeugt. Auf der anderen seite wieder gelöscht und durch anderes ersetzt. Nun kommen wegen updates oder sonst was, neue readings rein und man muss erst mal schauen wozu das passt. In den templates selber läuft an für sich alles. Aber so oder so wird der Punkt kommen, an dem leute auf neuerer FW und andere auf älterer FW unterwegs sind. Auch wenn mal was geändert wird und du zb die templates von der backe hast, muss der nächste erst mal wissen warum du das so wolltest. Ich mag vernünftige Namen - wie diese dann hier aussehen, ist mir an und für sich auch egal.

Obwohl ich selber schon viel mit dem templates machte, war ich verwundert und musste das erst mal nachvollziehen. Für mich Grund genug das im original zu belassen.

Ein User, der einfach nur die ein oder andere led zum leuchten bringen will, wird sicher nicht am template basteln oder aber sich dafür interessieren wie da was heißt (außer das gerät selber).

Sooooo...für heute leider wieder im Off. Genieß mal die sonnige Ruhe [emoji5]

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 Juni 2019, 15:38:17
...selbst wenn ich es parat gehabt hätte: Warum soll ich das hierher kopieren, ggf. was vergessen, dadurch weitere Rückfragen erzeugen usw...?

Den Eindruck, dass andere sich selten melden, mag ich nicht unbedingt teilen: Wer ein Anliegen hat (oder neue Vorschläge, Änderungswünsche...), der meldet sich schon hier und in den anderen Template-Thread. Dass es relativ ruhig ist, führe ich eher auf eine gewisse Konsolidierung des ganzen Themas zurück :) .

Wenn mal jemand die templates übernimmt, wird es sein wie bei jedem anderen Modul: Erst mal aufpassen, welche Auswirkungen jede Änderung ggf. hat. Das ist zwar hier nicht ganz so tragisch, wie wenn ein Modul FHEM komplett abschießt, aber wenn was nicht paßt, gibt's schon feedback. Unbeliebt macht man sich v.a. dadurch, dass man Dinge nicht rückwärtskompatibel hält. Wer das (noch) nicht weiß, wird es schnell lernen.

Was deine Vorgehensweise angeht: Kann man so machen, aber jedenfalls solange ich das mache, werde ich auch (im vertretbaren Rahmen) versuchen, Konsistenz über der Zeit zu gewährleisten, damit eben nicht jeder sich die Mühe machen muss, alles im einzelnen auszutesten... (Ist ja in Teilen auch Sinn der Übung, oder?)
Bisher ist es einigermaßen gelungen, "breaking updates" gering zu halten, und ich sehe keinen wirklichen Anlaß, warum sich das zukünftig ändern sollte (vielleicht in geringem Umfang wg. des Sprachsteuerungsthemas, aber das ist auch irgendwann "durch").

MaW: Du schaffst dir damit mAn. nur zusätzlichen (unnötigen) Aufwand...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 12 Juli 2019, 09:33:15
Hey - Bei dem Homebridgemapping hänge ich leider... An sich geht an/aus und Helligkeit. Leider bekomme ich das mit den Farben nicht hin. Hatte dazu einen Thread auf gemacht aber bisher, leider noch keine Lösung. Ist aber nicht vergessen, dass soll die Botschaft hier sein...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: DasQ am 12 Juli 2019, 09:40:41
angeblich soll das funktionieren.

ich bin aber auch an den farben gescheitert, die konnte ich zwar umstellen, aber bestimmte farben gehn garnicht, oder total falsch.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Juli 2019, 15:35:29
Es muss ja irgendwie gehen. Die normalen Mappings klappen ja auch. Naja ich habe so oder so nun erst mal Parookaville und danach habe ich ggf neue Ideen :)

Zur Info: Die Kollegen im Shelly Forum baten um eine kleine Anleitung zum einbinden der Shellys via MQTT an FHEM. Diese habe ich den Kollegen bereit gestellt. Ggf. ja auch für hier interessant....

https://www.shelly-support.eu/forum/index.php?thread/363-anleitung-shelly-mit-fhem-und-mqtt2/&postID=3311#post3311 (https://www.shelly-support.eu/forum/index.php?thread/363-anleitung-shelly-mit-fhem-und-mqtt2/&postID=3311#post3311)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Juli 2019, 15:53:17
[OT] Bin nicht glücklich, wenn die "Kollegen" "irgendwo" was haben wollen, und dann diverse Anleitungen "irgendwie" entstehen.
Hier ist z.B. ausschließlich MQTT2_SERVER als IO verwendet. Das geht zwar grundsätzlich, ist aber eben nicht die einzige Möglichkeit...
Weiter ist zumindest mir nicht klar, wie man "autocreate" aktiviert. Zur Klarstellung: Ich kenne zwei Stellen, die beide aktiv sein müssen, aber....:
- beim MQTT2_SERVER ist es per default aktiviert (worauf Rudi neulich berechtigterweise hingewiesen hat, was zur Streichung des Hinweises im Wiki führte, und das man auf zwei Arten "anschalten" kann...=> welche soll gelten?!?), und
- in der weiteren Anleitung ist nicht davon die Rede, dass man _zusätzlich_ ein TYPE=autocreate aktiv haben muß (was aber in der Standardinstallation auch an ist...). Das _könnte_ gemeint sein, aber klar ist das nicht...

Ergo: Mir (und ziemlich sicher einigen anderen auch) wäre lieber, wir würden Leute von extern darauf verweisen, wie die Doku in FHEM aufgebaut ist (https://wiki.fhem.de/wiki/Dokumentationsstruktur) und wo sie ggf. das finden, was sie suchen (z.B. "Praxisbeispiele" und die MQTT-Einführung).

Dann genügt die straffest -mögliche Kurzform, verbunden mit dem Hinweis, wo die full story zu finden ist. (Gerne mit den Hinweis, wie einfach die Dinge damit gehen, das freut mich ja durchaus 8) ...)

Wenn es da room for improvement gibt: Laßt wissen, keiner ist unfehlbar...
[/OT]
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Juli 2019, 17:25:21
Ohne ewig lang zu antworten...
... Viele user fangen wegen shelly an mit fhem. So wird es vermutlich bei allen mal eine HW gegeben haben, mit der man angefangen hat. Absichtlich ist die anleitung kurz und für Anfänger. Tiefer werde ich in Richtung mqtt dort auch nicht gehen. Ein FAQ zb würde sich dort eher auf shelly beziehen. Ich habe enorme probleme am Anfang gehabt, um am infos zu kommen. Ich denke die "start Infos" sollten leichter zugänglich sein. Wer will kann dann weiter in die tiefe ABER muss sich dann zwangsläufig hier melden usw.

Sieh es als fhem Promo :)
Sicherlich wird es auch noch einige gute Programmierer oder so anlocken.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Juli 2019, 17:36:02
Will das hier auch nicht zu sehr vertiefen...

Wer warum zu FHEM kommt, sei mal dahingestellt, aber der Hinweis war so zu verstehen, dass die Anleitung nicht _zu kurz_ ist, sondern _zu lang_ ;) . (Konkret und mindestens: Wirf' autocreate da ganz raus und mach einen Link in's FHEM-Wiki (Praxisbeispiele) dazu; entweder der Leser ist ein Einsteiger, dann werden beide autocreate-Einstellungen sowieso passen, oder er weiß, wo er weitere Infos findet).

Und anders als noch vor ein paar Monaten ist es heute auch nicht mehr besonders schwer, an Infos zu kommen (du hast dich ja dankenswerterweise mit ein paar sehr speziellen Dingen rumgeschlagen ;D , so dass es auf dieser Basis jetzt in der Tat kaum einfacher geht - vielleicht abgesehen von dem Shelly-Modul, das ich aber genausowenig kenne wie die Hardware selbst ::) ).

FHEM braucht man m.E. auch nicht zu promoten, das "verkauft sich von selbst" (an die, die bereit sind, etwas tiefer einzusteigen; für den Rest wird es immer "seltsam" bleiben, und das ist auch ok so).

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 16 Juli 2019, 18:00:16
Passe den Teil morgen an. Dann sollte sie dir zwar noch immer nicht zu 100% gefallen aber wissen ist KEINE hol schuld. Deinen Hinweis, nehme ich natürlich ernst und überlege mir mal was für die Zukunft. Sicherlich gibt es noch mehr Themen zu denen einen Anleitung gehört.

Ps: würde mir sowas für hier im Forum auch wünschen. Es gibt viele Wikis und Infos. Gute Anleitungen findet man aber meist zb auf der seite vom Kollegen winkler oder sonst wo. Hier gibt es einige aber meist sind die sehr schwer verständlich. Vllt kann ich ja für hier mal das eine oder andere für "einfache User" übersetzen. Das wäre doch was schönes :)

Edit: soeben im shelly Forum angepasst.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 29 Juli 2019, 08:51:04
Hey und guten Morgen,

im Zuge eines Shelly 2.5, genutzt für einen Dippel-Wippen-Schalter, habe ich das Template A_11a genutzt. Dieses ist ursprünglich für den Shelly 2. Dieser hat aber z.B. keine Messung für Strom usw. Hinzu mag ich es einheitlich, weswegen ich devStateIcon usw angepasst hatte.

devStateIcon (übernommen aus anderen Shelly Templates):
{my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"<div><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> Aktuell: $cons W / Temp.: $temp °C</div>"}

readingList (CH 1):
shellies/shellyswitch25-BA7797/relay/0:.* state
  shellies/shellyswitch25-BA7797/relay/0:.* relay_0
  shellies/shellyswitch25-BA7797/input/0:.* input_0
  shellies/shellyswitch25-BA7797/online:.* online
  shellies/shellyswitch25-BA7797/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-BA7797...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shellyswitch25-BA7797/relay/0/power:.* relay_0_power
  shellies/shellyswitch25-BA7797/relay/0/energy:.* relay_0_energy
  shellies/shellyswitch25-BA7797/temperature:.* temperature
  shellies/shellyswitch25-BA7797/overtemperature:.* overtemperature
  shellies/shellyswitch25-BA7797/longpush/0:.* longpush_0


readingList (CH 2):
shellies/shellyswitch25-BA7797/relay/1:.* state
  shellies/shellyswitch25-BA7797/relay/1:.* relay_1
  shellies/shellyswitch25-BA7797/input/1:.* input_1
  shellies/shellyswitch25-BA7797/online:.* online
  shellies/shellyswitch25-BA7797/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-BA7797...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shellyswitch25-BA7797/relay/1/power:.* relay_1_power
  shellies/shellyswitch25-BA7797/relay/1/energy:.* relay_1_energy
  shellies/shellyswitch25-BA7797/temperature:.* temperature
  shellies/shellyswitch25-BA7797/overtemperature:.* overtemperature
  shellies/shellyswitch25-BA7797/longpush/1:.* longpush_1



Anbei mal ein Bild...

Normal würde ich auch lieber ein Gerät haben, da es ein Doppel-Schalter ist. ABER das macht wierderum die Alexa Befehle komplizierter. Deswegen als Split....


@Beta-User: Ich habe immer mal wieder gesehen, dass man kleine Zahlen (wie bei einem iPhone) einblenden kann am devStateIcon. Meinst du, sowas würde bei den Shellys gehen, wenn eine neue FW vorhanden ist?
new_fw false
Ist das Reading wenn nichts da ist und true eben wenn was da ist. So das am Ende eine kleine 1 da wäre, wenn eine neue FW vorhanden ist. Das wäre echt praktisch :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 29 Juli 2019, 12:55:26
Hallo und Danke,

das kommt dann mit dem nächsten update und der Bitte zu testen.

Dazu dann auch ein "on-for-timer"-Backlog-Beispiel für Tasmota.

Was das mit der update-Anzeige angeht: geht, aber ich will's nicht bauen :P und würde dafür auch eher eine Readingsgroup verwenden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 29 Juli 2019, 13:14:45
Zitat von: Beta-User am 29 Juli 2019, 12:55:26
Hallo und Danke,

das kommt dann mit dem nächsten update und der Bitte zu testen.

...

Was das mit der update-Anzeige angeht: geht, aber ich will's nicht bauen :P und würde dafür auch eher eine Readingsgroup verwenden.

Kein Problem.. Mache ich gern...

Hast du einen Tipp wonach ich suchen muss wegen der Update Anzeige? Readinggroup wie zb für leere Batterien ist zwar einfach machbar aber bei weitem nicht so schön :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 29 Juli 2019, 13:28:00
Zitat von: 87insane am 29 Juli 2019, 13:14:45
Kein Problem.. Mache ich gern...

Hast du einen Tipp wonach ich suchen muss wegen der Update Anzeige? Readinggroup wie zb für leere Batterien ist zwar einfach machbar aber bei weitem nicht so schön :)
Perl-devStateIcon - da kannst du ja prüfen, ob das Reading den passenden Wert hat und dann statt "grünem Punkt" für online z.B. einen orangenen anzeigen?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 Juli 2019, 12:32:26
Hey zusammen,

ich habe nun heraus gefunden, das diese kleinen Icons mit den Zahlen, in FTUI eingepflegt wurden aber nicht in FHEM WEB.
Ist aber nicht schlimm, da man dies ja anders lösen kann.

@Beta-User: Ist zwar nur eine Mini-Anpassung aber würde gerne was vorschlagen. Danke für deine Vor-Arbeit ;)
@All: Am besten mal Eure Meinung dazu...

Im Bild unten sieht man einen Shelly der ein FW Update bekommen könnte (gelber Kreis). Bei klick darauf, wird der Update Prozess angestoßen (x_update). Wenn kein Update vorhanden ist, dann auch kein gelber Kreis (Im Bild wäre das der zweite Shelly der angezeigt wird - OHNE gelben Kreis). Über die Icon Wahl kann man streiten oder noch besser, Ideen nennen :)

Ich selber hab das nun bei allen Shellys in meinem FHEM aktiv.

Danke fürs lesen und bis dahin.

Anbei noch der neue Code:
{my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $fw = ReadingsVal($name,"new_fw","false") eq "true"?"10px-kreis-gelb":"";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $temp = ReadingsVal($name,"temperature","-100");; "<div><a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage($fw)."</a> <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> Aktuell: $cons W / Temp.: $temp °C</div>"}

PS: Ich habe andere Lampen Icons, die würden dann beim checkin vermutlich wieder auf die ON/OFF gedreht werden. Danke schonmal.


EDIT: Habe auch eine Variante mit nur einem Punkt aber allen Features gebaut. Diese prüft die new_fw und online readings und färbt den einzelnen Punkt grün, gelb oder rot.
Hier wird dann auch die Funktion des Punktes angepasst. Sollte z.B. der Shelly online sein und eine neue FW vorhanden sein, wird der Punkt gelb und man kann mit klick darauf, das Update der Firmware direkt anstoßen. Sollte kein Update da sein, wird weiterhin durch klicken auf den grünen Punkt das Web-IF aufgerufen. Also alles wie bei meinem Vorschlag, nur intelligent in einem Punkt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 06 August 2019, 19:45:13
Hallo zusammen,
ich habe heute ein paar Shelly 2.5 verbaut und das Template A_11b1a_shelly25_roller_invert_0 benutzt.
Hier wird bis zum ersten Eintreffen der Readings auch ein grüner Punkt angezeigt. Danach steht statt dessen nur "online".
Hat das vieleicht mit dem fehlenden Reading "http://ip" zu tun? Muss ich da noch etwas machen? Sorry ich Blicke das echt noch nicht ;)

Hier mal ein Beispiel der Readings. Ist bei allen Vieren gleich!

READINGS:
     2019-08-06 18:12:29   current         stop
     2019-08-06 18:12:29   energy          250
     2019-08-06 18:12:29   input0          0
     2019-08-06 18:12:29   input1          0
     2019-08-06 18:12:29   overtemperature 0
     2019-08-06 18:12:29   pct             100
     2019-08-06 18:12:29   power           0.00
     2019-08-06 18:12:29   roller_0_energy 250
     2019-08-06 18:12:29   roller_0_power  0.00
     2019-08-06 18:12:29   state           100
     2019-08-06 18:12:29   temperature     54.90


Firmware der Shellys ist aktuell.
Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 06 August 2019, 20:58:47
Starte die alle mal neu. Danach sollte es gehen. Das hat was mit announce zu tun.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 06 August 2019, 21:47:40
Danke!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 07 August 2019, 08:50:46
@Beta-User: Ich weiß du bist im Urlaub und wünsche Dir auch viel Spaß :)

Kannst du bei deiner Rückkehr ggf. eine Abfrage von announce beim aktivieren des Templates einbauen? Also ganz am Ende einmal DEVICE announce abfragen, bei allen Shellys. Damit würde der Neustart wegfallen, den z.B. der Kollege hier über meinem Post machen musste.

Danke!




Für alle die es interessiert, anbei devStateIcon für das "Ampel-System" bei Shellys.
Es wird auf folgendes geprüft:
online = true + new_fw true = gelb = bei klick wird das FW Update durchgeführt
online = false + new_fw false = rot = bei klick wird versucht das WEB-IF zu öffnen
online = true + new_fw false = grün = bei klick wird das WEB-IF geöffnet
online = false + new_fw true = rot = bei klick wird versucht das WEB-IF zu öffnen

Natürlich könnt ihr die Funktionen anpassen. Man könnte z.B. bei rot/offline eine Konsole öffnen und einen dauer-Ping laufen lassen. Oder oder oder... Hatte das nicht getan, da hier jeder auf anderen Systemen unterwegs ist. Ist als Anreiz gedacht und ich mag es nicht in den Shelly hinein zu müssen und direkt zu sehen da ist ein Update vorhanden und dann kann ich es auch noch direkt anklicken. Viel Spaß damit :)


{ my $amp = ReadingsVal($name,"online","false") eq "false" && ReadingsVal($name,"new_fw","false") eq "false" || ReadingsVal($name,"online","false") eq "false" && ReadingsVal($name,"new_fw","false") eq "true" ? "rot" : ReadingsVal($name,"online","false") eq "true" && ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $temp = ReadingsVal($name,"temperature","-100");; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C </div>" }
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 August 2019, 10:31:05
Da ich keine Hardware haben: Wie soll das mit dem announce genau gehen (sorry, webb das hier irgendwo schon mal dargestellt war, habe nicht gesucht)?
Optimal fände ich, wenn wir das recht neue "farewell"-feature nutzen könnten, also ein Dialogfeld anzeigen, mit dem man das optional abrufen kann. Dafür wäre vermutlich ein link für einen http-Request die einfachste Lösung, sonst muß man das IO und das passende topic ermitteln...




Was das "Ampel-System" angeht: wenn du es auf das notwendige Minimum reduzierst (das geht m.E. an mehreren Stellen kürzer) und nicht die "pending"-Lampe nimmst, bau ich's ggf. ein ;) ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: shootingstar am 31 August 2019, 12:21:46
Hallo in die Runde,

ich möchte einige der Shelly´s 2.5 als Rolladen Aktoren nutzen und stehe etwas auf dem Schlauch.
Die Einbindung in FHEM erfolgt über den internen MQTT Server, was auch problemlos funktioniert.
Ich möchte die Rolladen ebenfalls per Apple Homekit und Siri, als auch Alexa nutzen.
Mit Homekit über die seit Jahren funktionierende Homebridge gibt es keine Probleme.
Nur bei fhem-alexa habe ich das Problem, das die Shelly´s nur in der Alexa App erkannt werden, wenn diese das genericDevice Type ,,switch" haben. Wenn ich dieses auf ,,blind" setze, wenden die Shelly´s weder gefunden, noch sind sie bei einer nachträglichen Änderung anzusprechen.
Ich könnte ja mit ,,switch" als Wert leben, was auch funktioniert (Fahre Rolladen xxx auf 0 oder 100), aber dann will Homekit nicht mehr.
Die Shelly´s habe ich mit dem Template ,,A_11b1a_shelly25_roller_invert_0" parametriert.
Ich brauch da glaube ich mal einen kleinen Stoß in die richtige Richtung.
Gruß Andreas

Hier noch das List von einem der Devices:

IODev mymqtt
alexaName Rollladen Schlafzimmer links
alexaRoom Schlafzimmer
alias Rollladen Schlafzimmer links
cmdIcon open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
comment Shelly 2.5 in Roller-Mode. 100=opened / 0=closed
devStateIcon
opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0:fts_shutter_100 100:fts_shutter_10 9\d:fts_shutter_10 8\d:fts_shutter_20 7\d:fts_shutter_30 6\d:fts_shutter_40 5\d:fts_shutter_50 4\d:fts_shutter_60 3\d:fts_shutter_70 2\d:fts_shutter_80 1\d:fts_shutter_90 0\d:fts_shutter_100 set_.*:fts_shutter_updown
genericDeviceType switch
group Rolladen
model A_11b1a_shelly25_roller_invert_0
readingList shellies/shellyswitch25-00CC5F/roller/0/pos:.* pct
  shellies/shellyswitch25-00CC5F/status/0/rollers:.* power
  shellies/shellyswitch25-00CC5F/online:.* online
  shellies/shellyswitch25-00CC5F/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-00CC5F...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shellyswitch25-00CC5F/roller/0:.* current
  shellies/shellyswitch25-00CC5F/roller/0:open {{'state' => 'opening'}}
  shellies/shellyswitch25-00CC5F/roller/0:close {{'state' => 'closing'}}
  shellies/shellyswitch25-00CC5F/roller/0/pos:.* state
  shellies/shellyswitch25-00CC5F/input/1:.* input1
  shellies/shellyswitch25-00CC5F/input/0:.* input0
  shellies/shellyswitch25-00CC5F/relay/power:.* power
  shellies/shellyswitch25-00CC5F/relay/energy:.* energy
  shellies/shellyswitch25-00CC5F/temperature:.* temperature
  shellies/shellyswitch25-00CC5F/overtemperature:.* overtemperature
shellyswitch25_00CC5F:shellies/shellyswitch25-00CC5F/roller/0/power:.* roller_0_power
shellyswitch25_00CC5F:shellies/shellyswitch25-00CC5F/roller/0/energy:.* roller_0_energy
shellyswitch25_00CC5F:shellies/shellyswitch25-00CC5F/temperature_f:.* temperature_f
room Homekit,MQTT2_DEVICE
setList
open:noArg shellies/shellyswitch25-00CC5F/roller/0/command open
  close:noArg shellies/shellyswitch25-00CC5F/roller/0/command close
  half:noArg shellies/shellyswitch25-00CC5F/roller/0/command/pos 50
  stop:noArg shellies/shellyswitch25-00CC5F/roller/0/command stop
  pct:slider,0,1,100 shellies/shellyswitch25-00CC5F/roller/0/command/pos $EVTPART1
  x_recalibration:noArg shellies/shellyswitch25-00CC5F/roller/0/command rc
  x_update:noArg shellies/shellyswitch25-00CC5F/command update_fw
  x_mqttcom shellies/shellyswitch25-00CC5F/command $EVTPART1
setStateList open close half stop pct
siriName Jalousie Schlafzimmer links
stateFormat
<a href="http://ip" target="_blank">
online
</a>
state
webCmd :open:close:half:stop:pct
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 31 August 2019, 12:33:15
Hallo,

hast es mal mit genericDeviceType light versucht oder gar keiner Angabe des Attributes ?

Gruß

Thomas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 September 2019, 11:00:14
Lass das typedevice mal ganz Weng. Bei mir laufen die so auch ohne Probleme über Alexa. Steuern tust du dann über "Alexa Rollo Name 60%" zb.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 September 2019, 09:28:48
Guten Morgen zusammen,

anbei mal die kürzere Version zu dem "Ampel-Projekt" der Shellys.
{
my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;
my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';;
my $cons = ReadingsVal($name,"relay_0_power","unknown");;
my $temp = ReadingsVal($name,"temperature","-100");;
my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";;
"<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C </div>"
}


amp: Wertet den Zustand aus. Gibt es eine neue FW? Wenn ja = Kreis gelb und mit Klick wird das Update auf dem Shelly angestoßen. Wenn nein und Shelly ist online, ist der Kreis grün. Wenn offline, dann Kreis = rot.
light: Ist das Icon des Gerätes. Wird hier im Template vermutlich einfach die Standard Lampe. Aber so kann man das gut ändern bei der kleinen Zeile in devStateIcon.
cons: Aktueller Verbrauch in W
temp: Aktueller Temperaturwert des eingebauten Fühlers (wenn vorhanden). Bei einem Shelly 1 OHNE PM kann das natürlich weg.
show: Hängt zusammen mit amp. Je nachdem welche Farbe ausgewertet wurde, wird hiermit die Aktion beim klicken des Punktes eingestellt.
Der div Teil definiert das letztendliche Aussehen.

@all: Verbesserungen oder Ideen, bitte gerne melden :)
@Beta-User: Ist das für dich so besser? Kürzer bekomme ich das mit dem Funktionsumfang nicht.

Bilder habe ich hier keine angefügt. Sieht aber genauso aus, wie ich bereits ein paar Posts vorher gezeigt hatte. Nur der Code ist viel weniger.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 September 2019, 10:14:01
 :) Geht doch... ;D

Ein paar Zeichen lassen sich noch einsparen, aber man kann zugegebenermaßen darüber streiten, ob das vollends lohnt ;D ::) ;D :

{
my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;
my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';;
my $cons = ReadingsVal($name,"relay_0_power","unknown");;
my $temp = ReadingsVal($name,"temperature","-100");;
my $show = "<a href=\"";;$show .= $amp eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">";;$show .= FW_makeImage("10px-kreis-".$amp)."</a>";;
"<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C </div>"
}


Für's template würde ich dann noch die $light-Zeile so ändern:
my $light = ReadingsVal($name,"state","off");;
(Man kann das ReadingsVal auch in FW_makeImage direkt aufrufen, aber so läßt sich das leichter anpassen, wenn man UNBEDINGT diese Pendelleuchte (oder was anderes) haben will :P .

Bitte kurz (mit der "template"-Zeile) testen, bevor ich das einchecke...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 September 2019, 10:36:14
ZitatEin paar Zeichen lassen sich noch einsparen, aber man kann zugegebenermaßen darüber streiten, ob das vollends lohnt ;D ::) ;D :
Aus Interesse....was denn? :)

ZitatFür's template würde ich dann noch die $light-Zeile so ändern:
my $light = ReadingsVal($name,"state","off");;
(Man kann das ReadingsVal auch in FW_makeImage direkt aufrufen, aber so läßt sich das leichter anpassen, wenn man UNBEDINGT diese Pendelleuchte (oder was anderes) haben will :P .
Deswegen hatte ich das so gemacht ;) Ich weiß das du sie nicht nutzt aber bei x Geräten sieht das Auge so schneller :) Die Pendel-Leuchte ist auch immer nur wegen meines Test Schalters.

ZitatBitte kurz (mit der "template"-Zeile) testen, bevor ich das einchecke...
Kann ich von hier aus aktuell leider nicht. Wird also (wenn sich kein anderer dafür kurz meldet) etwas dauern...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 September 2019, 10:54:50
Zitat von: 87insane am 17 September 2019, 10:36:14
Aus Interesse....was denn? :)
Steht doch im meinem Post...

Statt
my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; steht da
my $show = "<a href=\"";;$show .= $amp eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">";;$show .= FW_makeImage("10px-kreis-".$amp)."</a>";;
Macht zwei Anführungszeichen und ca. 10 sonstige Zeichen weniger, bei mehr Codezeilen, die da "in einer" sind (damit man das besser von der Länge her vergleichen kann :P ).

(Ich sehe grade, man könnte auch das \"> noch nach hinten verlagern, aber kürzer wir es damit "leider" nicht mehr... ;D
my $show = "<a href=\"";;$show .= $amp eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1" : "http://".ReadingsVal($name,"ip","none")." \"target=\"_blank";;$show .= "\">".FW_makeImage("10px-kreis-".$amp)."</a>";;
Etwas kürzer geht aber doch noch 8) :
my $show = '<a href="';;$show .= $amp eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1" : "http://".ReadingsVal($name,"ip","none").' "target="_blank';;$show .= '">'.FW_makeImage("10px-kreis-".$amp)."</a>";;
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 September 2019, 10:57:19
Du machst mich fertig :-P muss ich mir am pc nachher mal ansehen. Freut mich aber das die Ampel nun eine Lebens Berechtigung bekommt :)

EDIT: Würde dann mit meinem testen. Finde das (wie du es immer schön sagst) besser als Beispiel für den Benutzer. Selbst das ist ja schon relativ komplex. Kann es aber, wie schon gesagt, leider erst recht spät in dieser Woche testen über das Template.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 September 2019, 16:59:07
Hey... Hatte das total vergessen. Aber die Shellys geben den Gesamt Verbrauch über MQTT NICHT in kW sondern Joule an!
1 Watt Minute = 0,017 Watt Stunden (Rechnung: 1 / 60). Das ganze noch durch 1.000 sind dann Kilo Watt Stunden.

Deswegen sind bei mir die Readings für relay_0_energy auch angepasst in der ReadingList.

Wer es auch haben will oder ggf Template, wenn es gut genug ist:
shellies/shelly1pm-005A2D/relay/0/energy:.* {'relay_0_energy' => sprintf("%.2f",$EVENT/60/1000)}
(natürlich muss der Name des Shelly angepasst werden, wenn das Beispiel kopiert wird)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 18 September 2019, 17:38:21
Bin noch am Zweifeln, ob man die Umrechnung gleich machen sollte oder erst beim stateFormat, tendiere aber zu gleich. Meinungen dazu?

Ansonsten würde ich das dann ggf. zusammen mit einem weiteren Gedanken von rebuehl - Zustand des angeschlossenen Geräts gleich mit anzeigen - einchecken, wenn das final getestet und für gut befunden wurde?

Bitte möglichst die "Ampel" so testen, wie ich sie dann einchecke ::) . Du darfst das dann gerne wieder so ändern, wie du das magst, aber ich kann das nicht selbst testen ohne Rückmeldung von der Hardware...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 September 2019, 17:43:12
Zuerst erzähle mir vom rebühl Zustand :) ich bin gespannt....!

Testen geht leider echt erst die Tage. An sich sollte das ja schnell gemacht sein, da nur die erste Zeile in devstateicon angepasst wurde. Alles andere ist gleich geblieben. Außer du willst eine deiner 35 Varianten :-P da müsstest du mir mal eben vorwerfen welche du getestet haben magst. Dann passiert das die Tage (vermutlich we).

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 21 September 2019, 15:31:31
....brauche noch deine Lieblings Variante...
Werde es Vermutlich morgen schaffen. Ach ja zu deiner idee wolltest du doch auch noch was sagen, oder? :)

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 September 2019, 16:19:23
So anbei mal getestet mit Ampel-System und Umrechnung von Gesamt Energie-Wert.
Getestet mit Shelly1pm.

Ich denke für die anderen Shelly kannst du das auch direkt einbauen. (Hinweis: Der normale Shelly1 hat KEINE Energie-Messung.)


name:TEST
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:Applies to single relay Shelly devices offering energy meassuring like Shelly 1PM or Shelly Plug S
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : undef }\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* {'relay_0_energy' => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/DEVNAME/longpush/0:.* longpush_0
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $temp = ReadingsVal($name,"temperature","-100");; my $show = "$onl" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$onl)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C</div>" }
attr DEVICE webCmd :
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE TEST



Danke!

Wie immer, wenn jemand Wünsche hat, einfach melden und mit basteln. Ich stecke ja selber auch schon zu tief hier drin :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 September 2019, 07:26:34
Moin,

wird etwas dauern, wenn ich die ganzen templates durchsehen muß, wo das jetzt (mit on/off... ::) ) im Detail wie sinnvollerweise hin muß.

Der user reibuehl hat für den Zustand des angeschlossenen Geräts noch folgendes beigesteuert;
shellies/shellyplug-s-123456/relay/0/power:.* { my $limit = 100;; my $compare = $EVTPART0<$limit ? "off":"on";; ReadingsVal($NAME,"loadState","on") eq $compare ? undef: {loadState => $compare} }Fände es gut, wenn wir das auch gleich mit verarbeiten könnten. Bekommt jemand das in den devStateIcon-Code mit rein als separates Icon?

Was die Energiemessung (mit Formel) angeht: Da fände ich es besser, wir würden das doppeln (also den originalen Wert belassen/zusätzlich reinkommen lassen und ein neues Reading für den kalkulierten Wert verwenden, z.B. relay_0_kwh? (Geht darum, dass jemand keine Irritationen bekommt, der heute eine andere Methode verwendet).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 26 September 2019, 07:50:00
Bei mir sind nur zwei Zeilen anders. Hab es aber komplett gepostet.

Nur devstateicon und readinglist die Umrechnung. Das doppeln macht Sinn, muss ja nicht separat getestet werden.

Die Fragestellung bezüglich des Power States vom Slave....
Für mich macht es wenig Sinn bei einer z.B. Lampe ein Zusatz Icon zu haben. Diese ist nur an wenn auch das Relay an ist.
Bei Geräten wie einer Waschmaschine macht es wiederum Sinn. Dort arbeite ich aber eh anders.


{ my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $pic = ReadingsVal($name,"running","") eq "true"?'scene_laundry_room_fem@green':'scene_laundry_room_fem';; my $text = ReadingsVal($name,"running","") eq "true"?"Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"power","")." W":'Standby';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." $text </div>" }


Hier ist das Relay des Shelly immer auf AN. Das Icon der Waschmaschine kann auch nicht geklickt werden, damit man nicht aus versehen dran kommt und die Waschmaschine unterbricht. Wenn nun ein von mir definierter Schwellwert (je nach Gerät) überschritten wird, geht running auf true. Dann wird das Icon grün und es stehen auch die Werte des Verbrauchers (slave) dort. In dem Reading was hier in ReadingList kommt, wird loadState auf on oder off gesetzt. Macht also das gleiche nur auf andere Art. Hier wird mit $limit, direkt in der ReadingList das erzeugt, was bei mir running ist. Mir fällt bis auf z.B. Pumpen, Waschmaschine, Trockner nichts ein wofür das überall drin sein sollte. An was habt ihr da gedacht?

Umgebaut auf das wie ich es nutzen würde wäre das:
shellies/shellyplug-s-040C7E/relay/0/power:.* { my $compare = $EVTPART0<ReadingsVal($NAME,"swerta","on") ? "false":"true";; ReadingsVal($NAME,"running","true") eq $compare ? undef: {running => $compare} }

Danke für die super Idee und gleichzeitige Problem-Lösung bei einem meiner Projekte!

Anbei mal ein Bild wie es aktuell bei mir ist und ggf. kann man dafür wiederrum bei Geräten, bei denen es Sinn macht ein fertiges Waschmaschinen oder Trockner Template bauen.




Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 September 2019, 10:06:07
Dachte schon, dass das dir gefällt ;D ;D ;D .

Jep, ist ein readingList-Auszug, hast du ja zwischenzeitlich gemerkt. Sollte funktionieren, geht nur noch um die Frage, wie man das grafisch sinnvoll darstellt.

MMn. wäre es wichtig zu wissen, an welcher Stelle der Kette das "off" ist, daher zwei Symbole? (Die Idee, das "vorne" nur schaltbar zu machen, wenn der Slave "off" ist, finde ich super!).
Vielleicht den Master als Steckdosensymbol (gab es mit an/aus, oder?) und den eigentlichen slave dann als "on/off" wie üblich? (cool wäre, das _optional_ über einen als userAttr hinterlegbaren Devicenamen on/off-schaltbar zu machen? Wenn da ein Devicename steht: Plug nicht schaltbar, wenn nicht: Einschalten über Plug erlauben?).

Da ich die Dinger nicht habe: Laßt eurer Phantasie etwas Raum, eventuell macht es Sinn, da zwei templates anzubieten, eines als "full-featured", das andere nur "basic"?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 26 September 2019, 10:25:34
ZitatMMn. wäre es wichtig zu wissen, an welcher Stelle der Kette das "off" ist, daher zwei Symbole? (Die Idee, das "vorne" nur schaltbar zu machen, wenn der Slave "off" ist, finde ich super!).
Bei mir ist das über das Icon garnicht schaltbar. Nur im Gerät selber. Der Stecker geht nach Stromverlust direkt wieder auf relay an und deswegen brauche ich keine Funktion hinter dem Icon. Im Gegenteil. Nachher komme ich aus versehen da drauf und schalte die Maschine aus.
Off ist dann, wenn der Schwellwert unterschritten wird. Hier habt ihr das mit $limit gelöst - ich eben mit einem Reading (swerta).


ZitatVielleicht den Master als Steckdosensymbol (gab es mit an/aus, oder?) und den eigentlichen slave dann als "on/off" wie üblich? (cool wäre, das _optional_ über einen als userAttr hinterlegbaren Devicenamen on/off-schaltbar zu machen? Wenn da ein Devicename steht: Plug nicht schaltbar, wenn nicht: Einschalten über Plug erlauben?
Das verstehe ich nicht. Wie sollte man das schalten, wenn es nur virtuell ist? Welchen Nutzen könnte das mit sich bringen? Oder ist das noch anders gemeint?

ZitatDa ich die Dinger nicht habe: Laßt eurer Phantasie etwas Raum, eventuell macht es Sinn, da zwei templates anzubieten, eines als "full-featured", das andere nur "basic"?
Hatte meinen Beitrag editiert. Schrieb ich auch schon. Das macht am meisten Sinn. Die Frage ist, ob man ggf. direkt ein Waschmaschinen oder Trockner Template macht. Ist eines der meist gefragten Themen und mit der Idee absolut einfach um zu setzen. Die Frage ist nur was am besten ist. Ich selber mache mir einfach selber Readings und nutze userReadings nur selten. Hinzu gibt es auch Geräte die haben zwei Schwellwerte. Also einmal nach dem einschalten und einmal nach dem Beendet des, z.B. Waschvorgangs. Gerade bei Trocknern hat man auch den Knitterschutz. Der brauch natürlich mehr Energie als wenn der Trockner wirklich im Idle ist.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 September 2019, 11:24:36
Zitat von: 87insane am 26 September 2019, 10:25:34
Bei mir ist das über das Icon garnicht schaltbar. Nur im Gerät selber.
Das macht in vielen Fällen absolut Sinn.

Es gibt aber Ausnahmen, da kann man eventuell beides schalten (vielleicht auch nur über einen unidirektionalen Befehl). Ich denke grade an eine Dunstabzugshaube, die via 433MHz-Signal geschaltet werden kann. Von der kenne ich den Status nicht ohne weiteres, kann sie aber auch von FHEM aus via Signalduino schalten (manchmal findet man Problemlösungen für Anwendungsfälle, die einem noch gar nicht bekannt waren 8) ; da muß wohl ein innr mal testweise umziehen ;D ; ist aber ein HUEDevice). Die Dunstabzugshaube ist also ein solches "virtuelles" Device.

ZitatDie Frage ist, ob man ggf. direkt ein Waschmaschinen oder Trockner Template macht. Ist eines der meist gefragten Themen und mit der Idee absolut einfach um zu setzen. Die Frage ist nur was am besten ist. Ich selber mache mir einfach selber Readings und nutze userReadings nur selten. Hinzu gibt es auch Geräte die haben zwei Schwellwerte. Also einmal nach dem einschalten und einmal nach dem Beendet des, z.B. Waschvorgangs. Gerade bei Trocknern hat man auch den Knitterschutz. Der brauch natürlich mehr Energie als wenn der Trockner wirklich im Idle ist.
Die Idee, templates nach zwei konkreten Anwendungsfällen zu benennen, finde ich gut, wäre klasse, wenn man das umgesetzt bekäme, ggf. auch mit mehreren Schwellwerten (ist aber vermutlich zu schwierig, da der Knitterschutz vermutlich nicht konstant eine Mindestleistung abfordert?).

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 26 September 2019, 12:40:54
ZitatEs gibt aber Ausnahmen, da kann man eventuell beides schalten (vielleicht auch nur über einen unidirektionalen Befehl). Ich denke grade an eine Dunstabzugshaube, die via 433MHz-Signal geschaltet werden kann. Von der kenne ich den Status nicht ohne weiteres, kann sie aber auch von FHEM aus via Signalduino schalten (manchmal findet man Problemlösungen für Anwendungsfälle, die einem noch gar nicht bekannt waren 8) ; da muß wohl ein innr mal testweise umziehen ;D ; ist aber ein HUEDevice). Die Dunstabzugshaube ist also ein solches "virtuelles" Device.
Verstehe das Beispiel nicht ganz ABER - Ich würde im Template das "nicht schalten" bevorzugen das ist schwieriger als das schalten. Ich musste das erstmal so umbiegen das es nicht klickbar ist in Konstellation mit den ganzen Icons usw. Könnte ich sogar schon komplett liefern....

ZitatDie Idee, templates nach zwei konkreten Anwendungsfällen zu benennen, finde ich gut, wäre klasse, wenn man das umgesetzt bekäme, ggf. auch mit mehreren Schwellwerten (ist aber vermutlich zu schwierig, da der Knitterschutz vermutlich nicht konstant eine Mindestleistung abfordert?).
Mit nur einem Wert geht das so wie es ist. Mit zwei Werten ist es etwas schwieriger und brauche ich aktuell auch nicht, da der Start-Schwellwert niedriger ist als der Schwellwert zum Ende hin. Da habe ich zumindest Glück gehabt. Beispiel Knitterschutz ist so gemeint:
Start: 40W und dann die ganze Zeit höher
Ende: Immer z.B. über 30W aber auch mal höher.
Also wäre man sonst unter 30 und somit die Maschine in der Theorie fertig. Nicht aber zwangsläufig, da der ganze Vorgang noch nicht beendet ist. Hoffe man versteht es so.

Ist eben sehr Geräteabhängig.

Die Fragen die ich nun habe, für ein sauberes Template:
Schwellwerte als Reading über setreading oder userReading oder direkt in ReadingList? Ich mache es selber über Readings die ich anlege (einmalig pro Gerät)
Icon gar nicht klickbar, für das Template, ok? (Ist wie oben schon gesagt, wohl einfacher, da man das ja auch einfach anpassen kann)
Wie in dem Bild zu sehen ist bei mir Standy = Relay an aber Slave aus. Wenn Slave an, wird auch gleich der aktuelle Verbrauch angezeigt.

Nachgelagert lasse ich mir via notify folgendes senden:
- Wie lange lief die Maschine
- Wie viel Watt hat sie verbraucht
- Was hat das ganze ca. gekostet (anhand meines Strompreises)

Lässt sich im Template ja nicht direkt mit einbauen, macht wenig Sinn in meinen Augen.
Man könnte aber z.B. über userReadings (so wie ich das auch habe) direkt einen Wert setzen für die Zeit und für den Verbauch + Kosten. Dann könnte ein User einfach diese Werte für sein notify nutzen, da ja alles schon da ist.

Das hier wäre dann ein Beispiel für die Berechnung für eine Runde waschen...Gleiches ginge für den Rest auch....
total_temp:running:.true { ReadingsNum("$name","total",0) },
gang:running:.false { ReadingsNum("$name","total",0) - ReadingsNum("$name","total_temp",0) }





EDIT:
Nach ein wenig überlegen würde ich das vermutlich so machen.....

1. Readinglist erweitern, wie von reibuehl beschrieben (leicht angepasst wegen meiner Umgebung):
shellies/shellyplug-s-040C7E/relay/0/power:.* { my $compare = $EVTPART0<ReadingsVal($NAME,"swerta",0) ? "false":"true";; ReadingsVal($NAME,"running","true") eq $compare ? undef: {running => $compare} }

2. userReadings setzen. Ich kenne das nur so, ggf. geht es besser?
total_temp:running:.true { ReadingsNum("$name","total",0) },
gang:running:.false { ReadingsNum("$name","total",0) - ReadingsNum("$name","total_temp",0) },
price:running:.false {sprintf("%.2f",ReadingsVal("$name","gang",0)*ReadingsVal($name,"spreis","true"))},
time:running:.false {strftime("%H:%M", localtime(ReadingsAge("$name","total_temp",0)-3600))}

Berechnet alles was man braucht. Zeit des Waschgangs, Kosten, Verbrauch in kWh.

3. devStateIcon setzen. Hier gehe ich davon aus, dass es NICHT klickbar sein soll und das wenn die Maschine im Standby ist, ist das Icon normal blau. Sollte die Maschine laufen, wird es grün und der aktuelle Verbrauch wird mit angezeigt. Das ganze reagiert in meiner Umgebung auf das Reading running.
{ my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $pic = ReadingsVal($name,"running","") eq "true"?'scene_laundry_room_fem@green':'scene_laundry_room_fem';; my $text = ReadingsVal($name,"running","") eq "true"?"Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"power","")." W":'Standby';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." $text </div>" }

So wären alle Daten für ein notify o.ä. im Gerät vorhanden.
Ich hätte am liebsten einen Bereich in dem man die variablen Daten (Schwellwert, Strompreis), direkt sieht und anpassen kann. Ggf. sowas wie ein set DEVICE Strompreis xxx oder set DEVICE Schwellwert xxx. Das wäre dann aber schon ein wirklich fertiges Script. Mehr fällt mir dazu nicht ein.

4. setList erweitern um:
  x_schwellwert {fhem("setreading MQTT2_shellyplug_s_040C7E swerta $EVTPART1");}
  x_strompreis {fhem("setreading MQTT2_shellyplug_s_040C7E spreis $EVTPART1");}


Das wäre für alle Shelly User (würde auch bei Tasmota u co gehen ;)) ein großer Gewinn. So könnte man in wenigen Sekunden haben, was mich Wochen gekostet hat. Allerdings konnte ich zu dem Zeitpunkt auch noch null FHEM.

Noch ein List, wie es sein könnte... Ich habe natürlich noch nicht gewaschen aber das wird so laufen. 100% kann ich das sagen nach dem nächsten mal waschen. Und es ist ein Beispiel, wie es bei mir aussieht. Ist natürlich leicht anpassbar. Ggf. sollten wir auch selbst erschaffene Readings "x_Reading" benamen. So weiß man direkt was wirklich vom Gerät kommt und was nicht.


Internals:
   CFGFN      ./FHEM/Tasmota.cfg
   CID        shellyplug_s_040C7E
   DEF        shellyplug_s_040C7E
   DEVICETOPIC MQTT2_shellyplug_s_040C7E
   FUUID      5d4c47d9-f33f-fcb4-c859-f484bf00612f2b75
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 16220
   MQTT2_FHEM_Server_TIME 2019-09-26 14:42:50
   MSGCNT     16220
   NAME       MQTT2_shellyplug_s_040C7E
   NR         173
   STATE      on
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-08-13 17:34:03   aname           Die Waschmaschine
     2019-09-25 16:13:03   fw_ver          20190821-095311/v1.5.2@4148d2b7
     2019-09-26 13:52:19   gang            0
     2019-09-25 16:13:03   id              shellyplug-s-040C7E
     2019-09-25 16:13:03   ip              192.168.xxx.xxx
     2019-09-26 09:45:46   loadState       off
     2019-09-25 16:13:03   mac             4C11AE040C7E
     2019-09-25 16:13:03   new_fw          false
     2019-09-25 16:13:03   online          true
     2019-09-26 14:42:50   overtemperature 0
     2019-09-26 14:42:49   power           0
     2019-09-26 13:52:19   price           0.00
     2019-09-26 14:42:49   relay0          on
     2019-09-26 13:52:19   running         false
     2019-09-26 14:24:29   spreis          0,29
     2019-09-26 14:42:49   state           on
     2019-09-26 14:31:51   swerta          4
     2019-09-26 14:42:49   temperature     28.37
     2019-09-26 14:42:49   temperature_f   83.07
     2019-09-26 14:42:49   total           6.90
     2019-09-26 13:51:52   total_temp      6.90
Attributes:
   IODev      MQTT2_FHEM_Server
   alias      Keller Waschmaschine
   devStateIcon { my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $pic = ReadingsVal($name,"running","") eq "true"?'scene_laundry_room_fem@green':'scene_laundry_room_fem';; my $text = ReadingsVal($name,"running","") eq "true"?"Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"power","")." W":'Standby';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." $text </div>" }
   event-on-change-reading .*
   genericDeviceType switch
   group      Strom
   model      A_10a_shellyplug
   readingList shellies/shellyplug-s-040C7E/relay/0:.* state
  shellies/shellyplug-s-040C7E/relay/0:.* relay0
  shellies/shellyplug-s-040C7E/input/0:.* input0
  shellies/shellyplug-s-040C7E/online:.* online
  shellies/shellyplug-s-040C7E/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-040C7E...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shellyplug-s-040C7E/relay/0/power:.* {'power' => $EVENT > 1 ? $EVENT : '0'}
  shellies/shellyplug-s-040C7E/temperature:.* temperature
  shellies/shellyplug-s-040C7E/overtemperature:.* overtemperature
  shellies/shellyplug-s-040C7E/relay/0/energy:.* {'total' => sprintf("%.2f",$EVENT/60/1000)}
  shellies/shellyplug-s-040C7E/temperature_f:.* temperature_f
  shellies/shellyplug-s-040C7E/relay/0/power:.* { my $compare = $EVTPART0<ReadingsVal($NAME,"swerta",0) ? "false":"true";; ReadingsVal($NAME,"running","true") eq $compare ? undef: {running => $compare} }
   room       FHEM / Info,Keller,MQTT
   setList    off:noArg shellies/shellyplug-s-040C7E/relay/0/command off
  on:noArg shellies/shellyplug-s-040C7E/relay/0/command on
  x_update:noArg shellies/shellyplug-s-040C7E/command update_fw
  x_mqttcom shellies/shellyplug-s-040C7E/command $EVTPART1
  x_schwellwert {fhem("setreading MQTT2_shellyplug_s_040C7E swerta $EVTPART1");}
  x_strompreis {fhem("setreading MQTT2_shellyplug_s_040C7E spreis $EVTPART1");}
   userReadings total_temp:running:.true { ReadingsNum("$name","total",0) },
gang:running:.false { ReadingsNum("$name","total",0) - ReadingsNum("$name","total_temp",0) },
price:running:.false {sprintf("%.2f",ReadingsVal("$name","gang",0)*ReadingsVal($name,"spreis",0))},
time:running:.false {strftime("%H:%M", localtime(ReadingsAge("$name","total_temp",0)-3600))}
   webCmd     :



Was sagt Ihr dazu?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 September 2019, 16:26:52
Boa, ganz schön viele Fragen...

Also:
- Klicken und optionales Schalten eines _anderen_ Devices fände ich klasse. Den zugehörigen Devicenamen bitte in ein userAttr.
- Den Wert für $limit gleich in die readingList zu schreiben, fände ich ausreichend. Aber auch hier wäre alternativ eventuell der Weg über ein userAttr etwas transparenter?
- Diese nachgelagertern Sachen finde ich ganz nett, bin aber noch unentschieden, ob wir das in ein template gießen sollten, oder ob es nicht im Wiki besser aufgehoben wäre; das macht ja jeder irgendwie anders (aber ein funktionierendes Beispiel ist auf alle Fälle ein Gewinn!). Aber wenn via template, würde ich dazu neigen, für die Preisgeschichte kein Reading am Device zu nehmen, sondern den Strompreis aus einem anderen Device (ausnahmsweise ein Dummy...!) holen, wobei ich dafür fix den Namen "Strompreis" nehmen würde, und einen halbwegs sinnvollen Wert als default-Wert in die ReadingsVal-Abfrage reinbauen? (Das hat den Vorteil, dass man es systemweit nur einmalig setzen müßte, was dann die Brücke zu Tasmota noch mehr vereinfachen könnte...)

Aber es dürfen gerne auch andere ihre Meinung dazu sagen; ich habe sowas derzeit selbst nicht im Einsatz, und werde nur das mit dem "Fremd-Slave-Device" schalten nur bei Gelegenheit mal in das devStateIcon des innr-HUEDevice-Dingens einbauen wollen (so die Funkstrecke da hinreicht, wo der Einsatzort wäre... Da gibt es aber weitere Problemchen: ist jetzt das Licht an, oder (auch, nur) der Ventilator?!? Auf welcher Stufe?).

Wie auch immer:

ZitatDas wäre für alle Shelly User (würde auch bei Tasmota u co gehen (https://forum.fhem.de/Smileys/default/wink.gif)) ein großer Gewinn. So könnte man in wenigen Sekunden haben, was mich Wochen gekostet hat. Allerdings konnte ich zu dem Zeitpunkt auch noch null FHEM.
Das ist genau das Ziel der template-Geschichte: Best practice sharen (oder was, was dem möglichst nahe kommt). Deswegen "nerve" ich manchmal auch ein wenig, wenn mir die Dinge noch nicht optimal vorkommen :P .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 26 September 2019, 17:59:11
Markiert mich wenn es weiter geht. Hab eine komplette (in meinen Augen) lösung angeboten. Ich danke für die Inspiration.

Was das globale Dummy Device angeht, kann das ja jeder machen wie er mag. Auf ein Template bezogen wäre das ein Beispiel, wenn man das nur dafür nutzt. Ich selber mache keine Jahres Verbrauchs-Werte oder so. Immer nur diese zwischenwerte um det dame des hauses zu sagen was es kostet wenn man sinnlos wäscht und trocknet :-P

Habe das bei mir nun auch so am laufen wie oben geschrieben.

Was das schalten angeht, komme ich da noch immer nicht mit. Das Beispiel mit 433mhz (vermutlich ohne Rück Kanal) ist für mich nicht nachvollziehbar. Bin froh das ich bis auf das Pool Thermometer nix mehr mit 433mhz habe.
Ich wüsste nicht was ich schalten soll im Bezug auf die Trockner / waschmaschinen Debatte.

Ps: dann tu es für mich :) kann ja zusätzlich ins Wiki. Aber ob man es daraus kopiert oder ob man das direkt anbietet. Dann doch lieber beides und im Wiki mit guter Beschreibung.

Bin gespannt wo wir landen :)

Ach ja EDIT:
Den ReadingsVal Wert vom Strompreis würde ich am besten total hoch setzen. So fällt ein fehlendes Reading bzw. ein Fehler eher auf. (Eine Idee, die sogar von dir ist ;))

Zitat- Den Wert für $limit gleich in die readingList zu schreiben, fände ich ausreichend. Aber auch hier wäre alternativ eventuell der Weg über ein userAttr etwas transparenter?
Hmmm... Hier finde ich sowohl deine Lösungen gut aber auch meine. Ich denke von der Systemlast her, würde sich vermutlich, soweit ich die Module im Überblick habe, nichts groß unterschiedlich sein. Hier wäre echt ne andere Meinung sehr gut! Weil laufen tuen die alle. Ich finde es bei meinem Vorschlag gut, dass der Benutzer direkt die Konfig dafür setzen kann. Im Ursprung würde ich hier auch direkt zu große oder viel zu kleine Werte schreiben. Die Readingnamen bei mir im Beispiel, sind mal eben hin geklatscht. So würde ich die auch nicht lassen. Hatte nur leider nicht so viel Zeit und habe schnell runter getippt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 27 September 2019, 13:45:43
Mahlzeit.

Habe eben mal eine Zwischenversion ins svn geschubst mit der kWh-Berechnung und dem loadState (mit $limit direkt, mit Absicht hier bei einer halbwegs realistischen Marke).

In die "extended version" muß ich mich auch erst mal noch eindenken, hatte aber noch ein paar andere Dinge, die ich sowieso ändern mußte, so habe ich das jetzt für den "basic" mal auf die Schnelle in dem Rutsch mit erledigt, dann haben andere Mitdiskutanten auch die Chance, mit einem "konsolidierten Stand" zu starten.

Das mit dem 433-er Gedöns ist mir auch nicht recht, aber da ist das halt von Hause aus so verbaut - discussion ends here, damit muß/kann ich leben (wie du bei dem Poolthermometer)...

Für Trockner/WM ist das klar, dass Schalten keinen Sinn macht, für eine Dunstabzugshaube ist eine Zwangstrennung vom Strom sogar in bestimmten Fällen Pflicht (aber nicht über das Web-Interface, sondern unabhängig davon) und für mich wäre es evtl hilfreich im Sinne von "alles aus" (das klappt nur leider nicht mit dem Zigbee-Ding, muß mir dafür was anderes überlegen...).
Von daher bin ich schon sehr geneigt, das WM/Trockner-Ding zu überarbeiten und mit aufzunehmen (das ist ja unbestritten eine gute Sache). Dauert aber eben, so ist mir die Konfiguration zu speziell, und ich würde hier für die Preisangabe tatsächlich die Dummy-Lösung gut finden (weil es dann für alle templates "auf einen Rutsch" im Wiki erklärt werden kann, ganz egal, ob shelly, zigbee2mqtt, tasmota...).
Muß mich dazu aber mal mit Perl-Funktionen zu addToUserAttrList auseinandersetzen (oder wie die Funktion auch immer heißt), ist nicht ganz trivial.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 September 2019, 16:33:17
Hey - hatte aufgrund einer Hochzeit verschwitzt zu antworten...

Hab mir die Templates der Shellys nochmal angesehen. Der Online-Status bzw. Firmware Update Button (gelber Kreis) geht bei allen. Bei mir habe ich diesen nur bei Split Geräten weg gelassen. Also nur im ersten Channel aktiv. Channel 2, 3... Bekommen bei mir nur grün oder aber rot.

shellies/DEVNAME/relay/0/power:.* { my $limit = 100;; my $compare = $EVTPART0<$limit ? "off":"on";; ReadingsVal($NAME,"loadState","on") eq $compare ? undef: {loadState => $compare} }\
Da du hier kein
x_schwellwert {fhem("setreading MQTT2_shellyplug_s_040C7E swerta $EVTPART1");}
oder so haben wolltest, würde ich aber auch die Definition von $limit weg lassen. Dann kann man es auch direkt hinter $EVTPART0 schreiben.

Wie aufwändig ist das eigentlich für FHEM bzw. die HW dahinter, einen durchgehenden loadState (wie es hier genannt wurde) zu überwachen? Immerhin überwacht die Geschichte bei jeder POWER Änderung. Gibt es für sowas eine Art Faust-Regel?

433Mhz - Ja leider... Aber das Ding ist nun auch kaputt und ich glaube ich bastel mal selber was. Hab mittlerweile genug HW-Schrott.

WM und Trockner... Ich lese hier, wie immer weiter mit und bin gespannt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 30 September 2019, 17:22:21
Dann mal willkommen zurück.

Was ich jetzt konkret in den Shelly-templates zum Online-Status tun soll, habe ich noch nicht so ganz verstanden. Im Moment müßtete es so sein, dass der jeweils nur im ersten Kanal angezeigt wird; wenn man den Status in allen Kanälen zeigen will, verstehe ich den Unterschied nicht, dann gleich "alles" (was ich aber eigentlich auch nicht sooo toll/schlicht too much finde; dann soll sich der user anders informieren lassen, wenn ein Device immer mal wieder ausfällt).
Aber wenn mehr sowas hinreichend deutlich zum Ausdruck bringen, dass sie sowas sinnvoll finden: von mir aus...

Dann habe ich das jetzt mal versucht zu konsolidieren (mit einem zentralen Strompreisdummy, es macht m.E. Sinn, so einen Wert zentral bereitzustellen; das kann übrigens auch ein readingsProxy sein), ist selbstredend nicht getestet ;D ::) :P :

name:shelly1_w_energy_meassuring_washer_example
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
order:A_10b1
desc:Example how to configure a single relay Shelly device offering energy meassuring like Shelly 1PM or Shelly Plug S to visualise the state of a machine behind the plug. Icons will not allow to turn the machine off.
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
set DEVICE attrTemplate shelly1_w_energy_meassuring
attr DEVICE devStateIcon { my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $pic = ReadingsVal($name,"loadState","") eq "on"?'scene_laundry_room_fem@green':'scene_laundry_room_fem';; my $text = ReadingsVal($name,"loadState","") eq "on"?"Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"power","")." W":'Standby';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show ".FW_makeImage($pic)." $text </div>" }
attr DEVICE userReadings total_temp:loadState:.on { ReadingsNum("$name","total",0) },gang:loadState:.off { ReadingsNum("$name","total",0) - ReadingsNum("$name","total_temp",0) },price:loadState:.off {sprintf("%.2f",ReadingsNum("$name","gang",1)*ReadingsNum("kWh_Price","state",0.30))},time:loadState:.off {strftime("%H:%M", localtime(ReadingsAge("$name","total_temp",0)-3600))}
attr DEVICE comment Adopt $limit in readingList to your needs to get appropriate loadState changes; using a seperate device named kWh_Price indicating actual energy price in state will lead to realistic price results.
attr DEVICE model shelly1_w_energy_meassuring_washer_example


Das mit $limit habe ich belassen, das ist m.E. für "Einsteiger" einfacher zu durchschauen, wenn es vorne steht und nicht irgendwo dazwischen; es gibt dann auch einen comment dazu im Basistemplate, das hatte noch gefehlt.

Was die Last durch den Vergleich angeht, glaube ich nicht, dass das eine größere Belastung ist, das sind ja nur wenige Anweisungen, und das "Überwachen" ist ja keine "loop", sondern geschieht Event-basiert. Werden schon nicht sooo viele Werte sein, die insgesamt so verarbeitet werden.

Feedback: gerne
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 September 2019, 17:26:43
Ne ne...missverstanden.

Ich brauche das nicht in allen channeln. So wie es ist, ist gut. Es fehlt nur noch überall die Farbe gelb der Ampel ;)

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 30 September 2019, 17:36:28
Also im template shelly1 das hier ergänzen, oder?
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; "<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>"}
(damit es an alle einkanaligen und den ersten Kanal per default vererbt wird)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 September 2019, 18:11:51
Das meinte ich...auf die Ampel bezogen (devstateicon). Das geht auch bei ALLEN shellys. Getestet hatte ich das mit einem 1pm. Aber die möglichkeit des FW Updates in der Form, haben alle.

Beitrag 467

Aktuell fehlt das noch ganz.

Gesendet von meinem LG-H850 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 01 Oktober 2019, 14:37:48
Habe eben ein update ins svn geschubst mit der "Ampel", dem loadState für den pm und dem Washer-Example. Wenn da jemand noch Verbesserungsbedarf sieht: her damit.

Kann nur sagen, dass das auf meiner Testinstallation (ohne Hardware) jeweils fehlerfrei durchlief, nicht aber, ob es auch jeweils passende und optisch ansprechende Ergebnisse liefert... ::)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 01 Oktober 2019, 16:05:19
Hey...gucken / testen geht erst am WE. Aber da ich ja gerade was die Optik angeht immer was habe, werde ich mich auch melden. Kann das dann auch direkt mit einem shelly testen.

Danke für deine Akzeptanz der Ampel gegenüber. Bin gespannt wie du sie genau übernommen hast. Aber sehe ich dann ja alles.

Ps: die Ampel geht bei allen Shelly's.

Gesendet von meinem LG-H850 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Magic01 am 10 Oktober 2019, 17:29:31
Hi,

ich habe das gerade mal versucht mit dem Washer Example zum laufen zu bekommen.
2 Anmerkungen schon mal:
a) Die Anmerkung mit dem Limit ist irreführend - es gibt kein $limit - da steht nur ein Wert den man ändern muss.
Habe lange gesucht bis ich gefunden habe was das sein soll.
b) In den User Readings wurde immer wieder ein Wert total abgefragt - total gibt es so nicht - muss das nicht relay_0_energy sein?

Ansonsten bin ich noch am testen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 10 Oktober 2019, 17:48:27
Schick mal ein list deines Gerätes. Limit ist in der tat eher schwellwert. Aus umgekehrter Sicht wäre das limit. Aber du hast es ja geschafft.

Du brauchst einen Strompreis Dummy. Ich selber fand das auch eher semi, da ich das lieber im Gerät eingebe. Aber das würde ich bei mehreren Geräten auch in einem dummy lösen. Habe nur zwei und deswegen ist mir das egal.

Was total angeht bin ich gespannt was du genau meinst. Das list wird es auflösen.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Magic01 am 10 Oktober 2019, 19:08:02
Hi,

gerne - also ich habe gerade noch mal einem device das template zugewiesen.
Raus kam das:


Internals:
   CID        shelly1pm-BA129A
   DEF        shelly1pm-BA129A
   DEVICETOPIC MQTT2_shelly1pm_BA129A
   FUUID      5d9a501e-f33f-06ad-c234-9c6763307952b990
   IODev      mqtt2Client
   LASTInputDev mqtt2Client
   MSGCNT     4408
   NAME       MQTT2_shelly1pm_BA129A
   NR         698
   STATE      on
   TYPE       MQTT2_DEVICE
   mqtt2Client_MSGCNT 4408
   mqtt2Client_TIME 2019-10-10 19:01:25
   Helper:
     DBLOG:
       command:
         DBLogging:
           TIME       1570726605.19086
           VALUE      announce
       fw_ver:
         DBLogging:
           TIME       1570726605.25411
           VALUE      20190821-095324/v1.5.2@4148d2b7
       id:
         DBLogging:
           TIME       1570726605.25411
           VALUE      shelly1pm-BA129A
       input0:
         DBLogging:
           TIME       1570726671.18166
           VALUE      0
       ip:
         DBLogging:
           TIME       1570726605.25411
           VALUE      10.0.0.41
       loadState:
         DBLogging:
           TIME       1570726680.03801
           VALUE      off
       mac:
         DBLogging:
           TIME       1570726605.25411
           VALUE      A4CF12BA129A
       new_fw:
         DBLogging:
           TIME       1570726605.25411
           VALUE      false
       online:
         DBLogging:
           TIME       1570726605.22177
           VALUE      true
       overtemperature:
         DBLogging:
           TIME       1570726671.34154
           VALUE      0
       price:
         DBLogging:
           TIME       1570726680.03801
           VALUE      0.00
       relay0:
         DBLogging:
           TIME       1570726671.14938
           VALUE      on
       relay_0_energy:
         DBLogging:
           TIME       1570726885.53332
           VALUE      21105
       relay_0_kWh:
         DBLogging:
           TIME       1570726885.53332
           VALUE      0.35
       relay_0_power:
         DBLogging:
           TIME       1570726885.50512
           VALUE      88.61
       state:
         DBLogging:
           TIME       1570726671.14938
           VALUE      on
       temperature:
         DBLogging:
           TIME       1570726671.27822
           VALUE      61.00
       temperature_f:
         DBLogging:
           TIME       1570726671.31159
           VALUE      141.80
       time:
         DBLogging:
           TIME       1570726680.03801
           VALUE      00:01
       total_temp:
         DBLogging:
           TIME       1570726581.13883
           VALUE      0
       wash:
         DBLogging:
           TIME       1570726680.03801
           VALUE      0
   OLDREADINGS:
   READINGS:
     2019-10-10 18:56:45   associatedWith  MQTT2_GeneralBridge
     2019-10-10 18:56:45   command         announce
     2019-10-10 18:56:45   fw_ver          20190821-095324/v1.5.2@4148d2b7
     2019-10-10 18:56:45   id              shelly1pm-BA129A
     2019-10-10 18:57:51   input0          0
     2019-10-10 18:56:45   ip              10.0.0.41
     2019-10-10 18:57:59   loadState       off
     2019-10-10 18:56:45   mac             A4CF12BA129A
     2019-10-10 18:56:45   new_fw          false
     2019-10-10 18:56:45   online          true
     2019-10-10 18:57:51   overtemperature 0
     2019-10-10 18:57:59   price           0.00
     2019-10-10 18:57:51   relay0          on
     2019-10-10 19:01:25   relay_0_energy  21105
     2019-10-10 19:01:25   relay_0_kWh     0.35
     2019-10-10 19:01:25   relay_0_power   88.61
     2019-10-10 18:57:51   state           on
     2019-10-10 18:57:51   temperature     61.00
     2019-10-10 18:57:51   temperature_f   141.80
     2019-10-10 18:57:59   time            00:01
     2019-10-10 18:56:21   total_temp      0
     2019-10-10 18:57:59   wash            0
Attributes:
   IODev      mqtt2Client
   alias      Spülmaschine
   comment    Adopt $limit in readingList to your needs to get appropriate loadState changes; using a seperate device named kWh_Price indicating actual energy price in state will lead to realistic price results.
   devStateIcon { my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $pic = ReadingsVal($name,"loadState","") eq "on"?'scene_laundry_room_fem@green':'scene_laundry_room_fem';; my $text = ReadingsVal($name,"loadState","") eq "on"?"Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"power","")." W":'Standby';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show ".FW_makeImage($pic)." $text </div>" }
   model      shelly1_w_energy_meassuring_washer_example
   readingList shellies/shelly1pm-BA129A/relay/0:.* state
  shellies/shelly1pm-BA129A/relay/0:.* relay0
  shellies/shelly1pm-BA129A/input/0:.* input0
  shellies/shelly1pm-BA129A/online:.* online
  shellies/announce:.* { $EVENT =~ m,..id...shelly1pm-BA129A...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shelly1pm-BA129A/announce:.* { json2nameValue($EVENT) }
  shellies/shelly1pm-BA129A/relay/0/power:.* relay_0_power
  shellies/shelly1pm-BA129A/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : undef }
  shellies/shelly1pm-BA129A/temperature:.* temperature
  shellies/shelly1pm-BA129A/overtemperature:.* overtemperature
  shellies/shelly1pm-BA129A/relay/0/energy:.* relay_0_energy
  shellies/shelly1pm-BA129A/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}
  shellies/shelly1pm-BA129A/longpush/0:.* longpush_0
shellies/shelly1pm-BA129A/temperature_f:.* temperature_f
shellies/shelly1pm-BA129A/command:.* command
   room       Kueche
   setList    relay0:on,off,toggle shellies/shelly1pm-BA129A/relay/0/command $EVTPART1
  off:noArg shellies/shelly1pm-BA129A/relay/0/command off
  on:noArg shellies/shelly1pm-BA129A/relay/0/command on
  x_update:noArg shellies/shelly1pm-BA129A/command update_fw
  x_mqttcom shellies/shelly1pm-BA129A/command $EVTPART1
   userReadings total_temp:loadState:.on { ReadingsNum("$name","total",0) },wash:loadState:.off { ReadingsNum("$name","total",0) - ReadingsNum("$name","total_temp",0) },price:loadState:.off {sprintf("%.2f",ReadingsNum("$name","wash",1)*ReadingsNum("kWh_Price","state",0.30))},time:loadState:.off {strftime("%H:%M", localtime(ReadingsAge("$name","total_temp",0)-3600))}


Also im devStateIcon gibt es: ReadingsVal($name,"power","") -> Power gibt es nicht - höchstens relay_0_power
In den userReadings steht  ReadingsNum("$name","total",0) } -> liest also den Wert total - auch den gibt es nicht.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 10 Oktober 2019, 19:29:39
Spontan fällt mir auf...
Mach mal bei dem 1pm erst das 1pm Template drauf. Danach dann das washer Template.

Die readings die dir fehlen sind umrechnungen usw. Die kommen mit dem 1pm Template zb. Habe aktuell nur mein handy und nicht zu 100% im Kopf was in welchem Template steht. Teste erst mal so..

Morgen schaue ich mir das am pc an. Kann auch sein das da readings durcheinander gekommen sind. Beta-User macht das was wir ihm mit teilen. Er hat dafür keine Hardware. Ich benenne gerne um und habe eine leicht andere Struktur. Ich hoffe nicht das ich den Test schalter nicht zurück gesetzt hatte aber das sehe ich dann ja nach deinem Test oder aber morgen, wenn ich nochmal teste.

Ach ja...dein Firmware stand ist aktuell?

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Guzzi-Charlie am 10 Oktober 2019, 19:34:26
Hi,
wenn man den Shelly im WEB-IF mit .../status aufruft, dann ist die Leistung [W] dort tatsächlich mit "power" und die Energie [kWh] mit "total" bezeichnet.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 10 Oktober 2019, 19:36:05
Nochmal ich...schreib mal in die userReadings anstelle von total -> relay_0_kWh

Dann sollte es passen. Zumindest am Handy sehe ich das so.

Nicht das die schon wieder was an den mqtt readings angepasst haben.

Edit: und wie du selber gesehen hast anstelle von Power eben relay_0_power im devstateicon. Die readings müssen natürlich überall passen. Ich selber teste wie gesagt morgen nochmal mit neuster FW. Du selber hast die Lösungen ja schon gefunden.

Gesendet von meinem LG-H850 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Magic01 am 10 Oktober 2019, 19:45:58
 

Beim Modell shelly1_w_energy_meassuring wird zwar in devStateIcon total definiert, aber nur als lokale Variable (my ...)

devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; 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 / Total: $total/ Temp: $temp °C</div>"}

Wenn ich ein anderes Template anwende, sind die alten Readings im übrigen auch wieder gelöscht ..

Ja, ich weiß, dass ich das total ersetzten muss - war ja die Anmerkung aus meinem Post hier etwas früher heute.

Ps: FW und Fhem sind uptodate.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 10 Oktober 2019, 20:00:36
Da du das alles ja gut nachvollziehen kannst, muss ich ja nix mehr testen. So brauche ich keinen neuen shelly Auspacken usw..

Poste doch einfach ein Beispiel in Form vom Template und teste das kurz. Dann kann Beta-User das direkt einchecken.

Hier kommen verschiedene Fakten zusammen. Verschiedene readings und auf unserer so wie shelly Seite Updates. Die änderungen hast du gefunden und darfst es gerne zuende bringen :)

Zudem kann man ggf $limit anders einbauen. Bei mir heist das einfach swert für schwellwert. Mir ist es am ende egal wie es heist. Ich selber habe eh auch andere readings und setter in der Wasch Maschine. Ist auch viel Geschmacks sache. Die templates sollen ja animieren und verständlich machen :) bei mir hatte das damals funktioniert

Bezüglich der Templates und dem "löschen" der readings. Ist normal. Zum testen kopiere ich mir sowas dann einfach aus der Template Datei heraus. Macht ja auch Sinn, weil sonst viel Müll nach dem x Template in einem Gerät stünde.

Danke für deine Unterstützung :)

Gesendet von meinem LG-H850 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Oktober 2019, 07:41:26
Habe eben (u.a.) ein update dazu ins svn geschoben, bitte um Rückmeldung, ob es jetzt tut wie erwartet...

(Und auch den überholten comment geändert; das mit "$limit" war zu lang für attrTemplate. Dazu gibt es den weiteren Hnweis, dass man für eine rein "lokale" Auswertung auch schlicht den default-Wert anpassen kann oder eine andere Info auswerten...
Ich finde es nicht gut, _eine_ Info, die sich zentral ändert, bei vielen Devices lokal vorzuhalten, sowas ist mMn nicht "best practice". Aber wer Argumente hat (außer: ich habe das aber bisher anders gemacht...), darf die gerne vortragen, sonst bitte ich schlicht um Stillschweigen :P ).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 11 Oktober 2019, 07:55:02
Super!

Ich glaube sogar fast das ich mit an dem Debakel schuld bin. Ich meine es waren nur zwei Readings und Magic01 hat dies zum Glück auch selber erkennen können.
Vermutlich habe ich bei den ganzen Updates iwas durcheinander gehauen. Lustig ist das bei mir (ohne manuell Umbenennung) die Readings immer noch so rein flattern (wie sie anscheinend nun falsch sind).

Danke für die Unterstützung @Magic01 und danke @Beta-User für das schnelle handeln. So habe ich ein To-Do weniger auf der Liste für das WE :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Oktober 2019, 08:24:13
 :)

Unter "Debakel" verstehe ich allerdings was anderes... Ist nur "unschön", wenn es nicht auf's erste Mal funktioniert, aber es sind "neue", nicht lebenswichtige Funktionen, da darf schon mal nachgearbeitet werden, oder?

(Viele der templates sind genau so entstanden: erste Versuche, einige Schleifen, "blöde" Rückfragen und letztendlich große Zufriedenheit bei den vielen, die das dann am Ende "einfach so" verwenden können :) . Daher nehme ich auch hin und wieder was "unfertiges" auf, wie jüngst das OpenMQTTGateway; wer Bluetooth-Tags hat (oder eine Xiaomi-BT-Waage) könnte das mal ausprobieren und Rückmeldung geben... Man nimmt dafür am einfachsten einen ESP32 für ca. 5 €; auch für _manche_ RF-Devices scheint das die einfachste Lösung zu sein).

Als Anregung: meine Testbitten sind ernst gemeint, das geht in der Regel völlig  gefahrlos mit einer Kopie... ;D
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 11 Oktober 2019, 08:50:56
Hey nochmal....

testen tue ich das selbstverständlich. Wenn aber zwischenzeitlich Änderungen eintreten oder aber mehrere Updates (wie nun mit Ampel, Washer usw.) kommen, kann mal was durcheinander geraten. Beim nächsten mal sollte ich eben nicht drei Sachen gleichzeitig machen. Ich gelobe Verbesserungen.

Anderes Thema...
Aktuell arbeite ich an einem Win MQTT Skript. Das ist auch erstmal fertig für meine Sache aber ich würde das aufbohren wollen. Ideen sammel ich noch. Das Forum dazu hattest du auch schon gesehen. Könnte ich dafür am Ende ggf. auch ein Template liefern? Bisher ist das noch nicht so wild, da ich noch nicht genug Ideen habe aber am Ende sollte es ggf. interessant werden für einige Personen. Gerade mit MQTT ist es (in meinen Augen) viel einfacher als über HTTP, Kommandos an FHEM zu senden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Oktober 2019, 08:57:44
Schon ok...

Wenn es was allgemeines ist, checke ich das gerne ein, ggf. auch "nur" mit einem Link z.B. in's Wiki, wo man dann weitere Infos findet (wg. der Auswertung werden vermutlich ein paar myUtils-Zeilen erforderlich werden, nehme ich an...). Details dann aber bitte in dem anderen Thread, das ist hier OT.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 11 Oktober 2019, 09:09:56
Welche Auswertung meinst du? (letzte Frage wegen OT)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Bartimaus am 17 Oktober 2019, 21:58:51
Guten Abend,

ich habe heute meine Shellys(1+2) auf MQTT2-Betrieb umgestellt. Funktioniert auch wunderbar.

Aber bei beiden Devices habe ich einen roten Punkt (online=false).
Ich habe die ensprechenden Templates Shelly1 bzw. Shelly2_Split gewählt.

hier mal ein List des Shelly1:

Internals:
   CFGFN     
   CHANGED   
   CID        shelly1_500683
   DEF        shelly1_500683
   DEVICETOPIC Licht.Garage
   FUUID      5da8619c-f33f-dcb4-55e3-117b6467e205d74c
   IODev      MQTT2_FHEM_Server
   LASTInputDev MeinMQTT2Client
   MQTT2_FHEM_Server_MSGCNT 1452
   MQTT2_FHEM_Server_TIME 2019-10-17 20:43:30
   MSGCNT     2902
   MeinMQTT2Client_MSGCNT 1450
   MeinMQTT2Client_TIME 2019-10-17 20:43:30
   NAME       Licht.Garage
   NR         256086
   STATE      off
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-10-17 20:43:07   input0          0
     2019-10-17 17:59:22   longpush_0      1
     2019-10-17 20:43:30   online          false
     2019-10-17 20:43:07   relay0          off
     2019-10-17 21:39:44   state           off
Attributes:
   IODev      MQTT2_FHEM_Server
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off");; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a>" }
   event-on-change-reading state
   model      shelly1
   readingList shellies/shelly1-500683/relay/0:.* state
  shellies/shelly1-500683/relay/0:.* relay0
  shellies/shelly1-500683/input/0:.* input0
  shellies/shelly1-500683/online:.* online
  shellies/shelly1-500683/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shelly1-500683...mac.*, ? json2nameValue($EVENT) : undef }
shelly1_500683:shellies/shelly1-500683/longpush/0:.* longpush_0
   room       Beleuchtung,Shelly
   setList    off:noArg shellies/shelly1-500683/relay/0/command off
  on:noArg shellies/shelly1-500683/relay/0/command on
  x_update:noArg shellies/shelly1-500683/command update_fw
  x_mqttcom shellies/shelly1-500683/command $EVTPART1


Was habe ich in der Config vergessen ? Alle Geräte sind innerhalb desselben Netzwerkes.


Edith: Fehler gefunden... (lag innerhalb der Einstellung im WebInterface)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 Oktober 2019, 13:09:51
Welche Einstellung meinst du?
Normal hätte ich direkt gesagt, starte die einmal neu oder mach ein announce.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: jo_wo am 18 Oktober 2019, 17:18:22
Hallo und vielen Dank für die tollen Templates.

Ich nutze seit dieser Woche erfolgreich das Template für ShellyPlug und Shelly 2.5.
Dabei ist mir aufgefallen, dass für ShellyPlug das Attribut devStateIcon nicht über das Template definiert wird.
Ist das so beabsichtigt? Oder könnte man das ergänzen?

LG
Jörg
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 Oktober 2019, 17:20:32
Das ist noch ein älteres Template. Ich vermute mal du würdest es gerne so haben wie die anderen?
Wenn ja, dann gebe ich mal den kleinen Hinweis, dass es fast 1zu1 übernehmbar wäre. Teste doch einfach mal ein wenig :)

Ach ja...danke :)

Ps: plug oder Plug s? Ich selber hab nur plug s, weswegen ich das dann eh nur da testen könnte

Gesendet von meinem LG-H850 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: jo_wo am 18 Oktober 2019, 17:44:06
Vielen Dank für das schnelle Feedback  :)
Ich habe PlugS im Einsatz und das shellyplug-Template genutzt.
Werde dann noch ein bisschen weiter forschen...  8)

LG
Jörg
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 Oktober 2019, 17:46:06
Eigentlich muss du nur überlegen was du willst. Meine plug s zb hängen an diversen Dingen. Lautsprecher, LED schläuche, Wasch Maschine usw. Deswgen kann ich das nicht so machen wie bei den anderen. Bzw würde es nicht wollen. Wie sehen deine wünsche aus?

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: jo_wo am 18 Oktober 2019, 17:51:17
Ich brauche eigentlich nur den Standard für on/off mit der zusätzlichen Info für online/offline/FW-Update über die Ampelfarben...

LG
Jörg
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 Oktober 2019, 17:58:23
Dann nimm einfsch das vom zb 1pm und pass das minimal an. Sollte 2min dauern

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: jo_wo am 18 Oktober 2019, 18:25:31
Ja, den Ansatz habe ich auch gewählt  :)
Hat zwar etwas länger gedauert als 2 Minuten - mein Editor wollte nicht so wie ich - aber jetzt scheint es zu funktionieren.

Vielen Dank für Deine Unterstützung!!!

LG
Jörg
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 Oktober 2019, 18:31:01
Kein Problem, immer wieder gern. Schick mal ein Bild wie du das wolltest und am besten auch ein list dabei.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: jo_wo am 18 Oktober 2019, 19:04:32
Anbei ein Foto wie es jetzt bei mir aussieht und das List von einem meiner PlugS:

Internals:
   CHANGED   
   CID        shellyplug_s_041528
   DEF        shellyplug_s_041528
   DEVICETOPIC MQTT2_Shelly_WT
   FUUID      5da88153-f33f-9862-e8f4-5448ddaa40a22c3b
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 757
   MQTT2_FHEM_Server_TIME 2019-10-18 18:44:14
   MSGCNT     757
   NAME       MQTT2_Shelly_WT
   NR         93
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-10-18 17:27:52   fw_ver          20190821-095311/v1.5.2@4148d2b7
     2019-10-18 17:27:52   id              shellyplug-s-041528
     2019-10-18 17:27:52   ip              192.168.178.233
     2019-10-18 17:27:52   mac             4C11AE041528
     2019-10-18 17:27:52   new_fw          false
     2019-10-18 18:43:53   online          false
     2019-10-18 18:41:53   overtemperature 0
     2019-10-18 18:42:16   relay0          off
     2019-10-18 16:05:55   relay_0_energy  7416
     2019-10-18 18:42:16   relay_0_power   0.00
     2019-10-18 18:42:16   state           off
     2019-10-18 18:41:53   temperature     31.32
     2019-10-18 18:41:53   temperature_f   88.38
Attributes:
   IODev      MQTT2_FHEM_Server
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off");; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a>" }
   event-on-change-reading state
   fhem_widget_command {"allowed_values": ["off","on"],"order":11, "alias": "WzInstarWT"}
   getList    power:noArg shellies/shellyplug-s-041528/relay/power power
   model      shellyplug
   readingList shellies/shellyplug-s-041528/relay/0:.* state
  shellies/shellyplug-s-041528/relay/0:.* relay0
  shellies/shellyplug-s-041528/input/0:.* input0
  shellies/shellyplug-s-041528/online:.* online
  shellies/shellyplug-s-041528/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-041528...mac.*, ? json2nameValue($EVENT) : undef }
shellyplug_s_041528:shellies/shellyplug-s-041528/relay/0/power:.* relay_0_power
shellyplug_s_041528:shellies/shellyplug-s-041528/temperature:.* temperature
shellyplug_s_041528:shellies/shellyplug-s-041528/temperature_f:.* temperature_f
shellyplug_s_041528:shellies/shellyplug-s-041528/overtemperature:.* overtemperature
shellyplug_s_041528:shellies/shellyplug-s-041528/relay/0/energy:.* relay_0_energy
   room       MQTT2_DEVICE,Wohnzimmer
   setList    off:noArg shellies/shellyplug-s-041528/relay/0/command off
  on:noArg shellies/shellyplug-s-041528/relay/0/command on
  x_update:noArg shellies/shellyplug-s-041528/command update_fw
  x_mqttcom shellies/shellyplug-s-041528/command $EVTPART1


Nochmal vielen Dank!

LG
Jörg
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 18 Oktober 2019, 19:15:43
Also Energie Werte und Temperatur wolltest du nicht..? Sieht gut aus. Danke für die Unterstützung.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: jo_wo am 18 Oktober 2019, 19:19:25
Ja genau.
Mir reicht in diesem Fall der Status vollkommen aus.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 23 Oktober 2019, 08:29:07
Anbei mal die technischen Daten der Shellys. Ich denke diese können bei der Template Entwicklung auch ganz interessant sein. Ggf. als Inspiration...

http://www.anf.de/shelly/modules02.htm (http://www.anf.de/shelly/modules02.htm)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Udomatic am 02 November 2019, 17:07:10
Hallo,

ich habe heute meinen dritten Shelly Plug S eingerichtet. MQTT habe ich aktiviert und den FHEM Server hinterlegt, wie bei den anderen beiden auch. Diese wurden auch automatisch in FHEM als MQTT_Device angelegt.

Der neue nun nicht. Jemand eine Idee? Hat sich seit dem Update etwas geändert?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 November 2019, 17:08:47
Werksreset und nochmal.
Ggf auch nur n IP dreher oder so.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Udomatic am 02 November 2019, 17:14:33
Zitat von: 87insane am 02 November 2019, 17:08:47
Werksreset und nochmal.
Ggf auch nur n IP dreher oder so.

Werksreset brachte keine Änderung.
Weil ich erstmal keine andere Idee hatte habe ich das Gerät nun per define als Shelly Device angelegt. Ich frage mich gerade warum ich MQTT dann überhaupt benötige, weil Leistungsmessung und Übertragung funktioniert ebenso??
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Bartimaus am 02 November 2019, 17:16:13
Weil über Mqtt2 auch Stati VOM Gerät übermittelt werden, also wenn Du am Gerät schaltest...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Udomatic am 02 November 2019, 17:22:55
Zitat von: Bartimaus am 02 November 2019, 17:16:13
Weil über Mqtt2 auch Stati VOM Gerät übermittelt werden, also wenn Du am Gerät schaltest...

Also per WLAN ging das eben auch. Hat nur etwas länger gedauert.

Warum auch immer, ist das Gerät plötzlich als MQTT_Device aufgetaucht. Hat etwa ne Stunde gedauert seit Inbetriebnahme. Bei den ersten beiden Shellys war das vlt. innerhalb einer Minute.

Bin gerade etwas verwirrt...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 November 2019, 17:35:05
Ggf. macht da auch mal ein FHEM Server neustart Sinn. Normal melden die Geräte sich direkt am MQTT Server an und werden angelegt. Ich hatte das auch einmal (hab über 30 Shelly). Allerdings war das ein IP dreher (bei mir).

MQTT ist am Ende ja nicht nur für Shelly. Warum du das brauchst? Naja du kannst ja selber wählen wie du deine Hardware ansteuerst. Allerdings bin ich ein absoluter MQTT Freund. Es ist einfach, schnell und zuverlässig. Ich nutze MQTT für so gut wie alles :)

Was genau bei dir nicht ging, lässt sich nicht so einfach nachvollziehen. Du hattest kein EventMonitor oder LOG mit gesendet. Auch deine FHEM MQTT Einstellungen sind unbekannt. Genau wie die Settings im Shelly. Wie du selber sagtest, es dauert normal nur wenige Sekunden bis ein Gerät erzeugt wird, nachdem man die Daten im Shelly eingegeben hat. Ich würde auch kein MQTT Gerät per define anlegen, wenn es sich selbst erzeugen kann. Meist kann man damit schon sehen, wenn man ggf. mal was falsch gemacht hat.

Naja -> Ende gut, alles gut :)

PS: Ich selber vergesse das gerne, aber das Template für den 1PM ist auch für den PlugS. Ich nehme lieber das, anstelle des normalen attr Template, des Shelly Plug (ohne S).


EDIT: Nochmal zum Verständnis.... MQTT macht mehr als nur Shelly. Ich weiß nicht wie du dein define genau gemacht hast, da es für Shelly aktuell mehrere Wege gibt. Wir haben das Shelly Modul und MQTT. Auch HTTP würde gehen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Udomatic am 02 November 2019, 17:55:08
Zitat von: 87insane am 02 November 2019, 17:35:05
Was genau bei dir nicht ging, lässt sich nicht so einfach nachvollziehen. Du hattest kein EventMonitor oder LOG mit gesendet. Auch deine FHEM MQTT Einstellungen sind unbekannt. Genau wie die Settings im Shelly. Wie du selber sagtest, es dauert normal nur wenige Sekunden bis ein Gerät erzeugt wird, nachdem man die Daten im Shelly eingegeben hat. Ich würde auch kein MQTT Gerät per define anlegen, wenn es sich selbst erzeugen kann. Meist kann man damit schon sehen, wenn man ggf. mal was falsch gemacht hat.

Naja -> Ende gut, alles gut :)

PS: Ich selber vergesse das gerne, aber das Template für den 1PM ist auch für den PlugS. Ich nehme lieber das, anstelle des normalen attr Template, des Shelly Plug (ohne S).


EDIT: Nochmal zum Verständnis.... MQTT macht mehr als nur Shelly. Ich weiß nicht wie du dein define genau gemacht hast, da es für Shelly aktuell mehrere Wege gibt. Wir haben das Shelly Modul und MQTT. Auch HTTP würde gehen.

Ich hatte den Event Monitor leider nicht mitlaufen und konnte deshalb nichts genaueres hier posten. Trotzdem Danke!

Das define habe ich auf Basis des Shelly Moduls angelegt: define <name> Shelly <IP Shelly>
Habe es jetzt aber gelöscht, weil ich nicht zweimal das gleiche Device in FHEM möchte.


Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 November 2019, 17:57:47
Dann hast du ja alles hin bekommen... Weiter so und viel Spaß damit :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: sledge am 04 November 2019, 19:40:58
Eine generelle Frage bei den ganzen devStateIcon-Vorschlägen: Ich denke, das möchte jeder gerne ein bisschen anders haben - insofern finde ich den Transfer in die Templates nicht so ganz glücklich.

Sollte man diese Vorschläge samt Bildmaterial nicht eher in einem entsprechenden Wiki-Artikel sammeln und das ausgelieferte Template diesbezüglich "schlicht" halten? Just an idea.

Meine Version des devStateIcon zB ist folgende:

{
  my $online=ReadingsVal($name,"online","false");
  my $fw=ReadingsVal($name,"new_fw","false");
  my $power=ReadingsVal($name, "state","off");
  if($online eq "false")
  {
       return ".*:message_socket_disabled\@red";
  }
  elsif($fw eq "true")
  {
       return ".*:message_socket_unknown\@orange";
  }
  else
  {
       if($power eq "on")
       {
           return ".*:message_socket_on2\@green";
       }
       else
       {
           return ".*:message_socket_off2\@grey";
       }
   }
}


Und @Beta-User bzgl. des Announce: Es ist in der Tat so, dass die Shelly seit einer der letzten Firmware-Updates recht sparsam sind mit den ersten Informationen - das "online" Reading zB kommt erst nach langer Zeit - dann verwirrt auch das ausgelieferte devStateIcon, da es auf "rot" steht, obwohl der Shelly klar ansteuerbar ist.

Vermutlich reicht ein set DEVICE x_mqtt_com announce am Ende der jeweiligen Templates, um die Shelly hier zu einer entsprechenden Antwort anzuregen.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 November 2019, 19:50:46
Zum zweiten Teil: announce reicht hier. Ist aber schon seit Anbeginn der shellys. Also hast du recht damit.

Zum ersten Teil: sehe es mittlerweile wie Beta-User. Das ist ne Inspiration. Also ein einheitliches aber inspirierendes Template für alle...
Aber deine Idee macht natürlich auch Sinn. Ggf sollten alle Ideen in einem Wiki landen. So hätte man direkt verschiedene Varianten. Allerdings wären das bis hier her dann drei verschiedene. Die meisten nutzen es wohl, wie es ist. Hatte auch gedacht es müssten viele verschiedene sein. Aber so groß ist der Andrang bisher nicht. Du hast geschrieben, dass dein devstateicon "einfacher" ist. Denke das ist genau so schlimm für einen normalen User wie das aktuelle :-P musste auch drei mal lesen.

Hier kurz Edit: du hast nicht "einfacher" geschrieben, ich hatte es nur falsch im Kopf. Sitze am handy und kann beim tippen, leider nicht nochmal nach lesen.

Die Wiki Idee würde ich soweit es mir möglich ist, unterstützen!

Gesendet von meinem LG-H850 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: sledge am 04 November 2019, 19:56:24
Zitat von: 87insane am 04 November 2019, 19:50:46
Zum zweiten Teil: announce reicht hier. Ist aber schon seit Anbeginn der shellys.

[....]
Du hast geschrieben, dass dein devstateicon "einfacher" ist. Denke das ist genau so schlimm für einen normalen User wie das aktuelle :-P musste auch drei mal lesen.

Die Wiki Idee würde ich soweit es mir möglich ist, unterstützen!
Einfacher - ja, True. Im Sinne von: Nur ein Icon. Keine Zusammengebauten Icons mit <...> usw ;-) Und als Anfang finde ich das FHEM-spezifische Lampen-Icon übrigens gar nicht so schlecht.

Und was die Wiki-Seite angeht: Klar. Ist die Überlegung, ob man die vorhandene Seite erweitert. Ich check' das mal ab.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 November 2019, 20:08:54
Die zusammen gebauten Icons bieten alles. Kleiner machen ist ja meist einfacher als größer. Ist aber natürlich Geschmacks Sache.

Ich persönlich denke, das Wiki ist der richtige weg.
War schon ein Kampf das so hin zu bekommen und so kann man direkt sehen was alles so geht. Auch die Abhängigkeiten waren zu anfang höchst interessant.

Bin aber generell für alles offen und gespannt wohin die reise geht.

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 November 2019, 20:42:12
Zitat von: sledge am 04 November 2019, 19:40:58
Eine generelle Frage bei den ganzen devStateIcon-Vorschlägen: Ich denke, das möchte jeder gerne ein bisschen anders haben - insofern finde ich den Transfer in die Templates nicht so ganz glücklich.
Hmm, eventuell wäre es eine Überlegung, die templates so zu ändern, dass zumindest bei vorhandenen devStateIcon-Attributen das bleibt, was da ist.

Nach meinem Eindruck waren die meisten bisher ganz froh mit dem, was ausgeliefert wurde, aber wenn es deutliche Nachfrage nach "weniger" gibt, mache ich auch das, mir letztlich egal...

(Mein Ziel bei der Mitarbeit an den attrTemplate-files war es übrigens u.A. _auch_, zu zeigen, was alles möglich ist, und da hat sich einiges bewegt, so dass es letztlich heute eher eine Frage der Praktikabilität ist, wo man was unterbringt...
Es sollte halt einheitlich sein, so dass die, die den Standard nutzen, nicht dauernd nacharbeiten müssen.
ZitatSollte man diese Vorschläge samt Bildmaterial nicht eher in einem entsprechenden Wiki-Artikel sammeln und das ausgelieferte Template diesbezüglich "schlicht" halten? Just an idea.
Gerne dürft ihr den Artikel erweitern (paßt am ehesten doch direkt zu devStateIcon, oder?).

Würde nur dazu tendieren, vorneweg die Grundzüge mit _wenigen_ Beispielen zu erläutern und dann "hinten" weitere konkrete Beispiele zu nennen, wobei ausdrücklich erwähnt sei, dass die in der Einleitung vorhandenen Beispiele "verbesserungsfähig" sind...

Wäre super, wenn sich da jemand kümmern könnte/möchte!

ZitatVermutlich reicht ein set DEVICE x_mqtt_com announce am Ende der jeweiligen Templates, um die Shelly hier zu einer entsprechenden Antwort anzuregen.
Schau ich mir an, guter Vorschlag! (nur evtl. etwas Aufwand)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 November 2019, 20:57:39
x_mqtt_com gibt es zum Zeitpunkt des Templates ja nicht wirklich. Erst ganz am ende und da könnte es zu schnell rein laufen...(oder?).

Reicht doch dann einfach ein announce gegen alles zu pushen oder wie bei den tasmota's zb
set IO_DEV publish announce

Gesendet von meinem LG-H850 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 November 2019, 22:00:51
Du machst dir Sorgen...
FHEM läuft streng sequentiell ab, unmittelbar, nachdem man setList gesetzt hast, kann man es verwenden. Ist einfacher, als das IO zu ermitteln, das fällt ja schließlich auch nicht vom Himmel ;) .

Kommt übrigens morgen mit dem update ;D
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: sledge am 05 November 2019, 08:50:24
Zitat von: Beta-User am 04 November 2019, 20:42:12
[...]
Es sollte halt einheitlich sein, so dass die, die den Standard nutzen, nicht dauernd nacharbeiten müssen.Gerne dürft ihr den Artikel erweitern (paßt am ehesten doch direkt zu devStateIcon, oder?).

Würde nur dazu tendieren, vorneweg die Grundzüge mit _wenigen_ Beispielen zu erläutern und dann "hinten" weitere konkrete Beispiele zu nennen, wobei ausdrücklich erwähnt sei, dass die in der Einleitung vorhandenen Beispiele "verbesserungsfähig" sind...

Wäre super, wenn sich da jemand kümmern könnte/möchte!
Yep - hatte mir gestern Abend angeschaut, wer da "hauptamtlich" unterwegs ist bei devStateIcon - ich gehe die Sache mal an. Derzeit fehlend ist auch die Beschreibung der kombinierten devStateIcon-Konfiguration, die seinerzeit von André (justme1968) ermöglicht wurde.

Und ja: Vorne die Grundlogik von devStateIcon, bevor man hinten verschiedene Beispiele erläutert, zB das von Yeelight oder eben hier von Shelly.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 November 2019, 09:55:23
Na ja, es ist ein kurzes (schlecht erläutertes) Beispiel für Andre's Multi-Icon-Variante drin, aber wie gesagt: verbesserungsfähig; auch die Erläuterungen von Andre selbst im Forum-Link sind eher sehr knapp...

Danke jedenfalls schon mal vorab für's Kümmern!

In dem Zusammenhang:
- TomLee hatte hier (https://forum.fhem.de/index.php/topic,104858.0.html) den afaik fortgeschrittensten devStateIcon-Darstellungs-Code entwickelt, den ich bisher (als Attributinhalt) gesehen habe;
- Parallel kannst du eventuell ein Auge auf "Device Overview anpassen" werfen. Als Merkposten für den "rechten Teil" (die setter) ist eventuell noch https://forum.fhem.de/index.php/topic,104863.msg989807.html#msg989807 interessant (auch wegen des Zusammenwirkens der verschiedenen programmiertechnischen Ebenen).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 05 November 2019, 10:37:05
@sledge: Wenn ich dich irgendwie unterstützen kann, einfach melden :) Schön das du dich hier gemeldet hast.

@Beta-User: Habe ich noch Aufgaben hier offen, die mir unter gingen? / MQTT am WIN PC habe ich noch auf dem Schirm, ist aber hier eh OT.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 November 2019, 10:44:33
Zitat von: 87insane am 05 November 2019, 10:37:05
Habe ich noch Aufgaben hier offen, die mir unter gingen? / MQTT am WIN PC habe ich noch auf dem Schirm, ist aber hier eh OT.
Mir wäre grade nichts in Erinnerung, ich bin aber vergesslich ;D .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 November 2019, 13:42:35
Jetzt ist doch was offen, was shelly-templates angeht: allg. Frage zu brightness/pct hier:

https://forum.fhem.de/index.php/topic,94494.msg996478.html#msg996478
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: reibuehl am 05 Januar 2020, 16:15:13
Hallo,

wie bekomme ich den die Shelly attrTemplates in mein FHEM? Über ein FHEM update all habe ich zwar ein paar neue attrTemplate einträge dazu bekommen aber der Shelly 2.5 den ich habe taucht da nicht auf. Muss ich da eine neue Update Source einbinden?

Gruß,
Reiner
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Januar 2020, 16:23:02
Die templates werden über den regulären FHEM-svn-update-Mechanismus verteilt, mehr als ein update sollte also nicht erforderlich sein.

Bekommst du shelly25_split?

(Sonst bitte mal die file durchscannen).

Es kann auch sein, dass da ein Filter zuschlägt (hier: filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*) => wenn es keinen readingList-Eintrag gibt, ist es nicht in der Auswahlliste zu finden...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: reibuehl am 05 Januar 2020, 16:33:45
In /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template habe ich den shelly25_split Abschnitt aber in der Auswahl des neu angelegten MQTT" Devices taucht er nicht auf.

Muss ich nach dem define erst ein bestimmtes Attribut setzen, damit der Filter das richtige Template anzeigt?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 05 Januar 2020, 16:34:43
Hast du den shelly via autocreate rein laufen lassen? Bitte löschen das Gerät und lege es so neu an.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: reibuehl am 05 Januar 2020, 16:39:03
Zitat von: 87insane am 05 Januar 2020, 16:34:43
Hast du den shelly via autocreate rein laufen lassen? Bitte löschen das Gerät und lege es so neu an.

Ich verwende Mosquitto und MQTT2_Client, daher gibts kein Autocreate.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Januar 2020, 16:41:47
Er schreibt ja, dass er ein define gemacht hat, das klingt nicht nach autocreate...

Ohne passenden readingList-Eintrag funktionieren die meisten Templates nicht ohne weiteres, du kannst aber das "set ... attrTemplate xyz" durchaus absetzen, mußt dann aber die abgefragten Parameter manuell setzen. Das ist hier nur "DEVNAME", also der Name, den du dem shelly gegeben hast => kein Hexenwerk.

Man kann auch mit MQTT2_CLIENT durchaus autocreate verwenden, das ist nur aus guten Gründen erst mal deaktiviert. Im Wiki zu MQTT2_CLIENT ist erläutert, was man dann machen sollte (nämlich ein "Sortierdevice" einrichten). Ist halt insgesamt deutlich unübersichtlicher als mit SERVER, aber geht auch...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: reibuehl am 05 Januar 2020, 16:58:28
Prima! Mit dem set attrTemplate shelly25_split auf der Kommandozeile hat es geklappt... bis auf das es für den Kanal 1 kein setList angelegt hat, aber das konnte ich vom Kanal 2 übernehmen.

Ist der rote Punkt im stateIcon eine Nebenwirkung des Setups mit Mosquitto? 
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 05 Januar 2020, 17:05:07
Mach mal einen Neustart des shelly oder sende eine Annonce. Dann sollte er grün werden.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Januar 2020, 17:12:01
Was das mit Kanal 1 angeht: hat vermutlich mit der Schachtelung der attrTemplates zu tun, da wird intern dann ein weiteres attrTemplate aufgerufen, das (wohl aus demselben Grund) nicht aufgelöst werden kann.

In diesen Fällen hilft es evtl., erst das jeweilige "Basistemplate" aufzurufen, damit es eine passende readingList gibt (hier: shelly1). Kann aber auch schlicht an der Reihenfolge mancher Anweisungen im template liegen (hab's vorsorglich gedreht).

Generell würde ich empfehlen, das mit autocreate an CLIENT mal anzusehen, wie gesagt, das geht schon...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: reibuehl am 05 Januar 2020, 19:12:54
Danke für die Hilfe! Jetzt läuft alles wie es soll. Das mit dem autocreate werde ich mir mal im Wiki ansehen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ingohz am 19 Januar 2020, 12:11:48
Moin,

gestern habe ich nach mehreren Shelly 1, 2.5 und RGBW2 noch 2 Shelly Dimmer mit MQTT2 unter fhem in Betrieb genommen. Funktionieren in fhem einwandfrei. Auch die Steuerung über HomeKit (Anbindung über Homebridge) incl. Siri läuft, nur die Zustandsanzeige des Geräts stimmt hier nicht. Der Dimmer wird im HomeKit immer als ON angezeigt - egal ob ein- oder ausgeschaltet. Bei anderen Shellies, auch dem RGBW2, funktioniert die Anzeige im HomeKit korrekt. Ist das ein bekannter Fehler bzw. wo muss ich suchen?

Vielen Dank und einen schönen Sonntag
Ingo
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 20 Januar 2020, 10:37:24
Zitat von: ingohz am 19 Januar 2020, 12:11:48
Ist das ein bekannter Fehler bzw. wo muss ich suchen?
Bisher hat sich keiner beschwert, aber ich habe einen "Verdacht", nur eben keine Hardware, um das vergleichen zu können...

Ist in dem JSON-Blob, den der dimmer sendet, irgendwas drin, was man sinnvollerweise nach "state" mappen kann, insbesondere: hast du ein "status"-Reading? Wenn ja, bitte die jsonMap um (z.B.) "status:state" erweitern.

Ansonsten: Wärst du so nett und würdest je eine RAW-Definition von beiden Typen (RGBW2 und dimmer) hier einstellen und ggf. versuchen rauszufinden, wie der JSON-Blob vom dimmer aussieht?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ingohz am 20 Januar 2020, 12:59:39
Hier erstmal das Listing vom Shelly Dimmer (ausgeschaltet und letzter Dimmwert 50%):


Internals:
   CID        shellydimmer_334455
   DEF        shellydimmer_334455
   DEVICETOPIC MQTT2_shellydimmer_334455
   FUUID      5e1f564a-f33f-add3-4655-c6857f89c29a2509
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 26149
   MQTT2_FHEM_Server_TIME 2020-01-20 12:09:50
   MSGCNT     26149
   NAME       MQTT2_shellydimmer_334455
   NR         164
   STATE      off
   TYPE       MQTT2_DEVICE
   JSONMAP:
     brightness pct
   READINGS:
     2020-01-15 19:16:48   brightness      50
     2020-01-19 11:57:18   fw_ver          20191216-090622/v1.5.7@c30657ba
     2020-01-19 11:57:18   id              shellydimmer-334455
     2020-01-18 19:14:24   input_0         0
     2020-01-19 11:57:18   ip              xxx.xxx.xxx.xxx
     2020-01-20 12:09:50   ison            false
     2020-01-20 12:09:50   light_0         off
     2020-01-20 12:09:50   light_0_energy  598
     2020-01-20 12:09:50   light_0_power   0.00
     2020-01-20 12:09:50   loaderror       0
     2020-01-19 11:57:18   mac             CC50E3334455
     2020-01-20 12:09:50   mode            white
     2020-01-19 11:57:18   new_fw          false
     2020-01-19 11:57:18   online          true
     2020-01-20 12:09:50   overload        0
     2020-01-20 12:09:50   overtemperature 0
     2020-01-20 12:09:50   pct             50
     2020-01-18 18:00:18   state           off
     2020-01-20 12:09:50   temperature     46.32
     2020-01-20 12:09:50   temperature_f   115.37
Attributes:
   IODev      MQTT2_FHEM_Server
   alias      EG_Wohnzimmer_Deckenlampe
   devStateIcon {my $lderr = ReadingsVal($name,"loaderror","true") eq "true"?"10px-kreis-rot":"10px-kreis-gruen";; my $light = ReadingsVal($name,"ison","false") eq "true"?"on":"off";; my $cons = ReadingsVal($name,"light_0_power","unknown");; FW_makeImage($lderr)."<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Leistung: $cons</div>"}
   group      Lampen
   icon       light_control
   jsonMap    brightness:pct
   model      shellydimmer
   readingList shellies/shellydimmer-334455/light/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}
  shellies/shellydimmer-334455/temperature:.* temperature
  shellies/shellydimmer-334455/temperature_f:.* temperature_f
  shellies/shellydimmer-334455/overtemperature:.* overtemperature
  shellies/shellydimmer-334455/overload:.* overload
  shellies/shellydimmer-334455/loaderror:.* loaderror
  shellies/announce:.* { $EVENT =~ m,..id...shellydimmer-334455...mac.*, ? json2nameValue($EVENT) : undef }
shellydimmer_334455:shellies/shellydimmer-334455/online:.* online
shellydimmer_334455:shellies/shellydimmer-334455/light/0:.* light_0
shellydimmer_334455:shellies/shellydimmer-334455/light/0/power:.* light_0_power
shellydimmer_334455:shellies/shellydimmer-334455/light/0/energy:.* light_0_energy
shellydimmer_334455:shellies/shellydimmer-334455/input/0:.* input_0
   room       Homekit,MQTT2_DEVICE,Wohnzimmer
   setList    off:noArg shellies/shellydimmer-334455/light/0/command off
  on:noArg shellies/shellydimmer-334455/light/0/command on
  pct:slider,0,1,100 shellies/shellydimmer-334455/light/0/set {"turn": "on","brightness": $EVTPART1}
  x_mqttcom shellies/shellydimmer-334455/command $EVTPART1
   webCmd     pct:on:off


und einem Shelly RGBW2 (ausgeschaltet)


Internals:
   CID        shellyrgbw2_334455
   DEF        shellyrgbw2_334455
   DEVICETOPIC MQTT2_shellyrgbw2_334455
   FUUID      5e0f36b1-f33f-add3-7c37-712194b42a5f7756
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 5998
   MQTT2_FHEM_Server_TIME 2020-01-20 12:31:55
   MSGCNT     5998
   NAME       MQTT2_shellyrgbw2_334455
   NR         156
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2020-01-20 12:31:55   blue            122
     2020-01-03 13:55:47   color_0         off
     2020-01-20 12:31:55   effect          0
     2020-01-19 11:57:18   fw_ver          20191216-090536/v1.5.7@c30657ba
     2020-01-20 12:31:55   gain            50
     2020-01-06 21:12:16   gain_on         set 100
     2020-01-20 12:31:55   green           57
     2020-01-19 11:57:18   id              shellyrgbw2-334455
     2020-01-19 11:57:18   ip              xxx.xxx.xxx.xxx
     2020-01-20 12:31:55   ison            false
     2020-01-19 11:57:18   mac             B4E62D334455
     2020-01-20 12:31:55   mode            color
     2020-01-19 11:57:18   new_fw          false
     2020-01-19 11:57:18   online          true
     2020-01-20 12:31:55   overpower       false
     2020-01-20 12:31:55   power           0.00
     2020-01-20 12:31:55   red             0
     2020-01-20 12:31:55   rgb             00397A
     2020-01-06 21:12:28   rgb_on          set FF0808
     2020-01-20 12:31:55   state           off
     2020-01-20 12:31:55   white           50
     2020-01-06 21:12:11   white_on        set 0
     2020-01-03 13:56:00   x_mqttcom       set announce
Attributes:
   IODev      MQTT2_FHEM_Server
   alias      EG_Wohnzimmer_Lichtleiste
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"power","unknown");; "<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>"}
   group      Lampen
   icon       light_led_stripe_rgb
   model      shelly2rgbw_color
   readingList shellies/shellyrgbw2-334455/color/0/status:.* {json2nameValue($EVENT)}
  shellies/shellyrgbw2-334455/color/0:.* state
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-334455...mac.*, ? json2nameValue($EVENT) : undef }
shellyrgbw2_334455:shellies/shellyrgbw2-334455/online:.* online
   room       Homekit,MQTT2_DEVICE,Wohnzimmer
   setList    off:noArg shellies/shellyrgbw2-334455/color/0/command off
  on:noArg shellies/shellyrgbw2-334455/color/0/command on
  white:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-334455/color/0/set {"white":"$EVTPART1"}
  gain:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-334455/color/0/set {"gain":"$EVTPART1"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-334455/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-334455/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  white_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-334455/color/0/set {"turn":"on","white":"$EVTPART1"}
  gain_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-334455/color/0/set {"turn":"on","gain":"$EVTPART1"}
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-334455/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-334455/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  effect:select,0,1,2,3 shellies/shellyrgbw2-334455/color/0/set {"effect":"$EVTPART1"}
  x_update:noArg shellies/shellyrgbw2-334455/command update_fw
  x_mqttcom shellies/shellyrgbw2-334455/command $EVTPART1
   setStateList on off
   userReadings rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
   webCmd     on:off:white:gain:rgb:effect


Ein Reading "state" ist beim Dimmer vorhanden. Es enthält in ausgeschaltetem Zustand den String "off" und eingeschaltet "pct". Ich habe inzwischen herausgefunden, dass homebridge-fhem zuerst nach dem Readding "pct" sucht (index.js, Zeile 1312). Dieses Reading enthält immer den letzten Prozentwert und deshalb wird die Lampe wohl als eingeschaltet angezeigt. Hatte probeweise mal die Zeile auf das Reading "state" geändert und dann funktioniert es. Da dieser Fall eigentlich für einen anderen gedacht ist, ist das aber keine gute Lösung.

Wenn Du mehr Daten benötigst, dann lass es mich wissen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 20 Januar 2020, 13:16:19
Hmm, diese Sprachsteuerungsdinge sind für mich terra incognita, aber wenn die Reading-Namen passen, geht scheinbar vieles automatisch...

Kannst du mal testweise zunächst mal eine Zeile der rL so ändern:
shellies/shellydimmer-334455/light/0:.* state
Zu dem hisherigen state-Reading: ich würde vermuten, das kommt von der FHEM-Seite und wird nicht vom Shelly aktualisiert, und ohne setStateList landet da z.B. auch der pct-Wert.
Testweise daher in Schritt 2 dann noch ergänzen:
setStateList on off
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ingohz am 20 Januar 2020, 19:21:20
Die Änderungen brachten leider keine Veränderung. Hier nochmal das geänderte Listing:


Internals:
   CID        shellydimmer_334455
   DEF        shellydimmer_334455
   DEVICETOPIC MQTT2_shellydimmer_334455
   FUUID      5e1f564a-f33f-add3-4655-c6857f89c29a2509
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 33816
   MQTT2_FHEM_Server_TIME 2020-01-20 19:16:00
   MSGCNT     33816
   NAME       MQTT2_shellydimmer_334455
   NR         164
   STATE      off
   TYPE       MQTT2_DEVICE
   JSONMAP:
     brightness pct
   READINGS:
     2020-01-20 19:16:00   brightness      50
     2020-01-19 11:57:18   fw_ver          20191216-090622/v1.5.7@c30657ba
     2020-01-19 11:57:18   id              shellydimmer-334455
     2020-01-18 19:14:24   input_0         0
     2020-01-19 11:57:18   ip              xxx.xxx.xxx.xxx
     2020-01-20 19:16:00   ison            false
     2020-01-20 19:16:00   light_0         off
     2020-01-20 19:16:00   light_0_energy  598
     2020-01-20 19:16:00   light_0_power   0.00
     2020-01-20 19:16:00   loaderror       0
     2020-01-19 11:57:18   mac             CC50E3334455
     2020-01-20 19:16:00   mode            white
     2020-01-19 11:57:18   new_fw          false
     2020-01-19 11:57:18   online          true
     2020-01-20 19:16:00   overload        0
     2020-01-20 19:16:00   overtemperature 0
     2020-01-20 19:08:00   pct             50
     2020-01-20 19:16:00   state           off
     2020-01-20 19:16:00   temperature     46.16
     2020-01-20 19:16:00   temperature_f   115.08
Attributes:
   IODev      MQTT2_FHEM_Server
   alias      EG_Wohnzimmer_Deckenlampe
   devStateIcon {my $lderr = ReadingsVal($name,"loaderror","true") eq "true"?"10px-kreis-rot":"10px-kreis-gruen";; my $light = ReadingsVal($name,"ison","false") eq "true"?"on":"off";; my $cons = ReadingsVal($name,"light_0_power","unknown");; FW_makeImage($lderr)."<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Leistung: $cons</div>"}
   group      Lampen
   icon       light_control
   jsonMap    brightness:pct
   model      shellydimmer
   readingList shellies/shellydimmer-334455/light/0:.* state
  shellies/shellydimmer-334455/temperature:.* temperature
  shellies/shellydimmer-334455/temperature_f:.* temperature_f
  shellies/shellydimmer-334455/overtemperature:.* overtemperature
  shellies/shellydimmer-334455/overload:.* overload
  shellies/shellydimmer-334455/loaderror:.* loaderror
  shellies/announce:.* { $EVENT =~ m,..id...shellydimmer-334455...mac.*, ? json2nameValue($EVENT) : undef }
shellydimmer_334455:shellies/shellydimmer-334455/online:.* online
shellydimmer_334455:shellies/shellydimmer-334455/light/0:.* light_0
shellydimmer_334455:shellies/shellydimmer-334455/light/0/power:.* light_0_power
shellydimmer_334455:shellies/shellydimmer-334455/light/0/energy:.* light_0_energy
shellydimmer_334455:shellies/shellydimmer-334455/input/0:.* input_0
shellydimmer_334455:shellies/shellydimmer-334455/light/0/status:.* { json2nameValue($EVENT) }
   room       Homekit,MQTT2_DEVICE,Wohnzimmer
   setList    off:noArg shellies/shellydimmer-334455/light/0/command off
  on:noArg shellies/shellydimmer-334455/light/0/command on
  pct:slider,0,1,100 shellies/shellydimmer-334455/light/0/set {"turn": "on","brightness": $EVTPART1}
  x_mqttcom shellies/shellydimmer-334455/command $EVTPART1
   setStateList on off
   webCmd     pct:on:off
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 23 Januar 2020, 15:19:11
Hmmm, dann bleiben nur zwei Wege...

Entweder du bringst der Spracherkennung bei, dass "state" wichtiger ist als pct, oder du setzt das Reading pct auf "0", wenn "state" auf "off" geht. Kann aber sein, dass letzteres Nebenwirkungen hat...

Das ginge jedenfalls so, dass du ein userReadings "pct" anlegst, das aber NUR DANN getriggert wird, wenn state auf off geht und dann "0" zurückgibt. Reicht das als Info?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ingohz am 23 Januar 2020, 21:34:18
Ja, danke. Ich hab die Auswertung in homebridge-fhem angepasst (index.js, Zeile 1312).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 23 Januar 2020, 21:51:29
Finde es gut wenn jemand herausgefunden hat worum es geht. Allerdings interessiert sich die Nachwelt sicher für die genaue Lösung. :)

Gesendet von meinem LM-G810 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ingohz am 24 Januar 2020, 09:21:05
Kein Problem: Die Datei index.js aus dem Paket homebridge-fhem (bei meiner Installation  im Verzeichnis /usr/lib/node_modules/homebridge-fhem) wie folgt ändern:

Bei der Abfrage für den "HM dimmer" (ab Zeile 1312) das Mapping für on/off von "pct" in "state" ändern:


  } else if( match = s.PossibleSets.match(/(^| )pct\b/) ) {
    // HM dimmer
    if( !this.service_name ) this.service_name = 'light';
    this.mappings.On = { reading: 'pct', valueOff: '0', cmdOn: 'on', cmdOff: 'off' };
    this.mappings.Brightness = { reading: 'pct', cmd: 'pct', delay: true };


ändern in


  } else if( match = s.PossibleSets.match(/(^| )pct\b/) ) {
    // HM dimmer
    if( !this.service_name ) this.service_name = 'light';
    this.mappings.On = { reading: 'state', valueOff: 'off', cmdOn: 'on', cmdOff: 'off' };
    this.mappings.Brightness = { reading: 'pct', cmd: 'pct', delay: true };


Wahrscheinlich stimmt dann die Anzeige für den HM Dimmer nicht mehr, aber für den Shelly passt es nun. Quick and dirty.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Januar 2020, 09:48:24
Zwei Anmerkungen evtl. zu homebridge, allerdings von einem Blinden, der von Farbe redet:

1. MMn. wäre es zielführend für alle User, wenn ihr André/justme1968 dazu ins Boot holt, vermutlich am einfachsten über einen der in https://wiki.fhem.de/wiki/Homebridge_einrichten verlinkten Threads.
Das ist eine Sache, die evtl. etwas komplexer gelöst werden muß, ich hatte dazu jüngst eine ähnliche Frage zu Color.pm, das daraufhin auch "in diese Richtung" geändert wurde.

2. Mit "option:" gibt es seit längerem die Möglichkeit, in den attrTemplates auch sprachsteuerungsspezifische Dinge mit einzubauen, aber nur anzuwenden, wenn das Sinn macht. Da die meisten templates für verbreitetes Zeug zwischenzeitlich wohl als ausgereift bezeichnet werden können, und auch der Umbau via jsonMap in "sprachsteuerungsfreundliche" Readingbenennungen scheinbar erfolgreich erfolgt ist, können wir das gerne angehen und die templates auch in dieser Hinsicht weiter optimieren.
Ich kann und will dabei aber nicht selbst testen, zum einen, weil ich keine Äpfel im Haus habe, und auch keine Cortanas ... hier rumspringen haben will, und zum anderen habe ich noch mindestens eine andere Baustelle, um die ich mich etwas intensiver kümmern will.

Wenn sich also jemand berufen fühlen würde, die basics für Punkt 2 mit zu legen: Einfach neuen Thread hier aufmachen (oder es gab irgendwo auch mal einen zum Thema attrTemplate+Sprachsteuerung, für den Rudi das "option:" und "prereq:"-feature eingebaut hatte; da könnte man sich auch anhängen, da sollte dann auch André schom mit an Bord sein).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Januar 2020, 09:53:17
Hey auch hier nochmal. Bist heute ja richtig poetisch ;)

Sowohl beim fischen als auch beim Äpfel pflücken bin ich immer gern behilflich. Ich selber hab HW und auch Alexa.

Zu den readings. An sich müssen die werte eben nur passen. Standard sind begriffe wie pct, in, off, rgb, temperature usw. Ich selber lege entweder den Namen um, wenn er nicht passt oder lege mir einfach ein user reading an. Leider weiß ich gerade nicht wo es genau klemmt. Habe das thema wohl nicht verstanden.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Januar 2020, 10:23:40
Zitat von: 87insane am 24 Januar 2020, 09:53:17
Hey auch hier nochmal. Bist heute ja richtig poetisch ;)
Dachte, dass bei manchen vielleicht Bilder eher Wirkung zeigen wie unfreundliches Anschnautzen ;D .

ZitatSowohl beim fischen als auch beim Äpfel pflücken bin ich immer gern behilflich. Ich selber hab HW und auch Alexa.

Zu den readings. An sich müssen die werte eben nur passen. Standard sind begriffe wie pct, in, off, rgb, temperature usw. Ich selber lege entweder den Namen um, wenn er nicht passt oder lege mir einfach ein user reading an. Leider weiß ich gerade nicht wo es genau klemmt. Habe das thema wohl nicht verstanden.
Dann wäre Fleißaufgabe 1a:
Schau nach, wo in der aktuellen Fassung der templatefile im svn noch Readingnamen drin sind, die verbessert werden könnten und liefere ein diff ;) .
Als Anhaltspunkt kannst du ja nachsehen, wo du (z.B. mit userReadings) "nachgesteuert" hast, list+FILTER sollten helfen, das schnell zu identifizieren.

Dann wäre Fleißaufgabe 1b:
Schau nach, welche Einstellungen (homebridgemapping?) dann noch erforderlich waren, um das jeweils zum Laufen zu bringen. Sie nach, ob das ggf. durch ein besseres jsonMap usw. "vorab" erledigt werden kann.
Auch das darf ins diff, ggf. kannst du gleich für vergleichbare templates auch Vorschläge liefern...

Aufgabe 2:
Kläre mit dem homebridge-Verantwortlichen, ob ggf. weitere Dinge auszuwerten sein könnten (z.B. brightness als Standard für 0-255-Helligkeitswerte). Dann muss nicht jeder User bei jedem Gerät irgendeine Umrechnung in pct/0-100 vornehmen, sondern kann die Werte "as is" verwenden...

Aufgabe 3:
Finde jemanden, der das für alexa parallel macht ;D .

Alles weitere findet sich, aber (mal wieder...): Nicht in diesem Thread ::) ;) 8) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Januar 2020, 10:31:43
Würde mir wünschen das hier ggf jeder sich um ein Gerät kümmert. Ich alleine würde ewig brauchen diese Aufgaben an x unterschiedlich Geräten durch zu führen und zu testen. Da bin ich ehrlich... Kann gerne liefern, aber wie du auch immer wieder sagst, die Kollegen hier im Forum dürfen gerne auch probieren und wünschen und liefern :)

Was homebridge/alexa angeht, würde ich gerne Erst mal ne Liste haben wollen, was nicht geht. Da bei mir ja alles läuft, weil selber gemacht oder von anfang an ging, ist es schwer das so auseinander zu nehmen.

Danke an alle Unterstützer/Helfer !

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Januar 2020, 10:48:07
Zitat von: 87insane am 24 Januar 2020, 10:31:43
Würde mir wünschen das hier ggf jeder sich um ein Gerät kümmert.
Mein Wunsch wäre (u.a.), dass überhaupt erst mal _ein Gerät_ via attrTemplate die "Eigenschaften" bekommt, die es braucht ;) .

Hat man mal eine Art "Master"-template für "option:" und die Frage, wie man z.B. die Raumliste erweitert (?), finden sich in der Regel auch weitere User, die das dann vollends ausrollen.

Es geht halt für alle einfacher, wenn man die Ausgangsbasis gleich bereinigt, z.B. indem man passende Readingnamen vergibt. Das war der Hauptgrund, warum ich insbesondere Tasmota nach jsonMap umgestellt habe! Das ist allerdings "nur" hilfreich, nicht aber notwendig, man kann das auch "nebenbei" erledigen... Es erzeugt halt nur ggf. Frust bei denen, die neu einsteigen, wenn sich die Readings dann erst nach und nach ändern, und ich habe nicht die große Lust, den Hintergrund eventuell noch erforderlicher Anpassungen an vielen Stellen zu erläutern, daher wäre mich "jetzt und gleich" lieber ;) .

Und ich glaube auch nicht, dass es schwer ist, das jetzt "auseinanderzunehmen" (das mußt du vermutlich nicht, sondern kannst das nach und nach machen). Aber nur so finden wir ggf. raus, was allg. noch fehlt...

Aber du hast recht, es gibt noch andere, die den Job machen könnten, und der Aufruf war auch nicht an dich speziell gerichtet ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Rossi am 01 Februar 2020, 18:19:08
Hi,

Ich habe einen Shelly 2.5 mit aktueller FW mittels Templete "shelly25_roller_invert_1" als Rollo Schalter eingerichtet und es funktioniert auch alles soweit, aber die Darstellung ist etwas strange. Ich hätte nur ein Statusbild erwartet. Siehe Anhang.
Bitte nicht über ganzen zusätzlichen Readings und Attribute wundern, die habe ich wegen meiner Rollo Steuerung eingefügt. ;-)

Kann mir jemand sagen woran das liegt und wie das evtl. fixen kann?

Hier ein List:
Internals:
   CHANGED   
   CID        shellyswitch25_10C987
   DEF        shellyswitch25_10C987
   DEVICETOPIC Rol.BueroShelly.Tuer
   FUUID      5e3584d0-f33f-4ad6-6e5f-4917f8af63e19389
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 1397
   MQTT2_FHEM_Server_TIME 2020-02-01 18:17:15
   MSGCNT     1397
   NAME       Rol.BueroShelly.Tuer
   NR         386
   STATE      <a href="http://192.168.5.57" target="_blank">
true
</a>
100
   TYPE       MQTT2_DEVICE
   READINGS:
     2020-02-01 17:32:13   Automatik_Abschatten_Ende_vorgemerkt 0
     2020-02-01 17:31:56   Automatik_Abschatten_vorgemerkt 0
     2020-02-01 16:41:13   Automatik_Abschattung_Bereich 210...320
     2020-02-01 17:26:43   Automatik_Abschattung_Zaehler_hoch 1
     2020-02-01 17:28:53   Automatik_Abschattung_Zaehler_runter 2
     2020-02-01 17:32:13   Automatik_Abschattung_letzte_Uhrzeit 17:32:13
     2020-02-01 16:41:13   Automatik_Modus_hoch immer
     2020-02-01 16:41:13   Automatik_Modus_runter immer
     2020-02-01 15:15:22   Automatik_Nachtschliessen 0
     2020-02-01 17:32:13   Automatik_Pos_vor_Abschattung -1
     2020-02-01 17:31:00   Automatik_Pos_vor_Geoeffnet -1
     2020-02-01 16:43:28   Automatik_Pos_vor_Lueften -1
     2020-02-01 17:31:00   Automatik_automatische_Fahrt 1
     2020-02-01 16:41:13   Automatik_hoch_Zeit 08:00:00
     2020-02-01 17:32:13   Automatik_in_Abschattung 0
     2020-02-01 16:41:13   Automatik_runter_Zeit 17:31
     2020-02-01 17:28:49   Manu_Modus      aus
     2020-02-01 15:27:10   closed          set
     2020-02-01 17:31:13   current         stop
     2020-02-01 18:17:15   energy          955
     2020-02-01 16:41:42   fw_ver          20200122-090247/v1.5.9@4b657c90
     2020-02-01 16:41:42   id              shellyswitch25-10C987
     2020-02-01 18:17:15   input0          0
     2020-02-01 18:17:15   input1          0
     2020-02-01 16:41:42   ip              192.168.5.57
     2020-02-01 16:41:42   mac             C82B9610C987
     2020-02-01 16:41:42   new_fw          false
     2020-02-01 16:41:42   online          true
     2020-02-01 18:17:15   overtemperature 0
     2020-02-01 18:17:15   pct             100
     2020-02-01 18:17:15   position        100
     2020-02-01 18:17:15   power           0.00
     2020-02-01 18:17:15   state           100
     2020-02-01 18:17:15   temperature     50.31
     2020-02-01 14:47:26   x_mqttcom       set announce
Attributes:
   Auto_Abschattung ja
   Auto_Abschattung_Helligkeitssensor AktuelleSonneneinstrahlungPV
   Auto_Abschattung_Pos 50
   Auto_Abschattung_Pos_nach_Abschattung -1
   Auto_Abschattung_Schwelle_sonnig 1500
   Auto_Abschattung_Schwelle_wolkig 1000
   Auto_Abschattung_Sperrzeit_nach_manuell 0
   Auto_Abschattung_Sperrzeit_vor_Nacht 0
   Auto_Abschattung_Wartezeit 0
   Auto_Abschattung_Winkel_links 60
   Auto_Abschattung_Winkel_rechts 50
   Auto_Abschattung_min_Temp_aussen 2.5
   Auto_Abschattung_min_elevation -10
   Auto_Aussperrschutz nein
   Auto_Fensterkontakt FensterKontakt_Buero
   Auto_Fensterkontakttyp twostate
   Auto_Himmelsrichtung 245
   Auto_Lueften_Pos 70
   Auto_Luft_Fenster_offen ja
   Auto_Modus_hoch immer
   Auto_Modus_runter immer
   Auto_Zeit_hoch_WE_Urlaub 08:00
   Auto_Zeit_hoch_frueh 06:00
   Auto_Zeit_hoch_spaet 08:00
   Auto_Zeit_runter_frueh 16:00
   Auto_Zeit_runter_spaet 22:00
   Auto_geschlossen_Pos 100
   Auto_hoch  Astro
   Auto_offen_Pos 0
   Auto_runter Astro
   IODev      MQTT2_FHEM_Server
   Manu_Modus aus
   Manu_geschlossen_Pos 100
   Manu_offen_Pos 0
   alias      Rollo Büro Tür
   cmdIcon    open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
   comment    Shelly 2.5 in Roller-Mode. 0=opened / 100=closed
   devStateIcon { my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $con = ReadingsVal($name,"state","undef");; my $pic = $con eq "opening" ? 'fts_shutter_up@red' : $con eq "closing" ? 'fts_shutter_down@red' : $con eq "100" ? 'fts_shutter_100' : $con =~ /(\d)\d/ ? 'fts_shutter_'.$1.'0' : $con =~ /\b\d\b/ ? 'fts_shutter_10' : 'fts_shutter_updown';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." </div>"}
   event-on-change-reading .*
   icon       fts_shutter_all
   model      shelly25_roller_invert_1
   readingList shellies/shellyswitch25-10C987/roller/0/pos:.* {'pct' => 100-$EVENT}
  shellies/shellyswitch25-10C987/status/0/rollers:.* power
  shellies/shellyswitch25-10C987/online:.* online
  shellies/shellyswitch25-10C987/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-10C987...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shellyswitch25-10C987/roller/0:.* current
  shellies/shellyswitch25-10C987/roller/0:open {{'state' => 'opening'}}
  shellies/shellyswitch25-10C987/roller/0:close {{'state' => 'closing'}}
  shellies/shellyswitch25-10C987/roller/0/pos:.* {'state' => 100-$EVENT}
  shellies/shellyswitch25-10C987/input/1:.* input1
  shellies/shellyswitch25-10C987/input/0:.* input0
  shellies/shellyswitch25-10C987/relay/power:.* power
  shellies/shellyswitch25-10C987/relay/energy:.* energy
  shellies/shellyswitch25-10C987/temperature:.* temperature
  shellies/shellyswitch25-10C987/overtemperature:.* overtemperature
   room       Steuerung -> Rollos,Zimmer -> Büro
   setList    open:noArg shellies/shellyswitch25-10C987/roller/0/command open
  close:noArg shellies/shellyswitch25-10C987/roller/0/command close
  closed:noArg shellies/shellyswitch25-10C987/roller/0/command close
  half:noArg shellies/shellyswitch25-10C987/roller/0/command/pos 50
  stop:noArg shellies/shellyswitch25-10C987/roller/0/command stop
  pct:slider,0,1,100 {"shellies/shellyswitch25-10C987/roller/0/command/pos ".(100-$EVTPART1)}
  position:slider,0,1,100 {"shellies/shellyswitch25-10C987/roller/0/command/pos ".(100-$EVTPART1)}
  x_recalibration:noArg shellies/shellyswitch25-10C987/roller/0/command rc
  x_update:noArg shellies/shellyswitch25-10C987/command update_fw
  x_mqttcom shellies/shellyswitch25-10C987/command $EVTPART1
   setStateList open close half stop pct
   stateFormat <a href="http://ip" target="_blank">
online
</a>
state
   type       normal
   userReadings position {ReadingsVal($NAME,"pct",-1)}
   userattr   Auto_Modus_hoch:bei_Abwesenheit,bei_Anwesenheit,immer,aus Auto_Modus_runter:bei_Abwesenheit,bei_Anwesenheit,immer,aus Auto_hoch:Zeit,Astro Auto_runter:Zeit,Astro Auto_Abschattung_Pos:0,10,20,30,40,50,60,70,80,90,100 Auto_Abschattung_Pos_nach_Abschattung:-1,0,10,20,30,40,50,60,70,80,90,100 Auto_Lueften_Pos:0,10,20,30,40,50,60,70,80,90,100 Auto_offen_Pos:0,10,20,30,40,50,60,70,80,90,100 Auto_Himmelsrichtung Auto_Abschattung:ja,nein,verspaetet,bei_Abwesenheit,bei_Anwesenheit Auto_Zeit_hoch_frueh Auto_Zeit_hoch_spaet Auto_Zeit_hoch_WE_Urlaub Auto_Zeit_runter_frueh Auto_Zeit_runter_spaet Auto_Zufall_Minuten Auto_Fensterkontakt Auto_Luft_Fenster_offen:ja,nein Auto_Aussperrschutz:ja,nein Auto_Geoeffnet_Pos:0,10,20,30,40,50,60,70,80,90,100 Auto_Abschattung_Winkel_links:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 Auto_Abschattung_Winkel_rechts:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 Auto_Abschattung_Helligkeitssensor Auto_Abschattung_Schwelle_sonnig Auto_Abschattung_Schwelle_wolkig Auto_Abschattung_Wartezeit Auto_Abschattung_min_elevation Auto_Abschattung_min_Temp_aussen Auto_Abschattung_Sperrzeit_nach_manuell Auto_Offset_Minuten_morgens Auto_Offset_Minuten_abends Auto_Abschattung_Sperrzeit_vor_Nacht Auto_Abschattung_schnell_oeffnen:nein,ja Auto_Abschattung_schnell_schliessen:nein,ja Auto_Fensterkontakttyp:twostate,threestate Auto_Pos_Befehl Auto_geschlossen_Pos Manu_Modus:ein,aus Manu_offen_Pos Manu_geschlossen_Pos Auto_Termin_beruecksichtigen type
   webCmd     :open:close:half:stop:pct
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 01 Februar 2020, 21:59:25
Hallo FHEM-Forum,

an dieser Stelle
Zitataber die Darstellung ist etwas strange ...
möchte ich mich gerne in dieses Thema einklinken, wahrscheinlich aber mit wesentlich einfacheren "Problem(chen") mit meinem Shelly1.

Ja, ich habe nicht alle 555 Einträge gelesen. Und nein, die gelesenen Einträge habe ich auch nicht alle verstanden. Und nein, mit PERL kenne ich mich kaum aus und muss mich immer an Beispielen orientieren. So tief hinter die Kulissen reicht mein Blick leider nicht. Trotzdem möchte ich mit FHEM weitermachen.

Ich vermute, dass Rossis Problem hauptsächlich mit dem endlos langen PERL-String hinter dem Attribut "devStateIcon" zu tun hat. Das schaut beim Shelly1 zwar etwas anders aus, nämlich so:

{my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off");; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }

ist aber ähnlich lang und für mich leider "ein Buch mit sieben Siegeln".

Meine drei Shelly1, die ich als MQTT2_DEVICE  und mit dem attrTemplate "shelly1" mit FHEM betreibe tun nach einigem "Rumfragen" im Forum jetzt eigentlich was sie sollen. Sie schalten nämlich irgendetwas ein oder aus (mehr können und sollen sie auch nicht) und müllen mir auch nicht mehr den Event monitor voll. Besonders gelungen finde ich das Ampelsystem (sieht man auch bei Rossi), am dem man erkennen kann, ob irgendwo Handlungsbedarf besteht.

Zwei Dinge stören mich bzw. sind mir aufgefallen:

1. Wenn ich den Shelly vom Stromnetz trenne, verschwindet er aus dem WLAN und die Ampel zeigt richtigerweise "ROT". Wenn ich allerdings in diesem stromlosen Zustand "on" oder "off" schalte, dann wechselt das Lampensymbol sein Aussehen und es sieht so aus, als würde der Shelly schalten (kann er natürlich nicht, weil er keinen Strom hat). Das ist bei anderen Aktoren, die nur empfangen und nicht senden können, auch der Fall, aber der Shelly kann mehr, oder?

2. Das erwähnte "Lampensymbol" für Status "on" bzw. "off" ist jeweils das FHEM-Standartsymbol. Das würde ich gerne ändern. Im Prinzip weiß ich wie das geht, traue mich aber nicht an den endlos langen PERL-String hinter dem Attribut "devStateIcon" heran. Zudem würde ich gerne das Ampelsystem erhalten wollen.

Danke, gute Nacht und Grüße von Gundermann
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Februar 2020, 08:16:19
@rossi Stateformat muss gelöscht werden.

Gesendet von meinem LM-G810 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Februar 2020, 08:16:55
Zitat von: Rossi am 01 Februar 2020, 18:19:08
Hi,

Ich habe einen Shelly 2.5 mit aktueller FW mittels Templete "shelly25_roller_invert_1" als Rollo Schalter eingerichtet und es funktioniert auch alles soweit, aber die Darstellung ist etwas strange. Ich hätte nur ein Statusbild erwartet. Siehe Anhang.
Bitte nicht über ganzen zusätzlichen Readings und Attribute wundern, die habe ich wegen meiner Rollo Steuerung eingefügt. ;-)

Kann mir jemand sagen woran das liegt und wie das evtl. fixen kann?

Hier ein List:
Internals:
   CHANGED   
   CID        shellyswitch25_10C987
   DEF        shellyswitch25_10C987
   DEVICETOPIC Rol.BueroShelly.Tuer
   FUUID      5e3584d0-f33f-4ad6-6e5f-4917f8af63e19389
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 1397
   MQTT2_FHEM_Server_TIME 2020-02-01 18:17:15
   MSGCNT     1397
   NAME       Rol.BueroShelly.Tuer
   NR         386
   STATE      <a href="http://192.168.5.57" target="_blank">
true
</a>
100
   TYPE       MQTT2_DEVICE
   READINGS:
     2020-02-01 17:32:13   Automatik_Abschatten_Ende_vorgemerkt 0
     2020-02-01 17:31:56   Automatik_Abschatten_vorgemerkt 0
     2020-02-01 16:41:13   Automatik_Abschattung_Bereich 210...320
     2020-02-01 17:26:43   Automatik_Abschattung_Zaehler_hoch 1
     2020-02-01 17:28:53   Automatik_Abschattung_Zaehler_runter 2
     2020-02-01 17:32:13   Automatik_Abschattung_letzte_Uhrzeit 17:32:13
     2020-02-01 16:41:13   Automatik_Modus_hoch immer
     2020-02-01 16:41:13   Automatik_Modus_runter immer
     2020-02-01 15:15:22   Automatik_Nachtschliessen 0
     2020-02-01 17:32:13   Automatik_Pos_vor_Abschattung -1
     2020-02-01 17:31:00   Automatik_Pos_vor_Geoeffnet -1
     2020-02-01 16:43:28   Automatik_Pos_vor_Lueften -1
     2020-02-01 17:31:00   Automatik_automatische_Fahrt 1
     2020-02-01 16:41:13   Automatik_hoch_Zeit 08:00:00
     2020-02-01 17:32:13   Automatik_in_Abschattung 0
     2020-02-01 16:41:13   Automatik_runter_Zeit 17:31
     2020-02-01 17:28:49   Manu_Modus      aus
     2020-02-01 15:27:10   closed          set
     2020-02-01 17:31:13   current         stop
     2020-02-01 18:17:15   energy          955
     2020-02-01 16:41:42   fw_ver          20200122-090247/v1.5.9@4b657c90
     2020-02-01 16:41:42   id              shellyswitch25-10C987
     2020-02-01 18:17:15   input0          0
     2020-02-01 18:17:15   input1          0
     2020-02-01 16:41:42   ip              192.168.5.57
     2020-02-01 16:41:42   mac             C82B9610C987
     2020-02-01 16:41:42   new_fw          false
     2020-02-01 16:41:42   online          true
     2020-02-01 18:17:15   overtemperature 0
     2020-02-01 18:17:15   pct             100
     2020-02-01 18:17:15   position        100
     2020-02-01 18:17:15   power           0.00
     2020-02-01 18:17:15   state           100
     2020-02-01 18:17:15   temperature     50.31
     2020-02-01 14:47:26   x_mqttcom       set announce
Attributes:
   Auto_Abschattung ja
   Auto_Abschattung_Helligkeitssensor AktuelleSonneneinstrahlungPV
   Auto_Abschattung_Pos 50
   Auto_Abschattung_Pos_nach_Abschattung -1
   Auto_Abschattung_Schwelle_sonnig 1500
   Auto_Abschattung_Schwelle_wolkig 1000
   Auto_Abschattung_Sperrzeit_nach_manuell 0
   Auto_Abschattung_Sperrzeit_vor_Nacht 0
   Auto_Abschattung_Wartezeit 0
   Auto_Abschattung_Winkel_links 60
   Auto_Abschattung_Winkel_rechts 50
   Auto_Abschattung_min_Temp_aussen 2.5
   Auto_Abschattung_min_elevation -10
   Auto_Aussperrschutz nein
   Auto_Fensterkontakt FensterKontakt_Buero
   Auto_Fensterkontakttyp twostate
   Auto_Himmelsrichtung 245
   Auto_Lueften_Pos 70
   Auto_Luft_Fenster_offen ja
   Auto_Modus_hoch immer
   Auto_Modus_runter immer
   Auto_Zeit_hoch_WE_Urlaub 08:00
   Auto_Zeit_hoch_frueh 06:00
   Auto_Zeit_hoch_spaet 08:00
   Auto_Zeit_runter_frueh 16:00
   Auto_Zeit_runter_spaet 22:00
   Auto_geschlossen_Pos 100
   Auto_hoch  Astro
   Auto_offen_Pos 0
   Auto_runter Astro
   IODev      MQTT2_FHEM_Server
   Manu_Modus aus
   Manu_geschlossen_Pos 100
   Manu_offen_Pos 0
   alias      Rollo Büro Tür
   cmdIcon    open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
   comment    Shelly 2.5 in Roller-Mode. 0=opened / 100=closed
   devStateIcon { my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $con = ReadingsVal($name,"state","undef");; my $pic = $con eq "opening" ? 'fts_shutter_up@red' : $con eq "closing" ? 'fts_shutter_down@red' : $con eq "100" ? 'fts_shutter_100' : $con =~ /(\d)\d/ ? 'fts_shutter_'.$1.'0' : $con =~ /\b\d\b/ ? 'fts_shutter_10' : 'fts_shutter_updown';; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." </div>"}
   event-on-change-reading .*
   icon       fts_shutter_all
   model      shelly25_roller_invert_1
   readingList shellies/shellyswitch25-10C987/roller/0/pos:.* {'pct' => 100-$EVENT}
  shellies/shellyswitch25-10C987/status/0/rollers:.* power
  shellies/shellyswitch25-10C987/online:.* online
  shellies/shellyswitch25-10C987/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-10C987...mac.*, ? json2nameValue($EVENT) : undef }
  shellies/shellyswitch25-10C987/roller/0:.* current
  shellies/shellyswitch25-10C987/roller/0:open {{'state' => 'opening'}}
  shellies/shellyswitch25-10C987/roller/0:close {{'state' => 'closing'}}
  shellies/shellyswitch25-10C987/roller/0/pos:.* {'state' => 100-$EVENT}
  shellies/shellyswitch25-10C987/input/1:.* input1
  shellies/shellyswitch25-10C987/input/0:.* input0
  shellies/shellyswitch25-10C987/relay/power:.* power
  shellies/shellyswitch25-10C987/relay/energy:.* energy
  shellies/shellyswitch25-10C987/temperature:.* temperature
  shellies/shellyswitch25-10C987/overtemperature:.* overtemperature
   room       Steuerung -> Rollos,Zimmer -> Büro
   setList    open:noArg shellies/shellyswitch25-10C987/roller/0/command open
  close:noArg shellies/shellyswitch25-10C987/roller/0/command close
  closed:noArg shellies/shellyswitch25-10C987/roller/0/command close
  half:noArg shellies/shellyswitch25-10C987/roller/0/command/pos 50
  stop:noArg shellies/shellyswitch25-10C987/roller/0/command stop
  pct:slider,0,1,100 {"shellies/shellyswitch25-10C987/roller/0/command/pos ".(100-$EVTPART1)}
  position:slider,0,1,100 {"shellies/shellyswitch25-10C987/roller/0/command/pos ".(100-$EVTPART1)}
  x_recalibration:noArg shellies/shellyswitch25-10C987/roller/0/command rc
  x_update:noArg shellies/shellyswitch25-10C987/command update_fw
  x_mqttcom shellies/shellyswitch25-10C987/command $EVTPART1
   setStateList open close half stop pct
   stateFormat <a href="http://ip" target="_blank">
online
</a>
state
   type       normal
   userReadings position {ReadingsVal($NAME,"pct",-1)}
   userattr   Auto_Modus_hoch:bei_Abwesenheit,bei_Anwesenheit,immer,aus Auto_Modus_runter:bei_Abwesenheit,bei_Anwesenheit,immer,aus Auto_hoch:Zeit,Astro Auto_runter:Zeit,Astro Auto_Abschattung_Pos:0,10,20,30,40,50,60,70,80,90,100 Auto_Abschattung_Pos_nach_Abschattung:-1,0,10,20,30,40,50,60,70,80,90,100 Auto_Lueften_Pos:0,10,20,30,40,50,60,70,80,90,100 Auto_offen_Pos:0,10,20,30,40,50,60,70,80,90,100 Auto_Himmelsrichtung Auto_Abschattung:ja,nein,verspaetet,bei_Abwesenheit,bei_Anwesenheit Auto_Zeit_hoch_frueh Auto_Zeit_hoch_spaet Auto_Zeit_hoch_WE_Urlaub Auto_Zeit_runter_frueh Auto_Zeit_runter_spaet Auto_Zufall_Minuten Auto_Fensterkontakt Auto_Luft_Fenster_offen:ja,nein Auto_Aussperrschutz:ja,nein Auto_Geoeffnet_Pos:0,10,20,30,40,50,60,70,80,90,100 Auto_Abschattung_Winkel_links:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 Auto_Abschattung_Winkel_rechts:0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90 Auto_Abschattung_Helligkeitssensor Auto_Abschattung_Schwelle_sonnig Auto_Abschattung_Schwelle_wolkig Auto_Abschattung_Wartezeit Auto_Abschattung_min_elevation Auto_Abschattung_min_Temp_aussen Auto_Abschattung_Sperrzeit_nach_manuell Auto_Offset_Minuten_morgens Auto_Offset_Minuten_abends Auto_Abschattung_Sperrzeit_vor_Nacht Auto_Abschattung_schnell_oeffnen:nein,ja Auto_Abschattung_schnell_schliessen:nein,ja Auto_Fensterkontakttyp:twostate,threestate Auto_Pos_Befehl Auto_geschlossen_Pos Manu_Modus:ein,aus Manu_offen_Pos Manu_geschlossen_Pos Auto_Termin_beruecksichtigen type
   webCmd     :open:close:half:stop:pct

Zitat von: Gundermann am 01 Februar 2020, 21:59:25
Hallo FHEM-Forum,

an dieser Stellemöchte ich mich gerne in dieses Thema einklinken, wahrscheinlich aber mit wesentlich einfacheren "Problem(chen") mit meinem Shelly1.

Ja, ich habe nicht alle 555 Einträge gelesen. Und nein, die gelesenen Einträge habe ich auch nicht alle verstanden. Und nein, mit PERL kenne ich mich kaum aus und muss mich immer an Beispielen orientieren. So tief hinter die Kulissen reicht mein Blick leider nicht. Trotzdem möchte ich mit FHEM weitermachen.

Ich vermute, dass Rossis Problem hauptsächlich mit dem endlos langen PERL-String hinter dem Attribut "devStateIcon" zu tun hat. Das schaut beim Shelly1 zwar etwas anders aus, nämlich so:

{my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off");; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }

ist aber ähnlich lang und für mich leider "ein Buch mit sieben Siegeln".

Meine drei Shelly1, die ich als MQTT2_DEVICE  und mit dem attrTemplate "shelly1" mit FHEM betreibe tun nach einigem "Rumfragen" im Forum jetzt eigentlich was sie sollen. Sie schalten nämlich irgendetwas ein oder aus (mehr können und sollen sie auch nicht) und müllen mir auch nicht mehr den Event monitor voll. Besonders gelungen finde ich das Ampelsystem (sieht man auch bei Rossi), am dem man erkennen kann, ob irgendwo Handlungsbedarf besteht.

Zwei Dinge stören mich bzw. sind mir aufgefallen:

1. Wenn ich den Shelly vom Stromnetz trenne, verschwindet er aus dem WLAN und die Ampel zeigt richtigerweise "ROT". Wenn ich allerdings in diesem stromlosen Zustand "on" oder "off" schalte, dann wechselt das Lampensymbol sein Aussehen und es sieht so aus, als würde der Shelly schalten (kann er natürlich nicht, weil er keinen Strom hat).

2. Das erwähnte "Lampensymbol" für Status "on" bzw. "off" ist jeweils das FHEM-Standartsymbol. Das würde ich gerne ändern. Im Prinzip weiß ich wie das geht, traue mich aber nicht an den endlos langen PERL-String hinter dem Attribut "devStateIcon" heran. Zudem würde ich gerne das Ampelsystem erhalten wollen.

Danke, gute Nacht und Grüße von Gundermann
Zu 2) einfsch den Namen des bildes in dem Code ändern.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Rossi am 02 Februar 2020, 10:20:28
@87insane:
Ok, danke.  ;D
Es hat funktioniert, obwohl ich nicht weiß wo der Eintarg herkam, evtl. weil ich das erst nach dem Einbinden in FHEM auf Rollo Mode am Shelly umgeschalten habe.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 02 Februar 2020, 10:45:13
Kann sein das er noch im template ist. Wurde vor kurzem umgestellt auf Ampel usw. Kann sein das ich das übersehen habe.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 03 Februar 2020, 08:27:39
Hallo 87insane (oder wer auch immer sich damit auskennt),

ZitatZu 2) einfsch den Namen des bildes in dem Code ändern

Damit bin ich leider nicht weiter gekommen. Nach meinem Wissen lauten die Dateinamen der Standardsymbole "on.svg" und "off.svg", wobei .svg nicht angegeben werden muss. Wo genau in diesem Code steckt der Name des Bildes, der geändert werden muss. Ich habe etwas herumexperimentiert, komme aber zu keinem Ergebnis.

Grüße von Gundermann
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 03 Februar 2020, 08:35:52
Bei my light.
Da steht aktuell einfsch on/off drin. Weil aus dem reading das raus kommt. Wenn du was anderes magst muss du das dort ändern. Wie die bilder heißen, einfsch mal im Icon Bereich nachsehen.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Februar 2020, 10:18:40
@all:
Ausgehend von diesem Thread (https://forum.fhem.de/index.php/topic,107859.msg1018661.html#msg1018661), in dem es um zyklische Statusinfos ging:

Zitat von: rudolfkoenig am 02 Februar 2020, 18:11:43
https://shelly-api-docs.shelly.cloud/#mqtt-support (https://shelly-api-docs.shelly.cloud/#mqtt-support)
ZitatDevice state is reported periodically, every 30 seconds by default. This can be changed by setting a new period for updates: mqtt_update_period under /settings. A value of 0 will disable periodic updates.
Kann mir jemand den MQTT-Code austesten, um diese Statusmeldungen zu unterbinden, dann baue ich das eventuell in den Standard ein...?
Würde auf dieses Format tippen:
set IO_DEV publish shellies/DEVNAME/settings mqtt_update_period 0
Wäre nur interessant zu wissen, ob das dann alles ausschaltet, oder die "sinnvollen" updates (Verbrauch usw.) trotzdem kommen?




@Gundermann: Ggf. kannst du auch einfach in der FHEMWEB-Instand iconPath anpassen?
Ansonsten, wenn du die "Ampel" nicht benötigst: Einfach die "normale" Form von devStateIcon verwenden (siehe Wiki zu DeviceOverview anpassen).
Und: Threads zu schließen ist "not recommended", ich hätte das mit den Updates lieber an der anderen Stelle rückgefragt...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 03 Februar 2020, 11:31:14
ZitatThreads zu schließen ist "not recommended"
Sorry, sollte jetzt wieder geöffnet sein.

Grüße von Gundermann
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 04 Februar 2020, 16:52:06
@ Beta-User und 87insane

Mit dem Thema ,,Icons" komme ich leider nicht klar und habe es jetzt aufgegeben. Hauptsache die Shellys schalten.

Danke für die Bemühungen und Grüße von Gundermann
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 Februar 2020, 17:15:06
Zitat von: Gundermann am 04 Februar 2020, 16:52:06
@ Beta-User und 87insane

Mit dem Thema ,,Icons" komme ich leider nicht klar und habe es jetzt aufgegeben. Hauptsache die Shellys schalten.

Danke für die Bemühungen und Grüße von Gundermann
Hey... So schnell aufgeben lohnt dich nicht ;)
Es ist in der Tat kein einfacher Code aber ein wenig rein denken muss sein, da man sonst nie selber was ändern kann.

Anbei sende ich mal ein devstateicon wie ich es zb für einen shelly 1pm nutze. Dieser ist an einer deckenlampe angeschlossen und beinhaltet zum einen ein anderes Symbol aber auch eine andere Farbe des Symbols, wenn das Gerät an ist. Dann sollte es etwas klarer sein:

{ my $amp = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off") eq "on"?'light_pendant_light@green':'light_pendant_light';; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $temp = ReadingsVal($name,"temperature","-100");; my $show = "$amp" eq "gelb" ? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" : "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C </div>" }

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Februar 2020, 17:19:20
Ganz ohne Perl (für devStateIcon, kein stateFormat setzen):
on:light_pendant_light@green off:light_pendant_light
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 04 Februar 2020, 19:24:14
@ Beta-User und 87insane

Nachdem ihr beiden keine Ruhe gegeben habt, hat auch mich noch einmal der Ehrgeiz gepackt und siehe da: es funktioniert.

Mit
on:light_pendant_light@green off:light_pendant_light
konnte ich zwar beliebige Icons verwenden aber leider ohne die Ampel, die mir so gut gefällt.

Das Beispiel von 87insane hat mir letztlich auf die Sprünge geholfen.
Meinen ursprünglichen PERL-String, der aus dem Template "shelly1" stammt, habe ich lediglich um den hier rot dargestellten Teil ergänzt ...

{my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $light = ReadingsVal($name,"state","off") eq "on"?'on1':'off1';; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>"}

...  und schon kann ich bei 'on1' und 'off1' beliebige Iconnamen einsetzen. Genau das war mein Ziel.

@ Beta-User
Ich lese in anderen Forenbeiträgen, dass du dich derzeit mit dem Thema Templates wohl intensiv beschäftigst. Vieleicht kannst du das hier ja irgendwie verwerten.

Noch einmal herzlichen Dank für die Geduld und Grüße von Gundermann

NS: Auf meine erste Frage aus #556 werde ich wohl auch noch irgendwann eine Antwort finden.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 Februar 2020, 19:58:37
556 ist von Rossi auf meinem Handy und wurde auch beantwortet. Hab ich was überlesen?

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Februar 2020, 07:40:27
Gemeint ist wohl das:
Zitat von: Gundermann am 01 Februar 2020, 21:59:25
1. Wenn ich den Shelly vom Stromnetz trenne, verschwindet er aus dem WLAN und die Ampel zeigt richtigerweise "ROT". Wenn ich allerdings in diesem stromlosen Zustand "on" oder "off" schalte, dann wechselt das Lampensymbol sein Aussehen und es sieht so aus, als würde der Shelly schalten (kann er natürlich nicht, weil er keinen Strom hat). Das ist bei anderen Aktoren, die nur empfangen und nicht senden können, auch der Fall, aber der Shelly kann mehr, oder?

Kann nur raten: Es erscheint ein Lampensymbol mit rotem Fragezeichen darin?
Wenn ja: Works as designed => das zeigt an, dass es zwar einen Schaltbefehl gab, dieser aber nicht bei der Hardware angekommen ist...
Ansonsten hätte ich gerne ausnahmsweise (!) einen Screenshot.

@Gundermann:
Bis dato sehe ich keine Veranlassung, statt des "on"-Symbols irgendwas anderes zu verwenden.
Vielleicht liest du mal in der commandref den Eintrag zu iconPath bei FHEMWEB, mMn. kann man das, was du möchtest, besser erreichen durch ein eigenes Verzeichnis mit eigenen Dateien namens "on.xyz" usw., das mit der höchsten Prio durchsucht werden soll. Das wirkt dann nämlich systemweit, ohne dass man irgendwelche Änderungen an einzelnen Devices vornehmen müßte...
(Ziemlich genau aus diesem Grund dränge ich hier immer mal wieder darauf, dass bitte Standardsymbole und diese in der Regel ohne Farbe zu verwenden sind...!)

Vielleicht noch eine persönliche Anmerkung zur Tonlage: Eventuell hat du etwas Zeit und kannst den hier verlinkten Artikel mal in Ruhe durchlesen: https://forum.fhem.de/index.php/topic,13092.msg105687.html#msg105687
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 05 Februar 2020, 13:59:52
@ Beta-User

ZitatVielleicht noch eine persönliche Anmerkung zur Tonlage: Eventuell hat du etwas Zeit und kannst den hier verlinkten Artikel mal in Ruhe durchlesen

Gelesen und viel darüber gelernt, wie Hacker ticken. Danke
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 05 Februar 2020, 14:31:09
@ Beta-User

ZitatKann nur raten: Es erscheint ein Lampensymbol mit rotem Fragezeichen darin?

Genau soetwas dachte ich mir. Das wäre dann - neben der roten Ampel - ein Hinweis, dass es ein Problem gibt (z.B. keinen Strom, also Schaltbefehl nicht angekommen). Die Lampensymbole sind aber immer die gleichen, nämlich die Standardsymbole, ob mit oder ohne Strom am Shelly, kein rotes Fragezeichen.

Und so sieht es unter "RAW definition" aus (die Attirbute "devStateIcon", "readingList" und "setList" sind aus dem attrTemplate "shelly1"):

defmod 233_Reserve_MQTT2_shelly1_2C79A6 MQTT2_DEVICE shelly1_2C79A6
attr 233_Reserve_MQTT2_shelly1_2C79A6 IODev MQTT2_FHEM_Server
attr 233_Reserve_MQTT2_shelly1_2C79A6 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $show = '<a href="';;;;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;;;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";;;; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }
attr 233_Reserve_MQTT2_shelly1_2C79A6 event-on-change-reading .*
attr 233_Reserve_MQTT2_shelly1_2C79A6 model shelly1
attr 233_Reserve_MQTT2_shelly1_2C79A6 readingList shellies/shelly1-2C79A6/relay/0:.* state\
  shellies/shelly1-2C79A6/relay/0:.* relay0\
  shellies/shelly1-2C79A6/input/0:.* input0\
  shellies/shelly1-2C79A6/online:.* online\
  shellies/shelly1-2C79A6/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shelly1-2C79A6...mac.*, ? json2nameValue($EVENT) : undef }
attr 233_Reserve_MQTT2_shelly1_2C79A6 room MQTT2_DEVICE
attr 233_Reserve_MQTT2_shelly1_2C79A6 setList off:noArg shellies/shelly1-2C79A6/relay/0/command off\
  on:noArg shellies/shelly1-2C79A6/relay/0/command on\
  x_update:noArg shellies/shelly1-2C79A6/command update_fw\
  x_mqttcom shellies/shelly1-2C79A6/command $EVTPART1

setstate 233_Reserve_MQTT2_shelly1_2C79A6 off
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 fw_ver 20200122-090220/v1.5.9@4b657c90
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 id shelly1-2C79A6
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 ip 192.168.188.233
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 mac 3C71BF2C79A6
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 new_fw false
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:16 online true
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:35 relay0 on
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:16:51 state off


Grüße von Gundermann
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Februar 2020, 15:18:21
Hmm,

das sollte vermutlich zu lösen sein mit einem setStateList-Attribut (on off toggle), das scheint auch bei einigen anderen Device-Typen noch zu fehlen (wundert mich, dass das bisher noch keinem aufgefallen ist, und freut mich, weil Rudi erst nicht so überzeugt war, dass man "sowas" braucht bzw. es jemand außer mir haben will)...

(Ein RAW, das zum "Zeitpunkt des Problems" "geschossen" worden wäre, wäre vermutlich noch aufschlußreicher gewesen, hier schien aber alles ok zu sein, das Device war jedenfalls online).

Grüße
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 05 Februar 2020, 15:54:32
Hallo Beta-User,

(Ein RAW, das zum "Zeitpunkt des Problems" "geschossen" worden wäre, wäre vermutlich noch aufschlußreicher gewesen, hier schien aber alles ok zu sein, das Device war jedenfalls online).

... liefere ich hiermit nach:

defmod 233_Reserve_MQTT2_shelly1_2C79A6 MQTT2_DEVICE shelly1_2C79A6
attr 233_Reserve_MQTT2_shelly1_2C79A6 IODev MQTT2_FHEM_Server
attr 233_Reserve_MQTT2_shelly1_2C79A6 devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $show = '<a href="';;;;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;;;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";;;; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }
attr 233_Reserve_MQTT2_shelly1_2C79A6 event-on-change-reading .*
attr 233_Reserve_MQTT2_shelly1_2C79A6 model shelly1
attr 233_Reserve_MQTT2_shelly1_2C79A6 readingList shellies/shelly1-2C79A6/relay/0:.* state\
  shellies/shelly1-2C79A6/relay/0:.* relay0\
  shellies/shelly1-2C79A6/input/0:.* input0\
  shellies/shelly1-2C79A6/online:.* online\
  shellies/shelly1-2C79A6/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shelly1-2C79A6...mac.*, ? json2nameValue($EVENT) : undef }
attr 233_Reserve_MQTT2_shelly1_2C79A6 room MQTT2_DEVICE
attr 233_Reserve_MQTT2_shelly1_2C79A6 setList off:noArg shellies/shelly1-2C79A6/relay/0/command off\
  on:noArg shellies/shelly1-2C79A6/relay/0/command on\
  x_update:noArg shellies/shelly1-2C79A6/command update_fw\
  x_mqttcom shellies/shelly1-2C79A6/command $EVTPART1

setstate 233_Reserve_MQTT2_shelly1_2C79A6 on
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 fw_ver 20200122-090220/v1.5.9@4b657c90
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 id shelly1-2C79A6
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:08 input0 1
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 ip 192.168.188.233
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 mac 3C71BF2C79A6
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:06 new_fw false
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:46:48 online false
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 14:45:18 relay0 off
setstate 233_Reserve_MQTT2_shelly1_2C79A6 2020-02-05 15:47:45 state on


Grüße von Gundermann
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Februar 2020, 16:05:58
...wie vermutet...

Aber nachdem ich schon über dein Problem nachgedacht hatte und einen Test bzw. einen Lösungsansatz vorgeschlagen, würde mich eigentlich das Ergebnis des Tests mehr interessieren  ;) ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Gundermann am 05 Februar 2020, 20:24:51
@ Beta-User

Ich nehme an, du beziehest dich jetzt auf deinen Vorschlag
Zitat... liest du mal in der commandref den Eintrag zu iconPath bei FHEMWEB, mMn. kann man das, was du möchtest, besser erreichen durch ein eigenes Verzeichnis mit eigenen Dateien namens "on.xyz" usw., das mit der höchsten Prio durchsucht werden soll. Das wirkt dann nämlich systemweit, ohne dass man irgendwelche Änderungen an einzelnen Devices vornehmen müßte...

Ja, ich bin sicher, dass es so funktionieren würde, weil es ja eigentlich auch schon so ist. Aber das ist nicht mein Ziel. Dann gäbe es zwar andere, aber trotzdem immer wieder gleiche Symbole. Wenn ein Aktor eine Lampe ein- und ausgeschaltet, sind eine gelbe Glühbirne für "on" und eine transparente für "off" bestimmt geeignete und intuitive Symbole. Wenn ich aber mit dem Aktor das Ladegerät meines fliegenden Teppichs ansteuere, dann eben nicht. Deshalb finde ich es für meine Anwendungen angemessener (und mache mir auch gerne die Mühe), die einzelnen Devices anzupassen und weiß dank der helfenden Köpfe in diesem Forum nun auch wie das geht.

Danke und Grüße von Gundermann
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 06 Februar 2020, 08:41:17
Zitat von: Gundermann am 05 Februar 2020, 20:24:51
Ich nehme an, du beziehest dich jetzt auf deinen Vorschlag
No. Auf diesen:
Zitat von: Beta-User am 05 Februar 2020, 15:18:21
setStateList-Attribut (on off toggle)

ZitatAber das ist nicht mein Ziel. [...]
Ok, leuchtet ein, ich habe nur keine Idee, wie man das am einfachsten vermitteln kann. Geht nur über Einarbeiten in den recht "knackigen" Perl-Code, oder eben, indem man dann die vereinfachte Variante nutzt (ggf. iVm. mit der "Multiline"-stateFormat-Lösung für die Anzeige mehrerer Symbole), die aber dann nicht einfach so auf externe Webseiten (das Web-Interface des ESP) verlinkt. Das war hier aber mehrheitlich gewünscht (Siehe ca. Beiträge 300-500 in diesem Thread und ein paar andere Stellen...), sonst gäbe es jetzt fast überall die einfache Variante und die komplexe nur als "Demo"...

(Meiner persönlichen Ansicht nach könnte man das update-Thema bequem mit dem Zentraldevice "abfrühstücken" und Funkprobleme (LWT) über einen Eventhandler/eine Readingsgroup, die nur "Problematische Devices" anzeigt ... mitteilen/visualisieren.)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ripperle am 08 Februar 2020, 19:56:48
Wollte gerade mein shelly2.5 in fhem rein holen aber ich sehe das passende template nicht?

Wie wird dass shelly2.5 als korrektes MQTT2_DEVICE angelegt? sehe nur shelly1 als template?  :o

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 08 Februar 2020, 20:04:15
Siehe https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F

Wenn du da nicht die passende Info findest: Bitte ein list von dem von autocreate angelegten Device... (Oder: wie hast du das MQTT2_DEVICE erstellt?).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ripperle am 09 Februar 2020, 18:10:59
Ja das ich es mit autocreate erstellen kann bzw. muss habe ich in der Zwischenzeit auch raus gefunden...

Also ich muss sagen diese template geschichte beim mqtt2 sollte dringend mal vernünftig dokumentiert werden. Man findet nur gestreut teilsrichtige oder aktuelle Infos...

Wie man das shelly 2.5 ohne autocreate anlegen kann, konnte ich immernoch nicht rausfinden...

P.S.
Und zum Thema autocreate. Ich benutze diese Funktion sehr ungern da oft sehr merkwürdige Dinge passieren, so auch gestern beim anlegen des shelly2.5.
Nachdem autocreate das device angelegt hatte habe ich noch ein shelly 1 eingebunden. Es wurde dann im shelly2.5 auf einemal die readings vom shelly1 eingetragen... Habe ich dann händisch wieder raus gelöscht und schnell Autocreate aus gemacht...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 09 Februar 2020, 18:28:26
Hey u guten Abend,

alles was du geschrieben hast spricht dafür, dass du dich DRINGEND in die fhem Basic einlesen solltest.

Nur als Beispiel... Geräte die via mqtt 2 Server in fhem eingebunden werden und via autocreate rein laufen - bekommen einen Namen. Sollte der doppelt sein, hast du eben Namen doppelt vergeben. Das kann fhem oder ein anderes System nicht wissen. Dementsprechend laufen verschiedene hardware Geräte in fhem in nur ein software Gerät.

Was die Doku angeht, kannst du gerne helfen :)
An sich ist es aber einfach und außer bei speziellen Dingen, würde ich es auch nur so machen:
- Autocreate an
- Gerät rein laufen lassen
- in das neue Gerät rein klicken, set attr Template xxx
- fertig oder ggf minimal anpassen

Das geht natürlich auf verschiedenen wegen aber nur mal einer als Beispiel.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 09 Februar 2020, 18:37:31
@ripperle
Du kannst es gerne besser dokumentieren... :P

Und wenn du weißt, was du tust, geht auch alles ohne autocreate, auch die gefilterten attrTemplate kann man anwenden, muß dann aber halt wissen, wie der topictree aufgebaut ist bzw. aufgebaut werden muß, um dann die Rückfragen passend zu beantworten. Oder man erstellt ein "rudimentäres" Device, das für die attrTemplate-Erkennung ausreichend ist, in der Regel reicht ein bestimmter readingList-Eintrag (LWT@tasmota, IRGENDEINEN Eintrag, der mit "shellies/" beginnt für die shelly-Geräte). Ist auch nicht schwer, nur eben nicht separat dokumentiert...

(Grummel, das Gemotze finde ich irgendwie ungerecht >:( . Ist schon klar, dass "besser" immer geht, aber zum einen tut autocreate meist, was es soll, jedenfalls, wenn man es "richtig" macht und wenigstens versucht zu verstehen, was da abläuft. Und zum anderen ist die Doku zumindest so, dass gefühlt 80-90% der User positiv überrascht sind, wie intuitiv das alles eigentlich geht.

Wer Verbesserungsvorschläge hat oder direkt verbessern kann und will, ist herzlich willkommen, aber nur Motzen ist ... (such dir was aus!)).
Schönen Abend noch...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: marvin78 am 09 Februar 2020, 18:49:10
Alles gut. Es funktioniert wie es soll. Doku ist prima und mehr als ausreichend. Wer damit nicht zurecht kommt, fällt eben hinten runter. Kann man verschmerzen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 09 Februar 2020, 19:03:01
Das sollte nicht die Botschaft sein!

Vielmehr hilft zu lesen oder sachlich zu fragen. Hatte auch Schmerzen mit dem Gemecker. Wichtig ist eben das man zumindest basics kennt. Du fährst dein Auto ja auch nicht ohne zu wissen wo dir bremse ist (übertrieben aber sollte es verdeutlichen).

Du hast es hin bekommen, sagtest du... Vielleicht hilft dein Lösungsweg einem anderen, der mal das Problem hat. Mich würde sie interessieren..

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 09 Februar 2020, 19:34:23
Zitat...aber nur Motzen ist ... (such dir was aus!)).
Kopf hoch: meiner Erfahrung nach motzen die, die es noch nie selbst gemacht haben, und deswegen nicht wissen, was das bedeutet.
Alle Anderen haben Respekt davor, und helfen mit, oder halten die Klappe :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ripperle am 09 Februar 2020, 20:56:45
Okeeeeeeeey sry für die harten Worte war vllt etwas genervt  ;D

Prinzipiell ist ja alles wunderbar und läuft auch sehr stabil und produktiv...

Ich habe bisher viele zigbee2mqtt Geräte im Einsatz und die habe ich nie über autocreate angelegt...

Diese lege ich immer mit define name MQTT2_DEVICE zigbee
Dann kann man das template auswählen und muss den Namen vergeben und prima...

Genauso wollte ich das auch machen... Anstelle des zigbee am Ende hatte ich dann auch versucht shellies oder shelly oder so einzutragen aber das template wurde net angezeigt.

Wäre für mich immernoch von Interesse wie man bzw ob man ein shelly2.5 device anlegen kann ohne Autocreate...

Gruß

P. S. : sobald mir da jemand helfen kann werde ich dass ins Wiki rein schreiben  :-*
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 09 Februar 2020, 22:25:00
Mich würde interessieren warum du das unbedingt manuell machen willst. Es muss was krum sein wenn es nicht geht. Gerade bei shelly läuft das super. Geht mir am ende nur darum zu verstehen was genau nutzerfreundlicher sein sollte...

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: ripperle am 10 Februar 2020, 06:35:30
Wie gesagt, habe die Erfahrung das manchmal unvohersehbare Sachen passieren bei Auto create...

Es tut schon mit Auto create und ist auch dementsprechend einfach und nutzerfreundlich...

Trotzdem würde ich gerne erfahren ob bzw wie es möglich ist den shelly2.5 ohne Auto create einzubinden...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 Februar 2020, 06:58:09
Ein stürmisches Moin zusammen, hoffe, die Schäden halten sich bei euch in Grenzen...

@ripperle:
Nach dieser Beschreibung würde ich annehnen, dass du MQTT2_CLIENT als IO-Modul nutzt?
Zitat von: ripperle am 09 Februar 2020, 18:10:59
so auch gestern beim anlegen des shelly2.5.
Nachdem autocreate das device angelegt hatte habe ich noch ein shelly 1 eingebunden. Es wurde dann im shelly2.5 auf einemal die readings vom shelly1 eingetragen...
Dann wäre das die Erklärung dafür, dass ALLES in einem Device landet... Abhilfevorschlag findet man im Wiki: https://wiki.fhem.de/wiki/MQTT2_CLIENT (https://wiki.fhem.de/wiki/MQTT2_CLIENT) (ist auch in den Praxisbeispielen verlinkt...)

Zitat von: ripperle am 10 Februar 2020, 06:35:30
Trotzdem würde ich gerne erfahren ob bzw wie es möglich ist den shelly2.5 ohne Auto create einzubinden...
Auch diese Frage war bereits beantwortet. Es geht! Und zwar sogar auf zwei Wegen:
Zitat von: Beta-User am 09 Februar 2020, 18:37:31
Und wenn du weißt, was du tust, geht auch alles ohne autocreate, auch die gefilterten attrTemplate kann man anwenden, muß dann aber halt wissen, wie der topictree aufgebaut ist bzw. aufgebaut werden muß, um dann die Rückfragen passend zu beantworten. Oder man erstellt ein "rudimentäres" Device, das für die attrTemplate-Erkennung ausreichend ist, in der Regel reicht ein bestimmter readingList-Eintrag (LWT@tasmota, IRGENDEINEN Eintrag, der mit "shellies/" beginnt für die shelly-Geräte). Ist auch nicht schwer, nur eben nicht separat dokumentiert...
Etwas "mundgerechter" formuliert:
- ein Device xyz anlegen und dann _via Kommandozeile_ "set xyz attrTemplate <gewünschtes template>" + Fragen korrekt beantworten, oder
- ein Device xyz anlegen, die Angaben manuell setzen, die für die Auswertung der Parameter genutzt werden (die par-Angaben in der attrTemplate-file, die du bitte selbst suchst..., Erläuterung hier: https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F (https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F))

Zitat von: ripperle am 09 Februar 2020, 18:10:59
Habe ich dann händisch wieder raus gelöscht und schnell Autocreate aus gemacht...
Die von attrTemplate ausgewerteten Angaben (readingList-Einträge...) hättest du u.A. dann auch in dem "Sammeldevice" gefunden und einfach in das händisch erstellte Device reinkopieren können...

Noch eine abschließende Bitte:
Versuche zukünftig auch die Teile von Beiträgen potentiell kompetenter Helfer zu verstehen, die sich dir nicht auf Anhieb erschließen und frage ggf. konkret nach, was mit bestimmten Sätzen gemeint ist, wenn (!) was tatsächlich nach etwas nachdenken/nachforschen (!) noch unklar sein sollte. Es macht nämlich immer noch keinen Spaß, Dinge mehrfach zu schreiben, ohne dass sich die Frage geändert hat...

(@Rudi, marvin78 & 87insane: Danke für die Rückmeldungen. Alles gut, auch jetzt noch ;) )
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: DasQ am 13 Februar 2020, 16:17:22
Meine Erfahrung ist, wer ständig von Hand sinnlos Zeug löscht, nicht speichert, oder rebootet, handelt sich unweigerlich, ,,merkwürdige Dinge" ein.


Fhemverzeiht da nix und das ist auch gut so. ;D :o
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 20 Februar 2020, 07:26:00
Guten Morgen Zusammen,

hat einer von Euch schon versucht einen mit Tasmota geflashten Shelly RGBW2 über MQTT an den FHEM MQTT2 Server zu binden?
Habe da so meine Probleme!

Zum einen (OT), denke ich ist auf dem Gerät etwas in Tasmota nicht korrekt eingestellt. Denn ich habe keine Slider sondern nur an/aus für die vier Kanäle. Sieht aus wie bei einem vier-Kanal Sonoff mit Tasmota.
Zum anderen geht aber selbst das nicht über FHEM.

Habe leider aktuell nur die def und kein LIST. Denke aber das es eh an Tasmota liegt, wollte hier nur mal fragen, da es nicht mein Gerät ist. Ich selber habe keine RGBW2 mit Tasmota im Einsatz.

define MQTT2_DVES_B0D1FD MQTT2_DEVICE DVES_B0D1FD
setuuid MQTT2_DVES_B0D1FD 5e4c1596-f33f-716e-ba23-2baeac7a9714d067
attr MQTT2_DVES_B0D1FD IODev MQTT2_FHEM_Server
attr MQTT2_DVES_B0D1FD alexaName Shelly RGBW2
attr MQTT2_DVES_B0D1FD alias Shelly RGBW2
attr MQTT2_DVES_B0D1FD autocreate 0
attr MQTT2_DVES_B0D1FD comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/cmnd/Shelly_RGBW2/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr MQTT2_DVES_B0D1FD devStateIcon {Color::devStateIcon($name,"rgb","Color","pct","state")}
attr MQTT2_DVES_B0D1FD genericDeviceType light
attr MQTT2_DVES_B0D1FD icon light_led
attr MQTT2_DVES_B0D1FD jsonMap POWER1:0 Dimmer:pct Channel_4:white Channel_1:0 Channel_2:0 Channel_3:0 HSBColor:0
attr MQTT2_DVES_B0D1FD model tasmota_rgbw_led
attr MQTT2_DVES_B0D1FD readingList tele/Shelly_RGBW2/LWT:.* LWT\
  tele/Shelly_RGBW2/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Shelly_RGBW2/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Shelly_RGBW2/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/Shelly_RGBW2/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/Shelly_RGBW2/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/Shelly_RGBW2/POWER1:.* state
attr MQTT2_DVES_B0D1FD room Licht,MQTT2_DEVICE
attr MQTT2_DVES_B0D1FD setList off:noArg cmnd/Shelly_RGBW2/POWER1 0\
  on:noArg cmnd/Shelly_RGBW2/POWER1 1\
  toggle:noArg cmnd/Shelly_RGBW2/POWER1 2\
  Color:colorpicker,RGB cmnd/Shelly_RGBW2/COLOR\
  pct:colorpicker,BRI,0,5,100 cmnd/Shelly_RGBW2/DIMMER\
  white:colorpicker,BRI,0,5,100 { "cmnd/Shelly_RGBW2/COLOR ". sprintf("000000%02X",$EVTPART1*2.55) }
attr MQTT2_DVES_B0D1FD webCmd pct:white:Color
attr MQTT2_DVES_B0D1FD webCmdLabel Helligkeit\
:Weiss\
:Farbe:


Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 20 Februar 2020, 07:46:24
Ich habe den Shelly zwar auch nicht, aber vermutlich wurde da ein anderes (tasmota-(!)) template (nicht FHEM-attrTemplate) ausgewählt, das den intern als 4-kanaligen Switch konfiguriert und nicht als RGBW-Dimmer mit 4 (Farb-) Kanälen.

Ist aber hier OT, bitte @tasmota (oder Bastelecke) nachfragen, welches der tasmota-templates das richtige für RGBW-Betrieb ist.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Ullulaki am 21 Februar 2020, 19:20:43
Moin,

ich muss einmal ganz doof fragen, da ich auch mit der Forensuche keine passende Antwort finde:
Wie bekomme ich meinen Shelly1 mit Tasmota richtig eingebunden?
Ich habe tasmota_basic und basic_state_power probiert, aber die Befehle kommen nicht an. :-/
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 21 Februar 2020, 19:47:47
Mit MQTT2_SERVER als IODev kann man schummeln: subscriptions muss zu setList passen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Ullulaki am 21 Februar 2020, 21:10:04
Zitat von: rudolfkoenig am 21 Februar 2020, 19:47:47
Mit MQTT2_SERVER als IODev kann man schummeln: subscriptions muss zu setList passen.

danke, jetzt funktioniert es. :-)

Aber eine Problematik, komischerweise bei allen Tasmota-Devices:
Wenn ich über FHEM on/off schalte funktioniert alles.
Schalte ich allerdings das jeweilige Device über das Web-UI findet keine Statusänderung in FHEM statt.
Finde auch in der Doku nichts dazu, oder habe ich einfach einen Denkfehler?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 22 Februar 2020, 15:10:48
Wärt ihr so freundlich, Tasmota-Themen bitte in einem der Tasmota-Threads zu beackern oder einen neuen anzufangen?

(Ich bin mir aber ziemlich sicher, dass wir genau das Thema bzw. Variationen davon schon mehrfach hatten - und dass die Lösung in den "Praxisbeispielen" zu finden ist - nur eben unter Tasmota!) (Und nein, ich werde dazu keine weiteren Auskünfte in diesem Thread erteilen, was genau gemeint sein könnte...).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Ullulaki am 23 Februar 2020, 13:43:48
Zitat von: Beta-User am 22 Februar 2020, 15:10:48
Wärt ihr so freundlich, Tasmota-Themen bitte in einem der Tasmota-Threads zu beackern oder einen neuen anzufangen?

(Ich bin mir aber ziemlich sicher, dass wir genau das Thema bzw. Variationen davon schon mehrfach hatten - und dass die Lösung in den "Praxisbeispielen" zu finden ist - nur eben unter Tasmota!) (Und nein, ich werde dazu keine weiteren Auskünfte in diesem Thread erteilen, was genau gemeint sein könnte...).

okay, sorry  ::) :-[

Ich hoffe es ist als Schlusswort noch okay, wenn ich für Andere kurz die Lösung poste bzw. wo ich sie gefunden habe:
Unter folgendem Link bei MQTT2-Device angeschaut und adaptiert, jetzt geht es:
https://forum.fhem.de/index.php?topic=90220.0

Genauergesagt der Part ist notwendig:
attr DEVICE userReadings state {ReadingsVal($name,"POWER","")}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 23 Februar 2020, 19:23:36
Zitat von: Ullulaki am 23 Februar 2020, 13:43:48
Ich hoffe es ist als Schlusswort noch okay, wenn ich für Andere kurz die Lösung poste bzw. wo ich sie gefunden habe:
Nein, ist nicht iok.
1. Ist es immer noch kein Shelly-template-Thema.2. geht der Link "irgendwohin" in einem vielseitigen Thread => nicht hilfreich, oder...?
3. Ist das mit einiger Sicherheit nur "erforderlich", weil du das "falsche" attrTemplate zuletzt angewendet hattest.

Also: Wenn du Fragen oder Anmerkungen zu attrTemplate zu TASMOTA hast, nutze bitte einfach den richtigen Thread dazu, da bekommst du ggf. Hilfe (auch von mir) und keine tendenziell kryptischen Zwischenrufe...
(Genau zwei (!) Beiträge vorher war schon jemand falsch... Muß doch nicht sein, oder?!)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: flummy1978 am 31 März 2020, 23:54:03
Hallöchen,

Verzeiht es mir bitte, wenn es irgendwo in der Zwischenzeit erwähnt sein sollte (hab jetzt nicht die kompletten 40 Seiten gelesen):

Ich weiss nicht ob es jemand schon in Erwägung gezogen hat, oder es einbinden möchte, aber bei dem Shelly Dimmer Template gibt es ja keine Möglichkeit nach Einschalten schrittweise die Stufen hoch / runter zu dimmen. Falls es jemand in ein Template einbinden möchte, (geht sicher noch eleganter, aber das ist für mich die einzige funktionierende Art. Wenn oder hier sucht ist es sicherlich nicht falsch angebracht:

Die beiden betreffenden Bereiche die man ergänzen muss: (2 Zeilen in Setlist)
dimmup:noArg { my $num=ReadingsNum($NAME,'pct',0)+10;; "shellies/Bad_OG_dimmer/light/0/set \{\"turn\": \"on\", \"brightness\": $num\}";; }
dimmdown:noArg { my $num=ReadingsNum($NAME,'pct',0)-10;; "shellies/Bad_OG_dimmer/light/0/set \{\"turn\": \"on\", \"brightness\": $num\}";; }

Damit hat man 2 Befehle "dimmup" und "dimmdown" der dann in 10er Schritten weiterspringt (auch von 13 auf 23 oder 87 auf 77)

Noch eleganter (für mich) waren zwei zusätzliche devstateicons, die dann hoch und runter dimmen lassen: (stateFormat)

{
my $z1 = int(ReadingsVal($name,"pct",0)/10)*10+10;
my $z2 = ReadingsVal($name,"ison","false") eq "true"?"light_light_dim_".int(ReadingsVal($name,"pct",0)/10)*10:"off";
my $z3 = int(ReadingsVal($name,"pct",0)/10)*10-10;
return "up$z1\n$z2\ndown$z3";
}


Damit sieht das State dann so aus:
up30
light_light_dim_20
down10
und man kann mit entsprechdem devstateicon das Ganze lösen.

Falls es jemandem weiterhilft freut mich das sehr ..... wenn unerwünscht bitte löschen :) (oder sagen wo ich es posten kann / soll)

Viele Grüße
Andreas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 01 April 2020, 10:57:50
Habe mal den sL-Vorschlag als "dimUp" bzw. "dimDown" eingebaut. Damit sollte man durch ein "einfaches" mehrzeiliges devStateIcon fast denselben Effekt erzielen können (aber ohne Rundung, ggf. muß die Schreibweise noch angepaßt werden).

Ich hoffe mal sehr, dass der Shelly bei 109% dann eben auch ein 100% liefert (bzw. 0% bei -8) und nichts seltsames anstellt ;D .

Da im Template der dimmer-slider drin ist, wollte ich das UI nicht ebenfalls via Template "zwangsweise" erweitern.

Ansonsten bist du hier schon richtig, wobei das mit dem dreifachen Icon (evtl. in der einfacheren Form mit den "icon-kompatiblen" (?) settern) ganz gut ins Wiki passen könnte.

ÜBERHAUPT:
Vor "langem" habe ich mal einen Wiki-Artikel gebastelt: https://wiki.fhem.de/wiki/DeviceOverview_anpassen
Damals hatte ich verwendet, was grade verfügbar war... heute würde ich sagen: "suboptimal".

Daher: Hat jemand Lust, die vollständige Konfiguration eines MQTT2_DEVICE "zu Fuß" Schritt für Schritt zu erläutern? Ist zwar mit setList und readingList etwas "speziell", aber sonst...? Mein Lieblingsdevice dabei wäre ein einkanaliger Shelly mit Strommeß-Funktion (oder erst ein Kanal aus einem Mehrkanaligen und dann als "Bonus" die weiteren Kanäle). Im Ergebnis darf dann gerne rauskommen, was auch ein attrTemplate machen würde, man muß also nix erfinden, aber eben z.B. ein paar Screenshots machen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 03 April 2020, 11:21:04
Hallo zusammen,
zuerst einmal ihr habt hier ja schon großartiges geleistet. Ich habe meinen Shelly Dimmer über mqtt2 blitzschnell einrichten können.
In FHEM tut er auch alles was er soll, leider gibt es via Homebridge in Apple Home zwei Fälle die nicht funktionieren bzw. wo in Apple Home der Status nicht richtig upgedatet wird.

Fall1: Der Dimmer wurde via Apple Home oder FHEM eingeschaltet. Schalte ich den dimmer nun direkt am Schalter aus updatet auch der Status in FHEM, aber nicht in Apple Home.

umgekehrt dazu

Fall2: Der Dimmer ist ausgeschaltet, Schalte ich den dimmer nun direkt am Schalter ein updatet auch der Status in FHEM, aber nicht in Apple Home.

Apple Home ist bei mir die "Enduser GUI" mit dem besten WAF, daher will ich auch dort alles richtig dargestellt haben. Zum Beispiel für en Fall2 müsste ich dann in Apple Home den Dimmer erst einmal anschalten (obwohl er ja tatsächlich schon an ist) um ihn dann via Apple Home ausschalten zu können.

Ich habe den Dimmer über das Template eingerichtet und kein zusätzliches homebridge Mapping aktiv.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 April 2020, 11:30:17
Vorab mal Danke für das Feedback - auch im Namen aller, die hier und anderswo ihren Inut geliefert haben, damit das läuft wie es läuft :) .

Was das Sprachsteuerungsthema angeht: Aktuelles template verwendet? Fragen (sireName usw.) beantwortet?
Oder ging da was schief?

(MaW: ein "list -r" wäre - wie meistens - förderlich, um die Glaskugel vorher zu putzen...).

Wenn das in diesen Basisangaben grundsätzlich paßt, ist es m.E. kein Problem, das wir hier in diesem Rahmen lösen können. Das wäre dann vermutlich besser im Sprachsteuerungsbereich aufgehoben.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 03 April 2020, 12:13:11
ZitatIch habe den Dimmer über das Template eingerichtet und kein zusätzliches homebridge Mapping aktiv.

Zeig doch mal deine jetzige Definition, weil hier (https://forum.fhem.de/index.php/topic,48558.msg1038056.html#msg1038056) war noch ein merkwürdiges homebridgeMapping aktiv.
Hab die Zusammenhänge auch noch nicht ganz verstanden, bin aber der Meinung zu sehen das wir das hier gemeinsam lösen können, vermutlich ? ohne homebridgeMapping.

Gruß

Thomas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 April 2020, 12:50:35
@TomLee: Danke für die Rückkoppelung.

@stratege-0815:

Wenn ich schlechtgelaunter Moderator hier in diesem Bereich wäre, würde ich mir jetzt überlegen...

Kurz:
Cross- und Doppelpostings sind an sich sch..., und vielleicht noch tolerabel, wenn man das entsprechend kennzeichnet. Aber ohne Hinweis, grade mal 20 Min. nach dem anderen Post? Finde jedenfalls ich "nicht gut"...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: flummy1978 am 03 April 2020, 17:19:27
Holla,

freut mich, dass ich mit meinem Beispiel zur Bequemlichkeit / Funktionserweiterung dazu beitragen konnte  ( Ich glaube das dürfte meine erste "Verwendung" in einem offiziellem Modul sein  ::) )

Bin nicht sicher ob ich das wirklich richtig verstanden habe:
Zitat von: Beta-User am 01 April 2020, 10:57:50
Daher: Hat jemand Lust, die vollständige Konfiguration eines MQTT2_DEVICE "zu Fuß" Schritt für Schritt zu erläutern? Ist zwar mit setList und readingList etwas "speziell", aber sonst...? Mein Lieblingsdevice dabei wäre ein einkanaliger Shelly mit Strommeß-Funktion (oder erst ein Kanal aus einem Mehrkanaligen und dann als "Bonus" die weiteren Kanäle). Im Ergebnis darf dann gerne rauskommen, was auch ein attrTemplate machen würde, man muß also nix erfinden, aber eben z.B. ein paar Screenshots machen.[/b]
Ich kann mir nicht vorstellen, dass viele die Geräte von Hand anlegen *grübel*

Ehrlicherweise glaube ich, dass viele (Anfänger) dort so handeln werden wie ich das auch gemacht habe:
Template benutzen, rausschmeissen was man nicht braucht und ggf erweitern. Ich finde die Template sehr sehr sinnvoll und bedingt dadurch, dass man am Anfang nicht weiß was man alles braucht, sehr hilfreich.

Falls ich Blödsinn verstanden habe, bitte nochmal um Erklärung ;)

Viele Grüße
Andreas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 April 2020, 17:38:51
Na ja, mein Gedanke ist folgender:

Viele haben Schwierigkeiten was nach ihren Vorstellungen umzukonfigurieren. Dann fangen sie "irgendwo" an - "lustigerweise" sehr häufig am falschen Ende...

Eine _mögliche_ Ursache ist die, dass (noch) nirgends so richtig erklärt wird, wie die Dinge aufeinander aufbauen. Das ist in weiten Teilen eigentlich gar nicht MQTT2_DEVICE-spezifisch, sondern (jedenfalls zu großen Teilen) eigentlich bei jedem FHEM-Device "gleich". Und mein damaliger Versuch im Wiki geht zwar in diese Richtung, war aber nicht optimal, weil diese HM-Teile nicht so verbreitet sind wie heute die Shelly (oder Tasmota)...

Das soll also dazu dienen, an einem Gerät, mit dem die User "vertraut sind" zu Erläutern, was attrTemplates (im Ergebnis) machen - so kann man die Zusammenhänge besser verstehen und dann auch auf andere Geräte übertragen (und zwar in der richtigen Reihenfolge...). (Und gerade wegen der attrTemplate kann man ja auch immer wieder zurück auf einen definierten Zustand, das fördert hoffentlich den Spieltrieb ;D ).

Ansonsten bin ich sehr froh, dass die Devise "Template anwenden, fertig das Gericht" gelebte Praxis ist und habe auch keine Pläne, das nicht weiter in diese Richtung zu supporten :) .

Nun klarer, was mein Gedanke dabei ist?

(Falls jetzt die Frage kommt: warum nicht mit einem Tasmota?
Weil man den Shelly "as is" verwenden kann - ist ein typisches Einsteigergerät. Microcontroller umzuprogrammieren ist meistens nicht grade der Start in die FHEM-Welt...
Und wir brauchen irgendwie wieder eine aktuelle Einsteigerdoku, oder sehe ich das falsch?)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 03 April 2020, 18:42:29
Hallo zusammen,
ja, ihr habt Recht. Das war nicht gut doppelt zu posten - sorry dafür. :-[

Ich habe das Thema hier "zusätzlich" gepostet weil ich es hier besser aufgehoben glaubte. Das MQTT Template macht wirklich einen super Job und bis auf die genannte Einschränlung geht auch alles auf Anhieb direkt ohne homebridge-mapping. Daher dachte ich auch es hier eher lösen zu können.

Zitat von: TomLee am 03 April 2020, 12:13:11
[...]bin aber der Meinung zu sehen das wir das hier gemeinsam lösen können, vermutlich ? ohne homebridgeMapping.[...]

Das war dabei auch meine Idee, je weniger Mapping um so besser.

Gerne versuche ich hier noch einmal das Problem zu schildern und liefere hier das gewünschte "list -r".


define Dimmer_Schlafzimmer MQTT2_DEVICE shellydimmer_D45DA1
attr Dimmer_Schlafzimmer IODev myMQTT2_SERVER
attr Dimmer_Schlafzimmer devStateIcon {my $lderr = ReadingsVal($name,"loaderror","true") eq "true"?"10px-kreis-rot":"10px-kreis-gruen";;;; my $light = ReadingsVal($name,"ison","false") eq "true"?"on":"off";;;; my $cons = ReadingsVal($name,"light_0_power","unknown");;;; FW_makeImage($lderr)."<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Leistung: $cons</div>"}
attr Dimmer_Schlafzimmer genericDeviceType light
attr Dimmer_Schlafzimmer icon light_control
attr Dimmer_Schlafzimmer jsonMap brightness:pct
attr Dimmer_Schlafzimmer model shellydimmer
attr Dimmer_Schlafzimmer readingList shellies/shellydimmer-D45DA1/light/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
  shellies/shellydimmer-D45DA1/temperature:.* temperature\
  shellies/shellydimmer-D45DA1/temperature_f:.* temperature_f\
  shellies/shellydimmer-D45DA1/overtemperature:.* overtemperature\
  shellies/shellydimmer-D45DA1/overload:.* overload\
  shellies/shellydimmer-D45DA1/loaderror:.* loaderror\
  shellies/announce:.* { $EVENT =~ m,..id...shellydimmer-D45DA1...mac.*, ? json2nameValue($EVENT) : undef }\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/online:.* online\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/announce:.* { json2nameValue($EVENT) }\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0:.* light_0\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0/power:.* light_0_power\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0/energy:.* light_0_energy\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/input/0:.* input_0
attr Dimmer_Schlafzimmer room Homekit,MQTT,Schlafzimmer
attr Dimmer_Schlafzimmer setList off:noArg shellies/shellydimmer-D45DA1/light/0/command off\
  on:noArg shellies/shellydimmer-D45DA1/light/0/command on\
  pct:slider,0,1,100 shellies/shellydimmer-D45DA1/light/0/set {"turn": "on","brightness": $EVTPART1}\
  x_mqttcom shellies/shellydimmer-D45DA1/command $EVTPART1
attr Dimmer_Schlafzimmer webCmd pct:on:off

setstate Dimmer_Schlafzimmer off
setstate Dimmer_Schlafzimmer 2020-03-31 21:37:31 brightness 20
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 fw_ver 20200309-104554/v1.6.0@43056d58
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 has_timer false
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 id shellydimmer-D45DA1
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:54 input_0 0
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 ip 192.168.1.62
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 ison false
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 light_0 off
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 light_0_energy 854
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 light_0_power 0.00
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 loaderror 0
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 mac F4CFA2D45DA1
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 mode white
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 new_fw false
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 online true
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 overload 0
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 overtemperature 0
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 pct 50
setstate Dimmer_Schlafzimmer 2020-04-03 15:13:12 state off
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 temperature 52.20
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 temperature_f 125.96
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 timer_remaining 0


Zitat von: Beta-User am 03 April 2020, 11:30:17
Was das Sprachsteuerungsthema angeht: Aktuelles template verwendet? Fragen (sireName usw.) beantwortet?
Oder ging da was schief?

Es handelt sich nicht um ein Sprachsteuerungsproblem. Es geht um eine Synchronisierung bestimmter Statusänderungen von FHEM nach Apple Home. (Ich hoffte hier würden vielleicht auch andere Benutzer ihre Shelly Devices über die Apple Oberfläche steuern)

Ich habe hier den Shelly Dimmer mit einem Taster verbunden und den "one button mode" im shelly konfiguriert. Wenn der Dimmer per Tasterdruck am Schalter oder über FHEM eingeschaltet wird wird dieser Status auch in FHEM dargestellt, kommt aber nicht in der Apple Oberfläche an.

Schalte ich über Apple Home den Dimmer ein, stimmt auch dort der Status. Beim Ausschalten über FHEM oder den physischen Schalter passiert dann wieder der gleiche Effekt, in Apple Home wird nicht synchonisiert. Der letzte Status bleibt unverändert.

Ich hoffe ich habe das jetzt verständlich erklärt.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: flummy1978 am 03 April 2020, 20:26:39
Holla,

ein wenig klarer wird es jetzt (glaube) ich schon. Wenn es darum geht den Einsatz des MQTT Templates vorzustellen und mit Screenshots etc zu untermalen, kann ich es gern mal probieren, muss allerdings auch dazu sagen, dass es ein paar Tage dauern kann bis ich dazu komme UND ich auch schon ewig lang keine Dokus / Erklärungen etc geschrieben hab, so dass ich das vorab jemandem Erfahrenem mal in die Hand drücken müsste ;)

Grüße
Andreas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 03 April 2020, 21:09:06
Bin mir nicht sicher, kann mich aber ja jemand verbessern wenn das Käse ist:

Ändere mal

shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0:.* light_0\
zu
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0:.* state\

weiß nicht ob das nötig ist, vorsichtshalber würd ich aber homebridge noch neustarten.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 04 April 2020, 09:29:04
Zitat von: flummy1978 am 03 April 2020, 20:26:39
Holla,

ein wenig klarer wird es jetzt (glaube) ich schon. Wenn es darum geht den Einsatz des MQTT Templates vorzustellen und mit Screenshots etc zu untermalen, kann ich es gern mal probieren, muss allerdings auch dazu sagen, dass es ein paar Tage dauern kann bis ich dazu komme UND ich auch schon ewig lang keine Dokus / Erklärungen etc geschrieben hab, so dass ich das vorab jemandem Erfahrenem mal in die Hand drücken müsste ;)

Grüße
Andreas

Hallo Andreas,
Welche Bilder und Screenshots kann/sollte ich dazu beisteuern?

Ich werde auch dem Hinweis von TomLee noch nach gehen.

Gruß Jan
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 April 2020, 10:15:39
Zitat von: flummy1978 am 03 April 2020, 20:26:39
Holla,

ein wenig klarer wird es jetzt (glaube) ich schon. Wenn es darum geht den Einsatz des MQTT Templates vorzustellen und mit Screenshots etc zu untermalen, kann ich es gern mal probieren, muss allerdings auch dazu sagen, dass es ein paar Tage dauern kann bis ich dazu komme UND ich auch schon ewig lang keine Dokus / Erklärungen etc geschrieben hab, so dass ich das vorab jemandem Erfahrenem mal in die Hand drücken müsste ;)
Muß es wohl nochmal anders erklären:

Es geht NICHT darum, die Anwendung des attrTemplate-features zu zeigen, sondern Attribut für Attribut zu erläutern, welche Wirkung es jeweils funktional und optisch hat. (Teilweise muß man es wohl sogar Zeile für Zeile innerhalb eines Attributs machen, z.B. wenn es um "state" geht...).
Dabei spielt die Reihenfolge eine gewisse Rolle, man muß sich also überlegen, wann welches Element an der Reihe ist usw..

Das ganze muß auch nicht schnell gehen, und screenshots kann man nebenbei machen.

Formal wäre das Ziel, einen Satz Dateien zu haben:
- Den Artikel im Wiki-Quelltextformat (Beispiel: https://wiki.fhem.de/w/index.php?title=DeviceOverview_anpassen&action=edit). Ist ein bißchen "Blindflug", wenn man das noch nie gemacht hat, aber c&p m.E. kein Hexenwerk, notfalls bitte einen Wiki-Zugang beantragen (oder mal schauen, gibt bestimmt irgendwo einen Onlin-Parser, den man nutzen kann)...
- Die zugehörigen screenshots/Bilder. Da wäre eine  sinnvolle Namensvergabezu überlegen, dass es im "Wiki-Namespace" auch halbwegs klar ist, für was das "media"-Element steht.
- "Super-addon" wäre, ggf. das ganze noch mit dem als Beispielartikel genannten irgendwie zu "verbinden", genaue Vorstellungen wie, habe ich noch nicht, das bleibt ggf. auch eurer Fantasie überlassen (einfacher Link, einige (optische?) Teile hier, andere (funktionale?) da...

Nochmal: Das ganze soll möglichst so sein, dass ein Anfänger ohne große FHEM-Kenntnisse, wie wir sie alle mal waren, das einfach nachbauen kann und hoffentlich den einen oder anderen "aha"-Effekt hat...
(Wenn erfahrenere diesen Aha-Effekt auch haben: umso besser...)

Ich schau dann gerne nochmal drüber, auch bei Zwischenversionen, kein Ding :) .

Jetzt klarer?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: flummy1978 am 04 April 2020, 12:48:19
Moinsen,

japp jetzt ist es um einiges klarer geworden. Da muss ich aber sagen, dass ich in diesem Fall tatsächlich der falsche Ansprechpartner wäre. In manchen Bereichen komme ich selbst kaum klar mit der Funktion und bin froh dass diese vorgegeben ist. Andere Bereiche wiederum les ich etwas dazu bis ich es verstehe und passe es dann an (wie zB die dimmUp dimm Down Funktion).

Ansonsten sieht meine Vorgehensweise bei allen (MQTT) Geräten so aus:

Gerät einbinden -> Autocreate abwarten -> erstelltes Log löschen -> überlegen was ich an dem Gerät alles angezeigt / geloggt /etc werden soll -> Template auswählen laden und testen -> Events etc anpassen -> devStateIcon anpassen ... fertig. Bisher habe ich fast nie was vermisst. Wenn doch, hab ich ne Lösung gefunden wie ich das lösen könnte. Anfängerfreundlich Alle Attribute Schritt für Schritt erklären und auswählen, das würde ich mir dann leider doch nicht zutrauen ;(  - Dafür bi ich einfach selbst zu viel Anfänger....

Viele Grüße
Andreas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 April 2020, 13:19:20
...es war nur eine Frage, und du darfst selbstredend "nein" sagen.

Ich behaupte aber mal, dass dich das zwar einige Zeit kosten wird, du aber selbst einen großen benefit davon haben würdest, weil dann die Dinge wirklich klar wären... (Die Basics hast du nach meinem Eindruck soweit "drauf", dass das klappt (nicht ohne Frust, klar, aber im Ergebnis...))
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 April 2020, 16:29:44
Hallo zusammen...

(Vermutlich) seit dem letzten shelly Firmware Update, kann ich meine shelly rgbw2 nicht mehr sauber über fhem schalten. Der komplette RGB Bereich macht nix. Im shelly selber geht es.

Der setlist Eintrag ist:
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-661CD3/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-661CD3/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}

Der string aber auf dem Zweig:
{"ison":true,"has_timer":false,"timer_remaining":0,"mode":"color","red":13,"green":215,"blue":255,"white":0,"gain":100,"effect":0,"power":10.10,"overpower":false}

Glaube hier wurden nur die werte (hex/RGB) angepasst oder?

Edit: https://shelly-api-docs.shelly.cloud/#shelly-rgbw2-mqtt

So hätte er es gern laut doku:
{ "mode": "color", /* "color" or "white" */
"red": 0, /* red brightness, 0..255, applies in mode="color" */
"green": 0, /* green brightness, 0..255, applies in mode="color" */
"blue": 255, /* blue brightness, 0..255, applies in mode="color" */
"gain": 100, /* gain for all channels, 0..100, applies in mode="color" */
"white": 0, /* white brightness, 0..255, applies in mode="color" */
"effect": 0, /* applies an effect when set */
"turn": "on" /* "on", "off" or "toggle" */ }

Da kann man im mqtt Teil auch nochmal alles sehen. Entweder steh ich gerade auf dem Schlauch oder verstehe was komplett falsch.

Gesendet von meinem LM-G810 mit Tapatalk
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 05 April 2020, 14:10:26
Mit den Werten ist Quark. Aber ich kann am handy nicht ausreichend testen um heraus zu finden warum das nun nicht mehr geht. Nach ein paar Tests die ich machte, denke ich das der string einfach geändert wurde?(Reihenfolge)

Leider haben die shellys keine Konsole wie zb tasmota. Sonst würde ich auf anderer Seite ja direkt sehen warum es nicht mehr klappt.

Will kein Mitleid aber kann leider noch nicht mehr als 5 sitzen nach der knie OP. Somit setze ich gerade auf euch, am pc :)

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: flummy1978 am 09 April 2020, 12:24:58
Moinsen,

habe Beta-Users Wunsch entsprochen und einen anderen Ausdruck getestet. Zusätzlich ist weiter unten eine (ergänzende) Möglichkeit aufgeführt....

Zitat von: Beta-User am 07 April 2020, 16:34:02
@flummy1978: Evtl. magst du den setter für den shelly nochmal kritisch beäugen, zwei Dinge sind mir noch unklar:
- gibt es nette Symbole, wenn man z.B. webCmd mit dimUp:dimDown ergänzt? (sonst müßte man das so umbenennen, dass FHEMWEB das automatisch richtig macht)
- Sind die "\" erforderlich oder nur "Hosenträger und Gürtel kombiniert" - ich meine eigentlich, das sollte ohne gehen bzw. (jüngst gelernt) mit einer "qq"-Anweisung einfacher:
dimUp:noArg { my $num=ReadingsNum($NAME,'pct',0)+10;; return qq{shellies/DEVNAME/light/0/set {"turn": "on", "brightness": $num}};; }
Funktioniert genau wie gewünscht und macht alles was es soll. Zusätzlich ist es etwas übersichtlicher vom Quellcode her. Hat aber Verbesserungspotential:

dimUp:noArg { my $num=ReadingsNum($NAME,'pct',0)+10; return qq {shellies/DEVNAME/light/0/set {"turn": "on", "brightness": $num}}; }
Das Leerzeichen sorgt dafür, dass in der Code Darstellung beim FHEM Web die { nicht in rot angezeigt  wird, weil sie angeblich "fehlt" -> Folglich noch schöner anzusehen und daher verständlicher
Der gesamte Befehl funktioniert auch ohne die ;; zu escapen. Sprich ein ; reicht.
Nachteil dieser Variante: Hat man mit einem Wert z.B.11-19 oder auch 22-27 angefangen, geht es über diese Funktion nie auf 100 und bleibt zwischen 90 und 100 stehen (je nach Ausgangswert)  - Man muss das devStateIcon auch auf krumme Zahlen anpassen.

Ich habe das Ganze (für mich) noch erweitert indem ich vorher auf die vorherige 10er Zahl runde abschneide.
dimUp:noArg { my $num=(int(ReadingsNum($NAME,'pct',0)/10)*10-10); return qq {shellies/DEVNAME/light/0/set {"turn": "on", "brightness": $num}}; }
Nachteil(e) dieser Variante: Geht man bsw mit pct=48 schrittweise nach unten, geht das System von 48(=>40) direkt auf 30 d.h. einmal einen großen Schritt. geht man von 48(=>40) direkt auf 50 gibt es erstmal einen kleinen Schritt, der kaum spürbar ist.
Da bei mir aber ein Bewegungsmelder 5 einstellt und ich händisch zu 98 % nach oben dimme, sind das Schönheitsfehler, mit den ich persönlich sehr gut leben kann.

Man könnte das Ganze umgehen, in dem mann mathematisch rundet oder ceil und floor aber ganz ehrlich, für so eine Funktion ein extra Modul oder einen 20 statt 1 Zeiler -> Das ist sogar MIR den Aufwand zuviel  ;D


Für diejenigen die es interessiert, wie ich es gelöst habe, dass die Icons entsprechend angezeigt werden (RAW export) - Screenshots weiter unten:


attr Licht_OG_BD_dimmer devStateIcon light_light_dim_.*::off up.*:control_arrow_upward@orange:dimUp down.*:control_arrow_downward@YellowGreen:dimDown
attr Licht_OG_BD_dimmer stateFormat { \
my $z1 = int(ReadingsVal($name,"pct",0)/10)*10+10;;\
#fhem ("set LogDummy z1 $z1 -- ");;\
my $z2 = ReadingsVal($name,"ison","false") eq "true"?"light_light_dim_".int(ReadingsVal($name,"pct",0)/10)*10:"off";; \
my $z3 = int(ReadingsVal($name,"pct",0)/10)*10-10;; \
return "up$z1\n$z2\ndown$z3";;\
}
attr Licht_OG_BD_dimmer webCmd pct:

stateFormat sorgt dafür, dass nur 10er Werte für das devStateIcon icon übergeben werden und errechnet gleichzeitig die Werte für das SET icon (das ist doppelt gemoppelt mit der setList, weil man sonst die icons nicht korrekt anzeit - oder die Definition in devStateIcon statt in StateFormat machen müsste)
devStateIcon fängt alle light_light_dim_XX zeilen ab und wandelt sie in das Icon light_light_dim_10 .....light_light_dim_100 ab
der Rest ist für die Pfeile da.

Mir gefallen die dimup / dimdown icons nicht, weshalb ich mich für die "control_arrow" icons entschieden habe - Vergleich auf den Screenshots.

Hier noch ein Vorschlag:
@Beta-User: Wenn Du Du als Befehl "dimup" und "dimdown" statt Großbuchstaben nimmst, passt die Schreibweise direkt für die Dimmericons. Auch wenn jemand andere haben möchte, hat er so sofort die richtigen drin und kann es so machen wie bei mir mit dem light_light_dim teil...

Bei Fragen, fragen... bei Verbesserungsvorschlägen bin ich natürlich sehr offen ( Beta-User hat bsw für mich einen Vorschlag gebracht, der meinen Code wesentlich vereinfacht hat, an den ich nicht gedacht habe)


Viele Grüße
Andreas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: frober am 10 April 2020, 10:09:45
Man könnte das Ganze umgehen, in dem mann mathematisch rundet oder ceil und floor aber ganz ehrlich, für so eine Funktion ein extra Modul oder einen 20 statt 1 Zeiler -> Das ist sogar MIR den Aufwand zuviel  [emoji16]



Wenn du schummelt [emoji6] geht es auch:


(Wert+5)/10*10+10

Dann wird aus z.B. 43 -> 48 und danach wie gehabt 40, aber aus 48 wird 53, also 50

D.h. es wird sozusagen gerundet.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: flummy1978 am 10 April 2020, 19:26:10
Zitat von: frober am 10 April 2020, 10:09:45
Wenn du schummelt [emoji6] geht es auch:
(Wert+5)/10*10+10

Und ohne schummeln ist es eine sehr gute Idee:
+4 erhöhen der Helligkeit
und
+7 beim verringern (damit sind die Sprünge nur minimal größer / kleiner als ohnehin bei +-10 )

ergbit 36-45 => erhöhen => 50 
und  26-33 => verringern => 20

Danke für die Idee :)

Grüße
Andreas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: majestro84 am 15 Mai 2020, 16:48:25
Ich habe hier ein Shelly DoorWindow Sensor den ich per MQTT verbunden habe.
Ich habe es so angepasst das ich im state open, closed und tilted bekomme.
Somit habe ich eine Threestate Sensor.
Evtl kannst du Beta-User was damit anfangen für ein Template...... Wenn du mehr Infos brauchst lass es mich wissen.

defmod AZ_Fensterkontakt MQTT2_DEVICE shellydw_F032F9
attr AZ_Fensterkontakt IODev MQTT_Server
attr AZ_Fensterkontakt devStateIcon open:fts_window_1w_open@red tilted:fts_window_1w_tilt@yellow closed:fts_window_1w@green
attr AZ_Fensterkontakt model shellydw
attr AZ_Fensterkontakt readingList shellies/shellydw-az/online:.* online\
  shellies/shellydw-az/sensor/state:.* doorWindow\
  shellies/shellydw-az/sensor/tilt:.* tilt\
  shellies/shellydw-az/sensor/vibration:.* vibration\
  shellies/shellydw-az/sensor/lux:.* lux\
  shellies/shellydw-az/sensor/battery:.* batteryPercent\
  shellies/shellydw-az/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...shellydw-az...mac.*, ? json2nameValue($EVENT) : return }
attr AZ_Fensterkontakt room Arbeitszimmer,MQTT2
attr AZ_Fensterkontakt setList x_update:noArg shellies/shellydw-az/command update_fw\
  x_mqttcom shellies/shellydw-az/command $EVTPART1
attr AZ_Fensterkontakt userReadings state {if(ReadingsVal($name,"doorWindow","") eq "close") {"closed"}\
elsif (ReadingsVal($name,"doorWindow","") eq "open" and ReadingsNum($name,"tilt","") eq 0) {"open"}\
elsif (ReadingsVal($name,"doorWindow","") eq "open" and ReadingsNum($name,"tilt","") > 0) {"tilted"}}


VG Alex
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Mai 2020, 17:00:51
 :) sieht gut aus!

Schade, dass der den Zustand nicht von sich aus konsolidiert.

Kannst du mal testen, ob ein "reduziertes" und klarer getriggertes userReadings auch hinhaut:
attr AZ_Fensterkontakt userReadings state:(doorWindow|tilt).* { ReadingsVal($name,"doorWindow","") eq "close" ? 'closed' : ReadingsNum($name,"tilt","") ? 'tilted' :'open' }
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: majestro84 am 15 Mai 2020, 17:10:28
Danke für das userreading es funktioniert und sieht doch eleganter aus :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Mai 2020, 18:04:35
Dann sollte das hier passen (ich checke es bei Gelegenheit ein, THX):
# shellydw using original firmware
name:shellydw
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellydw using original firmware
order:A_16b
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
par:ICON;ICON as set, defaults to fts_window_1w_open;{ AttrVal("DEVICE","icon","fts_window_1w_open") }
attr DEVICE icon ICON
attr DEVICE devStateIcon open:fts_window_1w_open@red tilted:fts_window_1w_tilt@yellow closed:fts_window_1w@green
attr DEVICE readingList shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/sensor/state:.* doorWindow\
  shellies/DEVNAME/sensor/tilt:.* tilt\
  shellies/DEVNAME/sensor/vibration:.* vibration\
  shellies/DEVNAME/sensor/lux:.* lux\
  shellies/DEVNAME/sensor/battery:.* batteryPercent\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }
attr DEVICE setList x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE userReadings state:(doorWindow|tilt).* { ReadingsVal($name,"doorWindow","") eq "close" ? 'closed' : ReadingsNum($name,"tilt","") ? 'tilted' :'open' }
attr DEVICE model shellydw
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: majestro84 am 15 Mai 2020, 18:22:19
Super vielen Dank
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: KurtK am 17 Mai 2020, 13:23:47
Hey Beta-User,

zu deinem Beitrag https://forum.fhem.de/index.php/topic,94495.msg1055012.html#msg1055012 kann ich nur sagen,
dass ich den Sensor für unsere Kellertür nutze und dort die Kippfunktion nicht vorkommt und daher die states open und close ausreichend sind.

Evtl. kann man das Template nach Verwendungszweck Fenster und Tür aufteilen.
Habe in meinem Templatevorschlag das StateIcon auf Tür geändert.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Mai 2020, 13:27:13
Oder wie bei vielen mittlerweile schon mit dem Assistenten zur Auswahl. Hab leider noch keinen der Sensoren aber bin gespannt was man da so raus holen kann. Ggf auch für sonnen einstrahlung und automatische Rollo Absenkung usw.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: majestro84 am 17 Mai 2020, 14:31:07
Hallo
Wenn du die Kipp Funktion nicht kalibrierst kann der Sensor ja nur Open und Close. Somit geht das Templet doch auch für Türen.
VG Alex
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: KurtK am 17 Mai 2020, 15:14:18
Alles klar. Die Funktionsweise war mir gar nicht bewusst. Dann reicht tatsächlich ein Template
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: majestro84 am 19 Mai 2020, 17:31:28
Hallo

Das Template für den shellydw muss wohl doch noch etwas angepasst werden. Habe nun einen weiteren hinzugefügt und das Template benutzt. Wenn man die Kippfunktion nicht konfiguriert steht im Reading tilt -1. Somit wird nur Open und tilted im state ausgegeben.
Beta-User kannst du das noch mit einbauen? Tilted nur bei Größer 0.
VG Alex
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 19 Mai 2020, 17:44:24
thx, done!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: majestro84 am 19 Mai 2020, 18:24:01
Vielen Dank
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: KurtK am 25 Mai 2020, 10:31:19
Zum template shellydimmer:

Mit dem neusten Firmwareupdate (Ist auch schon ein wenig her) haben sich beim Shelly Dimmer ein paar Änderungen ergeben.
Power und Energy sind nicht mehr im JSON des Status, daher müssen folgende Zeilen zur readingList hinzugefügt werden:

 
shellies/DEVNAME/light/0/power:.* light_0_power
shellies/DEVNAME/light/0/energy:.* light_0_energy
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 Mai 2020, 10:41:09
TXH, ist im svn.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: KurtK am 25 Mai 2020, 12:13:43
Noch eine Änderung ist mir gerade aufgefallen.

Im template wird der state nicht aktualisiert, wenn man den Lichtschalter am Shelly betätigt. Lediglich "ison" wird passend gesetzt.

Hiermit wird auch der state richtig gesetzt:

shellies/DEVNAME/light/0:.* state
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 Mai 2020, 12:26:49
OK, bastle ich bei Gelegenheit noch rein.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 25 Mai 2020, 22:28:33
Zitat von: KurtK am 25 Mai 2020, 12:13:43
Noch eine Änderung ist mir gerade aufgefallen.

Im template wird der state nicht aktualisiert, wenn man den Lichtschalter am Shelly betätigt. Lediglich "ison" wird passend gesetzt.

Hiermit wird auch der state richtig gesetzt:

shellies/DEVNAME/light/0:.* state


Haha. Genau ist das Problem das ich in #601 Anfang April schon versucht habe zu beschreiben.
Schön das es noch jemand anderem aufgefallen ist.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: KurtK am 26 Mai 2020, 08:19:32
Zitat von: stratege-0815 am 25 Mai 2020, 22:28:33
Haha. Genau ist das Problem das ich in #601 Anfang April schon versucht habe zu beschreiben.
Schön das es noch jemand anderem aufgefallen ist.
Mit der neuen template-Version die seit heute morgen verfügbar ist, sollte es ja jetzt problemlos klappen.
Habe sie bei einem neuen Dimmer eingespielt und alles wird richtig aktualisiert.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: KurtK am 29 Mai 2020, 18:58:05
Habe heute meinen Shelly RGBW2 bekommen.
Beim Template shelly2rgbw_color wurde der Online Status nicht abgefragt und der Slider für den Weißanteil hatte den falschen Einstellbereich.
Mit diesen Änderungen läuft es:

readingList:

shellies/DEVNAME/online:.* online


setList:

white:colorpicker,BRI,0,1,255 shellies/shellyrgbw2_wohnzimmer/color/0/set {"white":"$EVTPART1"}


Das ganze mit Firmware 20200309-104453/v1.6.0@43056d58 getestet.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 29 Mai 2020, 19:10:47
Teil 1 kann ich mir nicht vorstellen. Announce bzw Neustart gemacht?

Teil 2 habe ich nicht im Kopf aber teste ich auf jeden Fall.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: KurtK am 29 Mai 2020, 20:29:36
Teil 1: Auch mit Announce tauchte das Reading online nicht auf. Erst nachdem ich die Zeile zur readingList hinzugefügt und dann ein Announce gemacht habe, war es da.
Vielleicht übersehe ich aber auch was.


Teil 2: Im Template wird Weiß mit einem Slider 0 bis 100 eingestellt. Nach Shelly API und eigenem Ausprobieren sind hier maximal 255 möglich.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 29 Mai 2020, 20:56:55
Hab nur mein Handy also verzeih mir wenn ich Worte nicht zu 100% mit nehme. Sehe den deinen Beitrag beim Schreiben also nicht.

Zu 1) normal muss die liste der readings alleine gefüllt werden wenn die topics passen. Bedeutet du hast den mqtt Pfad im shelly angepasst oder es ist was anderes verdreht in deiner konfig.

Zu 2) hab die umrechnung nicht in Kopf aber ein % slider kann trotzdem von 0-100 auch von 0-255 sliden...denn...%...

Bin mir relativ sicher der war okay so. Checke ich aber.

Gesendet von meinem LM-G810 mit Tapatalk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 31 Mai 2020, 09:58:26
Zitat von: KurtK am 29 Mai 2020, 20:29:36
Teil 1: [...]
Teil 2: Im Template wird Weiß mit einem Slider 0 bis 100 eingestellt. Nach Shelly API und eigenem Ausprobieren sind hier maximal 255 möglich.
Ad 1: Ist gefixt (auch bei mind. noch einem weiteren);

Ad 2: Das mit brightness ist ein dickeres Brett. Habe eben nochmal die API angesehen (https://shelly-api-docs.shelly.cloud/#shelly-dimmer-sl-mqtt (https://shelly-api-docs.shelly.cloud/#shelly-dimmer-sl-mqtt)), jedenfalls an der Stelle wird behauptet, das sein ein 100%-Ding.

Wenn es eine andere/neuere API-Beschreibung gibt, bräuchte ich bitte einen Link, denn dann wäre es wohl so, dass man die attrTemplates für shelly-Dimmer-Geräte (alle?) auf "brightness" als Readingnamen umstellen sollte (statt pct; da hängt auch die Sprachsteuerung dran)...(Und wie kommunizieren wir das?)
EDIT: Zumindest bei dem RGBW2 ist weiß 0-255: https://shelly-api-docs.shelly.cloud/#shelly-rgbw2-mqtt
Muß ich mir noch Gedanken machen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 16 Juli 2020, 10:37:57
Hallo zusammen,
Ich plane einen Shelly RGBW anzuschaffen. Gibt's irgendwo eine Beschreibung welche ,,Effekte" oder ähnliches ich über diese MQTT templates erzeugen kann? Bin momentan nur beschränkt mittels Handy online,
Daher konnte ich den ganzen Thread nicht durcharbeiten.
Gruß
Jan
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Juli 2020, 10:58:04
Hmm, der setter kennt 0-3, was auch immer das im Detail bedeutet...

Ok, hier steht es (https://shelly-api-docs.shelly.cloud/#shelly-rgbw2-color-settings-color-0):
ZitatSupported values for effect are:

       
  • 0 - Off
  • 1 - Meteor shower
  • 2 - Gradual change
  • 3 - Flash
  • 4 - Red/green change
(Demnach fehlr im template #4, ziehe ich bei Gelegenheit mal nach, auch wenn man das vermutlich nicht so oft benötigt...).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 17 Juli 2020, 14:15:16
Es gibt 4 dokumentierte. Ich hab den setter auf 6 stehen, da es noch zwei weitere gibt. Aber ganz ehrlich. Wir reden über nicht Einzel steuerbare LEDs. Also was soll man da groß machen außer ein wenig blinken und Farben zu wechseln? Habe zwei im WZ und einen in der Garage. Wenn du Fragen dazu hast, meld dich einfach nochmal.

Gruß, 87insane
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 19 Juli 2020, 10:31:18
Falls ich gemeint bin muss ich etwas ausholen...
Sorry für OT
Ich möchte eine Nachtbeleuchtung für eine Treppe realisieren. Vom EG immer an der Treppenwange entlang bis zum 2.OG. Ich habe 2015 bei einer Treppenhaus Sarnierung schon Leerrohre verlegt. Ich komme auf ca. 13 LED insgesamt, immer wieder unterbrochen durch Kabelstrecken (Leerrohre im Boden).
Nun kam tatsächlich von den Kindern der Wunsch nach einem Bewegungsgesteuerten Nachtlicht damit der alternde Hund nicht stolpert. (Kommt tatsächlich vor) Aber auch wenn die Nachtschwärmer nach Hause kommen wäre das kein Nachteil. Ich lese mich in die LED stripe Thematik gerade erst ein. Einzeln gesteuerte LEDs sind ja wohl eine ganz andere Baustelle, ich glaube mit meinen Kabelunterbrechungen kriege ich das auch gar nicht hin. Aber mit RGBW sollten auch ein paar Effekte möglich sein - sanftes Überblenden der Farben wäre wohl ganz brauchbar.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: pula am 28 Juli 2020, 10:45:06
Hi,
für so was wäre evtl WS2812b eine super Option, da kann man jede LED einzeln steuern...
Cheers,
Pula
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Hellspawn am 30 Juli 2020, 13:06:31
Mal eine andere Frage, vielleicht stehe ich auch einfach nur auf dem Schlauch...
ich versuche auf ein Event zu triggern und zwar eines Shelly 2.5 Langer Tastendruck.. das Event ist:
MQTT2_DEVICE shelly_KuechenLichtCH2 event: L
das funktioniert auch gut... ABER
das Event erscheint immer wieder im eventmonitor und zwar solange, bis ich einen kurzen Tastendruck mache... dann erscheint
MQTT2_DEVICE shelly_KuechenLichtCH2 event: S

das Problem was ich habe, ist das mein DOIF immer wieder loslegt obwohl ich keinen langen Klick gemacht habe...

Liegt es an mir, am Doif oder evtl. doch am MQTT2 Template?

Lg
Carsten
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 30 Juli 2020, 13:11:10
Vmtl an Dir und DOIF :)
Ich gehe davon aus, dass dein DOIF nicht richtig konfiguriert ist.
Um es zu reparieren wuerde ich in der DOIF- oder Anfaenger-Abschnitt des Forums ein Thema oeffnen, und die Details (aka list oder list -r) des aktuellen DOIFs schildern, samt den Event-Zeilen aus dem Event-Monitor.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 30 Juli 2020, 13:18:45
...oder an dem Shelly...

Der ESP sendet (vermtl. abhängig von der Konfiguration) auch regelmäßig Statusupdates, obwohl sich nichts geändert hat, das Thema hatten wir schon ein paar Mal, aber bisher hat sich keiner bemüßigt gefühlt mir zu erklären, wie man das einem Shelly (bzw. wie welchem) "austreiben" kann.

Da der Shelly vermutlich Klartext sendet: event-on-change.* und timestamp-on-change.* ansehen und bitte dann eine so konsolidierte Rückmeldung machen, dass ich die Allgemeingültigkeit (bzw. den exakten Gültigkeitsbereich) der betreffenden Einstellungen erkennen kann, bitte dabei berücksichtigen, dass es für Meßwerte Sinn macht, die auch dann zu senden/und ggf. zu loggen, wenn sich nichts geändert hat seit der letzten Messung...

(Gerne können wir das für einen einzelnen Shelly auch mal durchexerzieren, ich bräuchte dann aber bitte a) einen separaten Thread und b) den Verkehr auf der MQTT-Ebene.)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 31 Juli 2020, 09:30:41
Eigentlich sollte longpush auch ein Reading haben welches auf 1 oder 0 steht....
longpush_0

Kommt aus: shellyXYZ_ID:shellies/shellyXYZ-ID/longpush/(0|1) (Je nachdem wie viele Eingänge er hat).

Bei mir laufen die "longpushes" eigentlich sauber... Ggf. Das Gerät krumm?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Hellspawn am 31 Juli 2020, 10:23:08
ok, mit dem Reading geht es in der Tat...
vielen Dank für die Rückmeldung...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 31 Juli 2020, 10:46:44
...das ändert aber nichts daran, dass der Shelly an anderer Stelle nach meinem Geschmack (viel) zu gesprächig ist und man diese Flut unabhängig von der "anderen Lösung" eindämmen sollte...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 31 Juli 2020, 11:26:35
Shelly verhält sich fast wie Tasmota (in meinen Augen).
Ich habe überall event-on-change aktiv, da mir das sonst auch zu viel ist. Allerdings dämme ich damit nur die Verarbeitung ein, nicht aber das was der Shelly immer und immer wieder sendet.

Was genau stört Dich an der Kommunikation? Ggf. kann ich ja helfen...

Gruß,
87insane
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Reinerlein am 31 Juli 2020, 12:12:45
Hallo Beta-User,

mir ist an dem DevStateIcon der Shelly-Templates eine kleine Unschönheit aufgefallen.
Es wird dort oftmals sowas gemacht:
my $light = ReadingsVal($name,"state","off");;

Damit soll dann der aktuelle Zustand in $light abgelegt werden, um ihn für die spätere Darstellung verwenden zu können.
Die Verwendung von "ReadingsVal" hat aber den unschönen Nebeneffekt, dass das immer live vom Gerätedevice geholt wird. Bei einer Anzeige innerhalb einer LightScene z.B. wird dann in der Szenenübersicht immer der aktuelle Zustand des Geräts dargestellt, und nicht der, den die Szene schalten würde.

Ich habe dieses "$light" bei mir ersetzt duch "$state". Diese Variable wird von FHEMWEB vor dem Perl-Eval des DevStateIcon gesetzt, und enthält im Falle einer Lightscene auch den passenden Wert, der geschaltet werden soll.

Am Beispiel von "shelly1_w_energy_meassuring" (schreibt man übrigens wohl mit einem "s" :) ):
{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 $cons = ReadingsVal($name,"relay_0_power","unknown");; my $total = ReadingsVal($name,"relay_0_kWh","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"".FW_makeImage($onl)." ".FW_makeImage($state)."
Verbrauch: $cons / Total: $total/ Temp: $temp ° C
"}

Die Definition von $light raus, und direkt $status verwenden.

Bei den anderen dann Analog dazu...

Grüße
Reinerlein
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 31 Juli 2020, 12:22:20
@Reinerlein:

Danke für die Rückmeldung, ich bau's bei Gelegenheit um. (Man lernt nie aus...)

Für den Fall, dass jemand diese Fleißarbeit leisten will (und dabei auch den Typo eliminieren mag):
Feel free, ich nehme auch patches oder "normalen Text", dann aber bitte möglichst alles als kompletten Auszug liefern...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 31 Juli 2020, 12:24:16
Zitat von: 87insane am 31 Juli 2020, 11:26:35
Shelly verhält sich fast wie Tasmota (in meinen Augen).
Ich habe überall event-on-change aktiv, da mir das sonst auch zu viel ist. Allerdings dämme ich damit nur die Verarbeitung ein, nicht aber das was der Shelly immer und immer wieder sendet.

Was [...] stört Dich an der Kommunikation?
Was mich "ungenau" stört: Das Verhalten von Shelly ist (wie das von Tasmota auch, aber da haben wir auch einigen Aufwand reingesteckt, um die Auswirkungen sinnvoll zu begrenzen...) mMn. nicht 100% "MQTT"-like.

Ich zitiere mal aus der Doku zu 3.1.1 (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html))
ZitatMQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.

Immer alles zu senden, ist nicht "light weight", hier hatte ich dazu auch schon mal etwas mehr geschrieben:
Zitat von: Beta-User am 27 April 2020, 12:37:53
[...] Das "Grundproblem" ist m.E. ein anderes: Nach meinem Verständnis ist MQTT ein Protokoll, das mal dafür gemacht war, Zustände ausfallsicher zu übermitteln. Es gibt daher zu jedem Informationspunkt in meiner Gedankenwelt optimalerweise genau eine Information, die in der Auswahl recht beschränkt ist, und irgendwelche Elemente nach dem Muster "0/1/on/off/missing/offline/failure..." haben sollte. Mit JSON weicht man das Prinzip etwas auf, was auch noch solange ok ist, als die Datenpunkte und Werte irgendwie zuordenbar bleiben.

Dinge wie Grafiken (valetudo) oder Konfigurationen (homeassistant-discovery-Meldungen) zu übertragen, sind für mich "abuse", das ist nicht "schlank und schnell" (=MQTT-like=maschinenlesbar), sondern "fett" (Webpage-like=menschenlesbar).

[...]
Vielleicht kurz zum Hintergrund: Mein "gedanklicher Prototyp" für den Einsatz von MQTT ist eine Ölpipeline. Für sowas wurde das afaik mal entwickelt:
Hardwareüberwachung unter Extrembedingungen. Lange Stecken, ständig zu befürchtende Verbindungsabbrüche, widrige externe Umstände wie Hitze/Staub/Kälte/Wasser. Also: Wenig Info, eigentliche Auswertung der Info erfolgt "hinter dem Broker".

Ich hoffe, das ist nachvollziehbar und hilft ggf. auch beim Design (imo) "guter" MQTT-Implementierungen?
Kurzform: Ein optimales MQTT-Device sendet mMn. immer nur genau die Infos, die jemand in einem Kontrollzentrum braucht oder haben will. Das erfordert eigentlich entsprechende Konfigurationsmöglichkeiten auf dem Device selbst, die allerdings afaik teils nicht vorhanden sind (?).
Meine Erwartung, an das, was zu senden wäre, wäre daher in etwa das hier:
- LWT => zeigt an, ob das Gerät überhaupt erwartungsgemäß kommunizieren kann. Sollte JEDES MQTT-Gerät können. Intervall sollte einstellbar sein, per Default eher lang (in einem typischen Hausautomatisierungsumfeld reichen 5-15 Minuten oder so).
- Bestätigungen für erhaltene Anweisungen (schalte Relay xy ein)
- Messwerte wie Temperaturen oder Luftfeuchtigkeit: regelmäßig, Intervall einstellbar, optimalerweise noch mit Schwellenwerten für schnellere Änderungen)
- Basisinfos nur beim Starten (IP-Adresse, firmwareversion usw.)
- sonstige Statusinfos nur auf Anfrage

Was mich konkret stört? Hier hatte ich versucht zu schreiben, was ich konkret haben will:

Zitat von: Beta-User am 30 Juli 2020, 13:18:45
Da der Shelly vermutlich Klartext sendet: event-on-change.* und timestamp-on-change.* ansehen und bitte dann eine so konsolidierte Rückmeldung machen, dass ich die Allgemeingültigkeit (bzw. den exakten Gültigkeitsbereich) der betreffenden Einstellungen erkennen kann, bitte dabei berücksichtigen, dass es für Meßwerte Sinn macht, die auch dann zu senden/und ggf. zu loggen, wenn sich nichts geändert hat seit der letzten Messung...

Hier hatte ich mal eine auf die Schnelle zusammengeklöppelte Basis gepostet:
Zitat von: Beta-User am 01 Juli 2020, 07:55:45
Bin nicht sicher, ob wir es da mit einem Fall von Rationalisierung zu tun haben ;D .
Wie dem auch sei: Wer bisher kein MQTT(2) nutzt, hat mit deinem Modul eine sehr gute Alternative, wer sowieso MQTT(2) nutzt, wird seine Gründe haben und die "Einheitlichkeit" (*lach...*) schätzen.

Aber:
Man könnte es auch als verpaßte Gelegenheit auffassen, den Usern den "richtigen Umgang" (falls es sowas überhaupt gibt...) mit den event-on.* und timestamp.*-Attributen zu vermitteln :P . Macht hier ja durchaus Sinn, da die Shelly ja (@MQTT) dankenswerterweise "Klartext" (und nicht JSON) sprechen. Oder dem Hersteller ein etwas differenzierteres Sendeverhalten vorzuschlagen, wenn man einen guten Draht hat und sowas auch sachlich differenziert vermitteln kann.

Wie dem auch sei, hier mal ein vorläufiges Zwischenergebnis@MQTT2 als Diskussionsgrundlage:
defmod Muster_Shelly1pm MQTT2_DEVICE shelly1pm_123456789012
attr Muster_Shelly1pm IODev MQTT2_FHEM_Server
attr Muster_Shelly1pm comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr Muster_Shelly1pm 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");;;; 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 / Total: $total/ Temp: $temp °C</div>"}
attr Muster_Shelly1pm event-on-change-reading state,temperature:0.2,online,loadState,overtemperature,Verbrauch_Total_kWh,relay_0_.*,relay0,input0
attr Muster_Shelly1pm event-on-update-reading stat[ERT].*
attr Muster_Shelly1pm model shelly1_w_energy_meassuring
attr Muster_Shelly1pm readingList shellies/shelly1pm-123456789012/relay/0:.* state\
  shellies/shelly1pm-123456789012/relay/0:.* relay0\
  shellies/shelly1pm-123456789012/input/0:.* input0\
  shellies/shelly1pm-123456789012/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...shelly1pm-123456789012...mac.*, ? json2nameValue($EVENT) : return }\
  shellies/shelly1pm-123456789012/announce:.* { json2nameValue($EVENT) }\
  shellies/shelly1pm-123456789012/relay/0/power:.* relay_0_power\
  shellies/shelly1pm-123456789012/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on";; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : return }\
  shellies/shelly1pm-123456789012/temperature:.* temperature\
  shellies/shelly1pm-123456789012/overtemperature:.* overtemperature\
  shellies/shelly1pm-123456789012/relay/0/energy:.* relay_0_energy\
  shellies/shelly1pm-123456789012/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/shelly1pm-123456789012/longpush/0:.* longpush_0\
  shellies/shelly1pm-123456789012/temperature_f:.* {}\
  shellies/shelly1pm-123456789012/input_event/0:.* { json2nameValue($EVENT) }
attr Muster_Shelly1pm room Steuerung->Test
attr Muster_Shelly1pm setList relay0:on,off,toggle shellies/shelly1pm-123456789012/relay/0/command $EVTPART1\
  off:noArg shellies/shelly1pm-123456789012/relay/0/command off\
  on:noArg shellies/shelly1pm-123456789012/relay/0/command on\
  x_update:noArg shellies/shelly1pm-123456789012/command update_fw\
  x_mqttcom shellies/shelly1pm-123456789012/command $EVTPART1
attr Muster_Shelly1pm setStateList on off
attr Muster_Shelly1pm timestamp-on-change-reading state,online,loadState,overtemperature
attr Muster_Shelly1pm userReadings relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}, Verbrauch_Total_kWh:relay_0_kWh:.* monotonic {ReadingsNum("$name","relay_0_kWh",0)}
attr Muster_Shelly1pm webCmd :

Vielleicht mag das ja jemand testen, verfeinern und ggf. so (generisch) notieren, dass man es auch für andere Shellies verwenden kann...?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 01 August 2020, 09:20:11
Eine Konsole hat man zwar nicht aber man kann den Intervall umstellen (meine ich jetzt aus dem Kopf).

Beim Lesen des zu testenden, sehe ich alte Bekannte😅
Glaube wir haben bei tasmota schon viel gesprochen darüber... Naja egal... Wenn ich an den pc kann/darf, teste ich.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 01 August 2020, 15:31:16
Das ist seit eben (hoffentlich) durchgängig raus (auch bei Tasmota), und den Typo habe ich auch gefixt.
Zitat von: Reinerlein am 31 Juli 2020, 12:12:45
my $light = ReadingsVal($name,"state","off");;
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 August 2020, 10:39:43
Zitat von: Beta-User am 31 Juli 2020, 12:24:16
Was mich "ungenau" stört: Das Verhalten von Shelly ist (wie das von Tasmota auch, aber da haben wir auch einigen Aufwand reingesteckt, um die Auswirkungen sinnvoll zu begrenzen...) mMn. nicht 100% "MQTT"-like.

Ich zitiere mal aus der Doku zu 3.1.1 (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html))

Immer alles zu senden, ist nicht "light weight", hier hatte ich dazu auch schon mal etwas mehr geschrieben:Kurzform: Ein optimales MQTT-Device sendet mMn. immer nur genau die Infos, die jemand in einem Kontrollzentrum braucht oder haben will. Das erfordert eigentlich entsprechende Konfigurationsmöglichkeiten auf dem Device selbst, die allerdings afaik teils nicht vorhanden sind (?).
Meine Erwartung, an das, was zu senden wäre, wäre daher in etwa das hier:
- LWT => zeigt an, ob das Gerät überhaupt erwartungsgemäß kommunizieren kann. Sollte JEDES MQTT-Gerät können. Intervall sollte einstellbar sein, per Default eher lang (in einem typischen Hausautomatisierungsumfeld reichen 5-15 Minuten oder so).
- Bestätigungen für erhaltene Anweisungen (schalte Relay xy ein)
- Messwerte wie Temperaturen oder Luftfeuchtigkeit: regelmäßig, Intervall einstellbar, optimalerweise noch mit Schwellenwerten für schnellere Änderungen)
- Basisinfos nur beim Starten (IP-Adresse, firmwareversion usw.)
- sonstige Statusinfos nur auf Anfrage

Was mich konkret stört? Hier hatte ich versucht zu schreiben, was ich konkret haben will:

Hier hatte ich mal eine auf die Schnelle zusammengeklöppelte Basis gepostet:Vielleicht mag das ja jemand testen, verfeinern und ggf. so (generisch) notieren, dass man es auch für andere Shellies verwenden kann...?

Hey - Was genau ist in deinem "Test" anders?
Ich nutze bei allen Shelly event-on-change .* (als Minimum).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 August 2020, 10:48:26
Zitat von: 87insane am 04 August 2020, 10:39:43
Hey - Was genau ist in deinem "Test" anders?
Ich nutze bei allen Shelly event-on-change .* (als Minimum).
.* ist schlicht und ergreifend mMn. zu pauschal, das ist in dem Beispiel sehr viel ausdifferenzierter, auch was timestamps angeht. Vielleicht hast du ja einen pm-Shelly irgendwo rumfliegen und kannst mal einen etwas kritischer beobachtenden Blick auf das ganze Device im Betrieb (auch bei lokalen Schaltungen am Taster usw.) werfen, wenn die von mir vorgeschlagenen Attribute gesetzt sind? Das Zusammenspiel ergibt sich besser, wenn man das "in Aktion" erlebt...

.* werde ich jedenfalls bis auf weiteres nicht einfach so in attrTemplate-Form gießen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 04 August 2020, 11:02:29
Ne neeeeee.. Sagte ja auch als Minimum. Je nachdem was das Ding in der Wand auch am Ende machen soll.

Ja, teste ich. Am Ende ist es aber sehr Personen bezogen. Waschmaschine ist am Ende was anderes als ein Licht oder aber ggf. als Raumzähler... usw

EDIT: Aber zum testen wollte ich nur die Veränderungen wissen. Würde das dann einfach anpassen. Wollte eben nicht selber comparen :)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 06 August 2020, 16:06:37
Hab den Test seit gestern Abend in meinem Waschmaschine Shelly.... Mal sehen was kommt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Hellspawn am 10 August 2020, 10:07:06
Hallo Ihr, ich noch mal...

ich habe hier einen Shelly-DW2, der verhält sich auch brav wie er soll... wenn ich allerdings das DW Template auswählen erscheint:
Unknown command shellies/announce:.*, try help.

ich glaube da ist ein Fehler im Template...

Gruß
Carsten
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 10 August 2020, 10:23:08
Danke für den Hinweis, da fehlt ein Zeilenumbruch (\) in Zeile 2351.

Update folgt.

Was mich zu dem allgemeinen announce-Pfad noch interessieren würde: Ist der eigentlich (noch) notwendig?
Hintergrund der Frage: würde eher dazu tendieren, das "shelly_announces" etwas mehr in den Vordergrund zu rücken bzw. ggf. im Hintergrund dafür sorgen, dass das als separates Device (einmalig) angelegt wird, um alle diese zentralen Infos zu abonnieren? Die "announce"-Infos kommen ja über zwei Pfade an, wenn man dem attrTemplate Glauben schenkt, und sind daher ggf. einfach doppelt bzw. werden auch doppelt ausgewertet... (man könnte den Pfad auch drin lassen, aber dann die Daten nicht auswerten; das erscheint mir als "Nebenaktion" sinnvoller, als die regex drüberlaufen zu lassen, das erzeugt ggf. nur unnötige Systemlast).

(Nach Analyse des MQTT-Verkehrs gebildete) Rückmeldungen wären nett...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: JJ_Pamoux am 14 August 2020, 22:11:56
Ich habe jetzt eine Shelly 1 an meine Sommer Garagensteuerung angeschlossen und auch ein Template erstellt.

Für mich passt das so, aber da gibt es bestimmt etwas zu verbessern.

name:shelly1_garage
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
order:A_10
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE webCmd :on
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* state\
  shellies/DEVNAME/relay/0:.* relay0\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }
attr DEVICE cmdIcon on:fts_garage_door_up_down_stop
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen";; my $status = ReadingsVal($name,"input0","0") eq "0" ? "100" : "10";; my $show = '<a href="';;$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">';;$show .= FW_makeImage("10px-kreis-".$onl)."</a>";; "<div> $show <a href=\"/fhem?cmd.dummy=set $name on&XHR=1\">".FW_makeImage("fts_garage_door_".$status)."</a></div>" }
deletereading -q DEVICE (?!associatedWith).*
set DEVICE x_mqttcom announce
set DEVICE attrTemplate speechcontrol_type_switch
attr DEVICE model shelly1_garage


Was mich noch stört, wenn ich z.B. das Shelly 2.5 Roller-Template (shelly25_roller_invert_0) verwende, dann erhalte ich nach einem Klick auf die Bezeichnung des Devices den "Vorschlag" set mit dem pct-Slider zu nutzen.
Bei meinem Template wird mir stattdessen "vorgeschlagen" das attrTemplate zu setzen (was ich ja glaube schon mit dem Template gesetzt zu haben).
Wie kann ich denn vorgeben, dass einfach set DEVICE on vorgeschlagen wird? Auf die Schnelle habe ich da im Template nichts gesehen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 August 2020, 13:41:31
Vorab mal willkommen im Forum!

Danke auch für den template-Vorschlag, von dem ich allerdings noch nicht so recht verstanden habe, was der "Trick" sein soll, den du damit als Beispiel zeigen willst. Oder funktioniert was an dem Basistemplate nicht?

Was die Frage angeht, wie ein Device aussieht (sowas wie webCmd, cmdIcon etc. allgemein), und wie die ganzen Attribute sinnvollerweise nacheinander aufeinander aufbauend zu setzen sind, würde ich das lieber an einem "einfachen" Device (idealerweise einem shelly mit Power-Messung) mal exemplarisch im Wiki zeigen (ähnlich wie "Device Overwiew anpassen"), bisher hat dazu aber noch keiner effektiv einen Vorschlag geliefert... (in diese Richtung verstehe ich das mit dem Roller-shelly?).

(Da das ein Garagentoröffner ist: du hast vermutlich das Teil im Tasterbetrieb und auch noch was auf dem Gerät konfiguriert, damit es nach einem "on" gleich wieder aus geht, oder?)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: JJ_Pamoux am 18 August 2020, 22:00:49
Hallo!

Danke für die schnelle Rückmeldung. Wieso "Trick"?
Ich habe einen Shelly 1 genutzt, dieser zeigt mir gleichzeitig (detached Switch) an, in welchem Status das Garagentor ist und ich kann es schalten (und ja, richtig vermutet, es schaltet nach 0,2 Sekunden wieder auf off).

Die Statusanzeige funktioniert, das Auf/Ab/Stop-Fahren funktioniert (habe dafür ein Icon modifiziert, bin mir nicht sicher, ob man das dann veröffentlichen darf), nur leider bekommt man beim Klick auf das Device halt immer den Vorschlag man solle ein Template setzen, statt den einfach "set on". Das wäre mir halt lieber, da man dann mit dem Smartphone nicht direkt das Template verstellt.

Habe dies hier beschrieben (letzter Post):
https://forum.creationx.de/forum/index.php?thread/2159-garagentor-sommer-torantrieb-s-9080-pro/
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 20 August 2020, 16:11:44
@beta-user: hab deinen Vorschlag nun lange getestet und bisher nur für die waschmaschine (bei mir running) in event-on-change reading hinzugefügt. Ansonsten reagiert eben kein notify oder sonst was. Aber sonst gut.

Teste weiter und melde mich.

Ps: running ist es bei mir. Glaube du/die Templates haben dafür loadstate.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: lewej am 21 Oktober 2020, 20:51:25
Hallo zusammen,

Ich stell mal hier die Frage rein, weil ich keinen anderen passen thread gefunden habe. Shelly schreibt ja ins topic /shellies/ID/online{true/false} rein. Das ganze passiert beim boot oder man triggert ein update.

Wenn man nichts macht, bleibt dort true stehen, obwohl man den shellie stromlos gemacht hat, ein Update kann dann halt nicht erfolgen. Im setting Teil vom shelly gibt es einen keep alive, der scheint inputs und relay  Topics upzudaten, was irgendwie nicht das ware ist.

Wie könnte man den online Status als heartbeat umsetzen, evtl. stand der eine oder andere vor dem gleichen Problem?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 22 Oktober 2020, 11:57:00
Vermutlich OT (so wie die Frage)...

MQTT hat IMMER einen Keep-Alive auf den online Status. MQTT sendet beim ersten Verbinden zum Server direkt die Info wie lange er als online gelten soll, wenn er sich nicht mehr meldet (also aus ist).
(https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/ (https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/))

In deinem Shelly ist das die eingestellte Zeit unter: Internet & Security -> ADVANCED - DEVELOPER SETTINGS -> Keep-Alive (Standard ist 60 Sekunden).
Also wenn Shelly offline, dann wird FHEM das nach 60 signalisieren.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 22 Oktober 2020, 13:11:44
ZitatMQTT hat IMMER einen Keep-Alive auf den online Status.
Nicht immer, aber ueblicherweise. Beim LWT ist das genauso.
Weiterhin muss der Server nach 1.5-mal Keep-Alive Time Alarm schlagen, hier also nach 90 Sekunden.
Siehe http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349238
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: lewej am 26 Oktober 2020, 20:41:20
Hallo zusammen,

shelly hat bei einigen devices ein neues Topic eingeführt. Die senden jetzt nach shellies/DEVICNAME/info Infos zu WLan und noch anderen Einstellungen.
Hat das jemand schon eingebunden?

Mit diesem subscribe geht es nicht:
shellies/DEVICENAME/info:.* { json2nameValue($EVENT) }

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 05 November 2020, 07:43:18
Zitat von: lewej am 26 Oktober 2020, 20:41:20
Hallo zusammen,

shelly hat bei einigen devices ein neues Topic eingeführt. Die senden jetzt nach shellies/DEVICNAME/info Infos zu WLan und noch anderen Einstellungen.
Hat das jemand schon eingebunden?

Mit diesem subscribe geht es nicht:
shellies/DEVICENAME/info:.* { json2nameValue($EVENT) }

Gruß

Bei mir geht wie es rein kommt....
shellies/shelly1pm-12345/info:.* { json2nameValue($EVENT) }

Beispiel: wifi_sta_connected
true
2020-10-06 12:40:37
wifi_sta_ip
192.168.20.51
2020-10-06 12:40:37
wifi_sta_rssi
-54
2020-10-06 12:40:37
wifi_sta_ssid
KA-nG-WLan_2.4Ghz
2020-10-06 12:40:37
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rallye am 28 November 2020, 17:17:23
Guten Abend in die Runde !
Ich hab mir mal ein paar Shellys (1er-Modell) zugelegt und einen verbaut. Ich bin nun nicht sicher welche Methode der Anbindung zu FHEM ich verwenden soll... HTTP oder MQTT ? Gibt's irgendwo eine "Abhandlung" über die Vor- und Nachteile der beiden Anbindungen ? Am Ende des Tages möchte ich so ca. 15+ Shellys verbauen (die sind so schön klein und passen überall hinein). Danke
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 November 2020, 17:27:56
Eine Methode hast du "vergessen": Shelly-Modul... ;)

https://wiki.fhem.de/wiki/Shelly-Aktoren

Willst du wirklich so viele WLAN-Dinger haben?

Entsprechende WLAN-Infrastruktur (!=Fritzbox ;)  ) vorhanden und nicht eh schon "zu viel" Wifi in der Umgebung?

Aber zurück zum Thema: mqtt vs. http -> mqtt! ;)

Shelly Modul echt einfach, Statusrückmeldung aber "pollend" (soweit ich weiß / außer man konfiguriert was im Shelly selbst)...

Entscheidung: up to you ;)

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 28 November 2020, 17:33:37
Vorab - bitte beachte die Warnung von MadMax-FHEM: WLAN in Massen braucht passende Infrastruktur...

Ansonsten, na ja, hier geht es um die Einbindung als MQTT2_DEVICE. Von daher wirst du hier eher nur Leute hören, die den MQTT-Weg "ok" finden, der ist auf alle Fälle auf "push" ausgelegt (teils - was shelly betrifft - aber sehr gesprächig!)..

Wenn du planst, ggf. auch weiteres Zeug via MQTT einzubinden, ist es vermutlich einfacher, "alles auf eine Schiene zu nageln" und das einheitlich zu machen, aber afaik gibt es auch genug Anwender, die pah's Modul "ok" finden. Eventuell nimmt einem das spezielle Modul manches ab (?), was "event-on-change-reading" angeht, da muss man bei MQTT2_DEVICE mAn. noch nachsteuern (ich warte noch auf abschließendes feedback zu dem ausdifferenzierten Vorschlag, den ich irgendwann mal gepostet hatte...), und die "cloud" ist mit MQTT-Einbindung auch weg, aber sonst: k.A....

Wie so oft in FHEM - TIMTOWTDI
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TNT0068 am 14 Dezember 2020, 21:56:27
Hallo zusammen,
gestern kam meine Lieferung mit den neuen Shelly Bulb - RGBW https://shop.shelly.cloud/shelly-bulb-rgbw-wifi-smart-home-automation#432 (https://shop.shelly.cloud/shelly-bulb-rgbw-wifi-smart-home-automation#432).
Ich benutze jetzt MQTT erst seit kurzen in FHEM vorher habe ich das alles über das Shelly Modul abgewickelt.
Ich habe das Template für den rgbw ausprobiert leider klappt nur On/off.
Wird es in naher Zukunft ein Template dafür geben?
Leider kenn ich mich mit der Template Erstellung überhaupt nicht aus geschweige den mit MQTT, falls ich mit irgendwelchen Infos dienen kann, dann mache ich das natürlich gerne.

Gruß
Micha

define Bad_Decke_2_mq MQTT2_DEVICE shellycolorbulb_483FDA92803F
attr Bad_Decke_2_mq IODev MQTT2
attr Bad_Decke_2_mq genericDeviceType light
attr Bad_Decke_2_mq icon light_control
attr Bad_Decke_2_mq jsonMap brightness:pct
attr Bad_Decke_2_mq model shellybulb
attr Bad_Decke_2_mq readingList shellies/shellycolorbulb-483FDA92803F/color/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/online:.* online\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/announce:.* { json2nameValue($EVENT) }\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/info:.* { json2nameValue($EVENT) }\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/color/0:.* color_0\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/light/0/power:.* light_0_power\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/light/0/energy:.* light_0_energy
attr Bad_Decke_2_mq room MQTT2_DEVICE
attr Bad_Decke_2_mq setList off:noArg shellies/shellycolorbulb-483FDA92803F/color/0/command off\
  on:noArg shellies/shellycolorbulb-483FDA92803F/color/0/command on\
  pct:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-483FDA92803F/color/0/set {"gain":"$EVTPART1","brightness":"$EVTPART1"}\
  pct_on:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-483FDA92803F/color/0/set {"turn":"on","gain":"$EVTPART1","brightness":"$EVTPART1"}\
  ct:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);;"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
  ct_on:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);;"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;;if($1 ne $2 || $2 ne $3){"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;;if($1 ne $2 || $2 ne $3){"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  x_update:noArg shellies/shellycolorbulb-483FDA92803F/command update_fw\
  x_mqttcom shellies/shellycolorbulb-483FDA92803F/command $EVTPART1
attr Bad_Decke_2_mq userReadings ct:temp.* {ReadingsVal($name,"temp",3000)}, rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);;"$a$a$a"}}
attr Bad_Decke_2_mq webCmd on:off:pct:ct:rgb

setstate Bad_Decke_2_mq off
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 actions_stats_skipped 0
setstate Bad_Decke_2_mq 2020-12-14 21:10:59 attrTemplateVersion 20200522 or prior
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 blue 0
setstate Bad_Decke_2_mq 2020-12-14 21:10:59 brightness 100
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 cfg_changed_cnt 3
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 cloud_connected false
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 cloud_enabled false
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 color_0 on
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 ct 3000
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 effect 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 fs_free 156875
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 fs_size 233681
setstate Bad_Decke_2_mq 2020-12-14 21:40:30 fw_ver 20201124-090732/v1.9.0@57ac4ad8
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 gain 49
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 green 0
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 has_timer false
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 has_update true
setstate Bad_Decke_2_mq 2020-12-14 21:40:30 id shellycolorbulb-483FDA92803F
setstate Bad_Decke_2_mq 2020-12-14 21:40:30 ip 192.168.10.66
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 ison true
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 light_0_energy 25
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 light_0_power 0.61
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_blue 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_brightness 100
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_effect 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_gain 100
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_green 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_has_timer false
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_ison true
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_mode color
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_red 255
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_source http
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_temp 4750
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_timer_duration 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_timer_remaining 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_timer_started 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 lights_1_white 0
setstate Bad_Decke_2_mq 2020-12-14 21:40:30 mac 483FDA92803F
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 meters_1_counters_1 1.250
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 meters_1_counters_2 1.250
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 meters_1_counters_3 1.250
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 meters_1_is_valid true
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 meters_1_power 1.25
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 meters_1_timestamp 1607980260
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 meters_1_total 56
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 mode color
setstate Bad_Decke_2_mq 2020-12-14 21:40:30 model SHCB-1
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 mqtt_connected true
setstate Bad_Decke_2_mq 2020-12-14 21:40:30 new_fw false
setstate Bad_Decke_2_mq 2020-12-14 21:40:30 online true
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 pct 28
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 ram_free 38168
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 ram_total 50784
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 red 255
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 rgb FF0000
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 serial 5
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 source http
setstate Bad_Decke_2_mq 2020-12-14 21:52:08 state off
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 temp 3000
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 time 21:11
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 timer_duration 0
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 timer_remaining 0
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 timer_started 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 unixtime 1607980260
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 update_beta_version 20201202-135344/v1.9.3-rc3@50c6ab57
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 update_has_update true
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 update_new_version 20201124-090732/v1.9.0@57ac4ad8
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 update_old_version 20201008-085327/master@a3d98bb0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 update_status pending
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 uptime 1541
setstate Bad_Decke_2_mq 2020-12-14 21:57:00 white 0
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 wifi_sta_connected true
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 wifi_sta_ip 192.168.10.66
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 wifi_sta_rssi -55
setstate Bad_Decke_2_mq 2020-12-14 21:11:00 wifi_sta_ssid hugo_xxxx

PS: für 10 Euro sind die Dinger echt genial. Habe damit nun ein Bad bestückt(5) anstatt Halogen und will eine Art Wellness Bereich daraus machen mit verschiedenen Farbspielen etc

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 14 Dezember 2020, 22:44:20
Hallo,

ZitatIch habe das Template für den rgbw ausprobiert leider klappt nur On/off.

Hab keinen Shelly RGBW-Bulb und frag mich warum es keinen setter für pct beim shelly2rgbw_color-Template gibt ?

Du hast auf jedenfall auf die gezeigte Definition das Template shellybulb angewendet, wenn du jetzt nochmal das shelly2rgbw_color-Template auf das Gerät anwendest gehen dann auch die Farben ?

Gruß

Thomas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TNT0068 am 15 Dezember 2020, 06:38:37
Hallo Tom,
sorry das ich da den falschen Bulb gepostet habe. Ich habe mit den Templates etwas getestet. Nun habe ich das shelly2rgbw_color-Template ausgewählt
Funktionen:
+ on off
+Farbe über den Colorpicker wechseln

- keine Möglichkeit von Color auf Weiss zu wechseln
- kein Dimmen
- keine Verbrauchsanzeige
- kein setzen der internen Shelly scenen zb. Meteor etc

Achja ich nutze den internen MQTT Server von FHEM

danke




define Bad_Decke_2_mq MQTT2_DEVICE shellycolorbulb_483FDA92803F
attr Bad_Decke_2_mq IODev MQTT2
attr Bad_Decke_2_mq devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"power","unknown");; "<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>"}
attr Bad_Decke_2_mq genericDeviceType light
attr Bad_Decke_2_mq icon light_control
attr Bad_Decke_2_mq jsonMap brightness:pct
attr Bad_Decke_2_mq model shelly2rgbw_color
attr Bad_Decke_2_mq readingList shellies/shellycolorbulb-483FDA92803F/color/0/status:.* {json2nameValue($EVENT)}\
  shellies/shellycolorbulb-483FDA92803F/color/0:.* state\
  shellies/shellycolorbulb-483FDA92803F/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...shellycolorbulb-483FDA92803F...mac.*, ? json2nameValue($EVENT) : return }\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/announce:.* { json2nameValue($EVENT) }\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/info:.* { json2nameValue($EVENT) }\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/light/0/power:.* light_0_power\
shellycolorbulb_483FDA92803F:shellies/shellycolorbulb-483FDA92803F/light/0/energy:.* light_0_energy
attr Bad_Decke_2_mq room MQTT2_DEVICE
attr Bad_Decke_2_mq setList off:noArg shellies/shellycolorbulb-483FDA92803F/color/0/command off\
  on:noArg shellies/shellycolorbulb-483FDA92803F/color/0/command on\
  white:colorpicker,BRI,0,1,255 shellies/shellycolorbulb-483FDA92803F/color/0/set {"white":"$EVTPART1"}\
  gain:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-483FDA92803F/color/0/set {"gain":"$EVTPART1"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;;if($1 ne $2 || $2 ne $3) {"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  white_on:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-483FDA92803F/color/0/set {"turn":"on","white":"$EVTPART1"}\
  gain_on:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-483FDA92803F/color/0/set {"turn":"on","gain":"$EVTPART1"}\
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;;if($1 ne $2 || $2 ne $3) {"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellycolorbulb-483FDA92803F/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  effect:selectnumbers,0,1,6,0,lin  shellies/shellycolorbulb-483FDA92803F/color/0/set {"effect":"$EVTPART1"}\
  x_update:noArg shellies/shellycolorbulb-483FDA92803F/command update_fw\
  x_mqttcom shellies/shellycolorbulb-483FDA92803F/command $EVTPART1
attr Bad_Decke_2_mq setStateList on off
attr Bad_Decke_2_mq userReadings rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);;"$a$a$a"}}
attr Bad_Decke_2_mq webCmd on:off:white:gain:rgb:effect

setstate Bad_Decke_2_mq on
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 actions_stats_skipped 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 attrTemplateVersion 20200831
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 blue 23
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 brightness 28
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 cfg_changed_cnt 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 cloud_connected false
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 cloud_enabled false
setstate Bad_Decke_2_mq 2020-12-15 06:29:26 color_0 off
setstate Bad_Decke_2_mq 2020-12-15 06:29:26 ct 3000
setstate Bad_Decke_2_mq 2020-12-15 06:33:09 effect set 3
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 fs_free 156122
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 fs_size 233681
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 fw_ver 20201124-090732/v1.9.0@57ac4ad8
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 gain 49
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 green 77
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 has_timer false
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 has_update false
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 id shellycolorbulb-483FDA92803F
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 ip 192.168.10.66
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 ison true
setstate Bad_Decke_2_mq 2020-12-15 06:33:02 light_0_energy 2
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 light_0_power 0.85
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_blue 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_brightness 28
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_effect 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_gain 49
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_green 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_has_timer false
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_ison false
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_mode color
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_red 255
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_source http
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_temp 3000
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_timer_duration 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_timer_remaining 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_timer_started 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 lights_1_white 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 mac 483FDA92803F
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 meters_1_counters_1 0.613
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 meters_1_counters_2 0.000
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 meters_1_counters_3 0.000
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 meters_1_is_valid true
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 meters_1_power 0.00
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 meters_1_timestamp 1608013780
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 meters_1_total 0
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 mode color
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 model SHCB-1
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 mqtt_connected true
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 new_fw false
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 online true
setstate Bad_Decke_2_mq 2020-12-15 06:29:26 pct 28
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 ram_free 38872
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 ram_total 50808
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 red 255
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 rgb FF4D17
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 serial 2
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 source mqtt
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 state on
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 temp 3000
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 time 06:29
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 timer_duration 0
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 timer_remaining 0
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 timer_started 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 unixtime 1608013780
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 update_beta_version 20201202-135344/v1.9.3-rc3@50c6ab57
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 update_has_update false
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 update_new_version 20201124-090732/v1.9.0@57ac4ad8
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 update_old_version 20201124-090732/v1.9.0@57ac4ad8
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 update_status idle
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 uptime 108
setstate Bad_Decke_2_mq 2020-12-15 06:32:57 white 0
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 wifi_sta_connected true
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 wifi_sta_ip 192.168.10.66
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 wifi_sta_rssi -53
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 wifi_sta_ssid hugo_xxxxx
setstate Bad_Decke_2_mq 2020-12-15 06:29:40 x_mqttcom set announce
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Dezember 2020, 13:18:38
Hmm, den setter für "brightness" würde ich aus dem shelly2rgbw_4w_split ja noch rausklauen und dann das ganze als speechcontrol_type_light_255 ansehen (den split auch...), aber beim Rest wäre ich sehr dankbar, wenn sich das jemand mal vornehmen würde...

Ein paar noch sehr generelle Anmerkungen (u.a.) zum Thema Shelly:
M.E. sollte man auch den "announce"-Teil rausnehmen und diese Infos dann ggf. nur noch in einem Zentraldevice anzeigen. Da die Shelly allesamt wohl mit jeder firmware-Aktualisierung noch gesprächiger werden, wäre ich auch stark dafür, die event-on-.*-Attribute exemplarisch zu setzen, vgl. diesen Thread: https://forum.fhem.de/index.php/topic,116658.msg1110215.html#msg1110215 (https://forum.fhem.de/index.php/topic,116658.msg1110215.html#msg1110215) (oder als erweiterten Hintergrund den Thread, der über folgendes Zitat zu finden ist:
Zitat von: rudolfkoenig am 13 Dezember 2020, 14:37:49
Insgesamt ist das System mit [...] zu viel fuer ein RPi3, besonders wenn nur die MQTT Clients schon 100+ Nachrichten/sec generieren. Ich wuerde diese Datenflut verkleinern und ein Hardware-Upgrade einplanen.
.

Ich will aber nochmal daran erinnern, dass ich selbst praktisch keine Shelly- oder Tasmota-Geräte im Einsatz habe, und daher zwar willens bin, sinnvolle Vorschläge ins svn zu übernehmen, damit das für alle verfügbar wird, aber wenig Neigung verspüre, die ganze diesbezügliche Arbeit alleine zu machen...!
Das mit den massenhaften Events ist - kurz gesagt - euer Problem, weniger meines. (Oder ist es etwa kein Problem, wenn man Hardware nachrüsten muss, nur weil firmwares nicht "schlank" programmiert bzw. konfiguriert sind und wir es nicht hinbekommen, nur den relevanten Teil aus der Datenflut zu fischen?!?)...

(Bei Gelegenheit schreibe ich das auch noch in den "Tasmota"-Thread rein, aber da scheint es seit Version 8.x wenigstens die Option zu geben, Schwellenwerte zu setzen).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: hyper2910 am 02 Januar 2021, 15:04:34
Hallo,  nutze einen RGBW2 aber nur für White um damit 4einzelne LEDs zu steuern.

Habe die per MQTT eingebunden, und das entsprechende Template ausgewählt, nur ist keine Dimmung möglich nur An/aus.

Jemand eine Idee?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Januar 2021, 06:46:17
Hmm, hattest du "shelly2rgbw_4w_split" ausgewählt und ist dein FHEM aktuell? Soweit ich das erst mal nachvollzogen habe, sind da setList-Einträge für brightness vorhanden.

Sonst bitte je ein "vorher-nachher" RAW-list.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: hyper2910 am 03 Januar 2021, 12:11:13
Hi

Angelegt worden ist das Device mit einem WEBCMD. PCT, was es nicht gibt, ich habe dieses auf Brightness geändert und die Steps auf 100 gestellt, da es ja nur 0-100 gibt. Danach funktioniert es.

Aber was ist der Unterschied zwischen Brightness und Brightness-on?


Gruss Dirk

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kjmEjfu am 03 Januar 2021, 13:38:38
Zitat von: MadMax-FHEM am 28 November 2020, 17:27:56
Entsprechende WLAN-Infrastruktur (!=Fritzbox ;)  ) vorhanden und nicht eh schon "zu viel" Wifi in der Umgebung?

etwas OT, aber weil ich gerade auch vermehrt Shellys (und Tasmota) verbaue: was wäre denn eine preisgünstige WLAN-Infrastuktur? Bei der Fritzbox merkt man tatsächlich so langsam ein nachlassendes WLAN.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: frober am 03 Januar 2021, 13:51:06
Zitat von: kjmEjfu am 03 Januar 2021, 13:38:38
etwas OT, aber weil ich gerade auch vermehrt Shellys (und Tasmota) verbaue: was wäre denn eine preisgünstige WLAN-Infrastuktur? Bei der Fritzbox merkt man tatsächlich so langsam ein nachlassendes WLAN.

Prinzipiell muss man die Clients auf mehrere Accesspoints verteilen. Die APs sind per LAN anzuschließen, ob Repeater auch genügen kann ich nicht beurteilen, vermute aber nicht.
Beim Verteilen unterschiedliche Kanäle, die sich am besten nicht überschneiden.
Oder bessere Hardware ;)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 03 Januar 2021, 13:58:19
Zitat von: kjmEjfu am 03 Januar 2021, 13:38:38
etwas OT, aber weil ich gerade auch vermehrt Shellys (und Tasmota) verbaue: was wäre denn eine preisgünstige WLAN-Infrastuktur? Bei der Fritzbox merkt man tatsächlich so langsam ein nachlassendes WLAN.

Definiere "preisgünstig"... ;)

Und wie meist: preisgünstig und "taugt was" ist halt oft nicht zusammen zu kriegen...

Bzw. kann man auch einen "günstigen" WLAN-Router mit z.B. openWRT nehmen, für die Shellys dann ein eigenes WLAN "aufspannen" und eben per LAN-Kabel an die FB dran hängen...

ABER: alle Funk-Kisten (auch fremde) TEILEN sich die Luft! Also nur weil es eine andere SSID ist und von einer anderen HW (WLAN-Router) "zur Verfügung gestellt" wird heißt das nicht, dass sich das nicht gegenseitig "stört"...

Also sind auch Kanalwahl etc. wichtig...
...und auch hier: die Anzahl von Clients und was die so "brauchen"...

Viele hier haben Unifi-APs (und Router/Switche) im Einsatz.
Ist aber eher nicht Kategorie "günstig" (auch wenn es für die [theoretischen] "Leistungen" [quasi "professionell"] schon "bezahlbar" ist verglichen mit Cisco, Aruba, ...).

Aber: das ist ein reiner WLAN-AP sonst nix!
(geht aber sicher auch zusammen mit einer FB / dort dann WLAN lassen [aber andere SSID, damit sich bestimmte Clients halt nur da oder "dort" verbinden], siehe "oben" oder eben deaktivieren)

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kjmEjfu am 03 Januar 2021, 14:16:49
Zitat von: MadMax-FHEM am 03 Januar 2021, 13:58:19
Definiere "preisgünstig"... ;)

Und wie meist: preisgünstig und "taugt was" ist halt oft nicht zusammen zu kriegen...

ok, preisgünstig war der falsche Begriff. Preiswert wäre passender gewesen :-)


Zitat von: MadMax-FHEM am 03 Januar 2021, 13:58:19
Viele hier haben Unifi-APs (und Router/Switche) im Einsatz.
Ist aber eher nicht Kategorie "günstig" (auch wenn es für die [theoretischen] "Leistungen" [quasi "professionell"] schon "bezahlbar" ist verglichen mit Cisco, Aruba, ...).

Ja, Richtung Unifi tendiere ich tatsächlich im Moment. Wobei meine Idee war das etwas schwache WLAN der Fritzbox komplett zu deaktivieren (und die nur noch für Ethernet und Internet zu nehmen) und stattdessen rein Unifi zu nutzen.
Muss ich wohl mal durchdenken.

Danke für die Tipps!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 03 Januar 2021, 14:54:46
Zitat von: kjmEjfu am 03 Januar 2021, 14:16:49
Ja, Richtung Unifi tendiere ich tatsächlich im Moment. Wobei meine Idee war das etwas schwache WLAN der Fritzbox komplett zu deaktivieren (und die nur noch für Ethernet und Internet zu nehmen) und stattdessen rein Unifi zu nutzen.

Habe ich auch so laufen :)

Allerdings muss ich sagen war ich zunächst "enttäuscht" von der WLAN-Kraft.
Ich hatte zuvor einen Netgear Nighthawk ("all-in-wonder" nach der FB, die "brauche" ich als DSL-Modem und Telefonbox) und der war echt "kräftig".
Allerdings hatte ich in manchen Ecken halt nicht "ausreichend" WLAN (oder dachte: das muss doch besser gehen ;) ).

Dachte ich könnte statt dem Nighthawk einen Unifi-AP (UAP-AC-Pro) nehmen.
Pustekuchen...

Mittlerweile habe ich 3 APs wo vorher der Nighthawk gewerkelt hatte, gut jetzt nat. mit "Ausleuchtung" wie ich sie will aber halt auch mit 3 APs statt einem "all-in-wonder" (und sooo schlecht war es vorher nicht ;)  )...

Aber sicher kann ein Unifi-AP "stabiler" als eine FB und auch mit mehr Clients...

So, genug OT! (sorry schon mal)

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Januar 2021, 15:41:16
Zitat von: hyper2910 am 03 Januar 2021, 12:11:13
Angelegt worden ist das Device mit einem WEBCMD. PCT, was es nicht gibt, ich habe dieses auf Brightness geändert und die Steps auf 100 gestellt, da es ja nur 0-100 gibt. Danach funktioniert es.
Danke für den Hinweis, da muss ich was ändern, steht auch so in der API, dass es im Weiß-Modus 4 Kanäle je von 0-100 sind. Damit ist aber der setter falsch, der solle pct bzw. pct_on sein ...

ZitatAber was ist der Unterschied zwischen Brightness und Brightness-on?
Na ja, zumindest früher war es so, dass ein reiner brightness-Command nicht unbedingt auch angeschaltet hat. (aber ist die setList nicht fast selbsterklärend...?)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: davidgross am 16 Januar 2021, 23:17:36
Hi,
ich hoffe ich bin hier richtig. Ich habe das shelly2rgbw_color template mit colorpicker erfolgreich im Einsatz. Jetzt habe ich mir noch eine Funktion mit festen Farben hinzugefügt und fand einen kleinen Bug.
Könnt ihr im userreading anstatt: rgb:red.*  dies eintragen: rgb:(red|green|blue).*

Zusätzlioch wäre eine Funktion mit festen (in einem reading) veränderbaren Farben für mich eine sinnvolle Ergänzung. Das Gespiele auf dem Colorpicker ist zwar nett aber nicht sehr effektiv. Allerdings habe ich meine Umschaltung in ein Doif ausgelagert. Nicht sehr elegant, aber funktioniert.
im shelly:
setList colorpreset:Kerze,Lampe,Sonne,Rot,Grün,Blau $EVTPART1


define WoziRGB_Doif DOIF ([MQTT2_shellyrgbw2_6621A5:colorpreset]) ({\
  my $val1=ReadingsVal("MQTT2_shellyrgbw2_6621A5", "colorpreset" , 0 );;\
  fhem "setreading $SELF diag1 $val1";;\
  if ($val1 eq "set Kerze")    { fhem "set MQTT2_shellyrgbw2_6621A5 rgb ff6d00";;;; fhem "setreading MQTT2_shellyrgbw2_6621A5 colorpreset Kerze";;}\
  elsif ($val1 eq "set Lampe") { fhem "set MQTT2_shellyrgbw2_6621A5 rgb ffa54f";;;; fhem "setreading MQTT2_shellyrgbw2_6621A5 colorpreset Lampe";;}\
  elsif ($val1 eq "set Sonne") { fhem "set MQTT2_shellyrgbw2_6621A5 rgb fff0e9";;;; fhem "setreading MQTT2_shellyrgbw2_6621A5 colorpreset Sonne";;}\
  elsif ($val1 eq "set Rot")   { fhem "set MQTT2_shellyrgbw2_6621A5 rgb FF2626";;;; fhem "setreading MQTT2_shellyrgbw2_6621A5 colorpreset Rot";;}\
  elsif ($val1 eq "set Grün")  { fhem "set MQTT2_shellyrgbw2_6621A5 rgb 26FF26";;;; fhem "setreading MQTT2_shellyrgbw2_6621A5 colorpreset Grün";;}\
  elsif ($val1 eq "set Blau")  { fhem "set MQTT2_shellyrgbw2_6621A5 rgb 2626FF";;;; fhem "setreading MQTT2_shellyrgbw2_6621A5 colorpreset Blau";;}\
})
attr WoziRGB_Doif do always

VG
   
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Januar 2021, 08:43:54
Zitat von: davidgross am 16 Januar 2021, 23:17:36
Hi,
ich hoffe ich bin hier richtig. Ich habe das shelly2rgbw_color template mit colorpicker erfolgreich im Einsatz. Jetzt habe ich mir noch eine Funktion mit festen Farben hinzugefügt und fand einen kleinen Bug.

ad "fand einen kleinen Bug (https://forum.fhem.de/index.php/topic,13092.msg105687.html#msg105687)". Kannst du das bitte mit etwas MQTT-Verkehr belegen (https://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html), warum dein Vorschlag zielführender ist als die (evtl. hier unnötigerweise) einschränkende regexp, die jetzt da steht?

Zu dem Vorschlag: nehme gerne was "internationalisiertes" in die setList auf, dieser Umweg ist in der Tat unnötig:
candle:noArg <topic> <passende rgb-payload>
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: JJ_Pamoux am 17 Januar 2021, 16:42:55
Neuere Firmware-Versionen verhindern das Anzeigen der schönen fts_shutter_[up|down] Icons.

Alte Firmware:

2021-01-17 16:36:36.789 MQTT2_DEVICE rollo_wz_giebel set_close
2021-01-17 16:36:37.202 MQTT2_DEVICE rollo_wz_giebel closing
2021-01-17 16:36:37.202 MQTT2_DEVICE rollo_wz_giebel current: close

Neue Firmware:

2021-01-17 16:22:05.163 MQTT2_DEVICE rollo_wz_tuer_l set_close
2021-01-17 16:22:05.255 MQTT2_DEVICE rollo_wz_tuer_l current: close
2021-01-17 16:22:05.255 MQTT2_DEVICE rollo_wz_tuer_l closing
2021-01-17 16:22:05.324 MQTT2_DEVICE rollo_wz_tuer_l pct: 100
2021-01-17 16:22:05.324 MQTT2_DEVICE rollo_wz_tuer_l 100


Die neue Firmware teilt halt direkt noch einmal mit, wie der Stand vor (!) dem Kommando wahr. Leider hat das dann natürlich direkte Auswirkungen auf das Icon. Eine schnelle Lösung ist mir da jetzt nicht eingefallen, aber ich wollte das wenigstens kurz mal melden.

Die Chatiness von Shelly im Zusammenhang mit MQTT lässt sich natürlich etwas reduzieren, indem man das entsprechende Setting setzt, siehe: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Shelly
Ich setze dabei aber nicht direkt "0", sondern halt irgendwas deutlich größer als den Standardwert (30). Kann man ja entsprechend selbst einmal experimentieren.

WLAN-Clients bleiben die Dinger natürlich. Demnach sollte man für viele Geräte schon gute WLAN-Hardware anschaffen (Beispiele wurden ja genannt, u.a. Unifi).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: davidgross am 17 Januar 2021, 19:21:55
Zitat von: Beta-User am 17 Januar 2021, 08:43:54
ad "fand einen kleinen Bug (https://forum.fhem.de/index.php/topic,13092.msg105687.html#msg105687)". Kannst du das bitte mit etwas MQTT-Verkehr belegen (https://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html), warum dein Vorschlag zielführender ist als die (evtl. hier unnötigerweise) einschränkende regexp, die jetzt da steht?
Das ist kein Bug beim MQTT auslesen. Das Problem ist nur das die Aktualisierung der Anzeige des RGB-Wertes auf Änderungen vom :red wartet. Wenn sich der red-Wert aber nicht verändert (da z.b. immer 255) gibt es auch keine Änderung des angezeigten RGB-Wertes. rgb:(red|green|blue).*  reagiert auf jegliche Änderung der Farben. Wie gesagt nur im userReadings.


Zitat von: Beta-User am 17 Januar 2021, 08:43:54
Zu dem Vorschlag: nehme gerne was "internationalisiertes" in die setList auf, dieser Umweg ist in der Tat unnötig:
candle:noArg <topic> <passende rgb-payload>
Natürlich.  :)

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Januar 2021, 19:44:46
Zitat von: davidgross am 17 Januar 2021, 19:21:55
Das ist kein Bug beim MQTT auslesen. Das Problem ist nur das die Aktualisierung der Anzeige des RGB-Wertes auf Änderungen vom :red wartet.
Hmmm, ja, vielleicht, vielleicht auch nicht....

Mein "Problem": _für eine Leuchte_ halte ich ein Sendeintervall von "0" für "korrekt" und das "Setzen von eocr .*" für "falsch".... (das ist ein eigenes "add-on", das dieses "Problem" verursacht, unterstelle ich mal). Muß mal drüber nachdenken, aber da das ein bulk-update ist, ist es an der Stelle vermutlich egal...

Es wäre nett, wenn die Shelly-User sich da auch zur Frage, für welche Devices welche Einstellungen der firmware sinnvoll sind irgendwie zusammentun, damit wir da was konsolidiertes hinbekommen (siehe die Initiative von @gestein hier: https://forum.fhem.de/index.php/topic,117446.msg1118413.html#msg1118413




Zu dem Rollo-Thema fällt mir im Moment auch nichts ein...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 24 Januar 2021, 12:50:49
Zitat von: JJ_Pamoux am 17 Januar 2021, 16:42:55
Neuere Firmware-Versionen verhindern das Anzeigen der schönen fts_shutter_[up|down] Icons. ............
Eine schnelle Lösung ist mir da jetzt nicht eingefallen, aber ich wollte das wenigstens kurz mal melden.
Zitat von: Beta-User am 17 Januar 2021, 19:44:46
Zu dem Rollo-Thema fällt mir im Moment auch nichts ein...

Hallo,
da einige DOIF's nicht mehr funktionierten, ist mir das Problem auch aufgefallen. Ich habe es bei mir so gelöst.
attr devStateIcon.*/open:fts_shutter_up@red .*/close:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0/stop:fts_shutter_100 100/stop:fts_shutter_10 9\d/stop:fts_shutter_10 8\d/stop:fts_shutter_20 7\d/stop:fts_shutter_30 6\d/stop:fts_shutter_40 5\d/stop:fts_shutter_50 4\d/stop:fts_shutter_60 3\d/stop:fts_shutter_70 2\d/stop:fts_shutter_80 1\d/stop:fts_shutter_90 0\d/stop:fts_shutter_100 set_.*:fts_shutter_updown
attr stateFormat<a href="http://ip" target="_blank">
online
</a>
state/current


Funktioniert soweit!

Gruß
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Dersch am 12 Februar 2021, 19:05:45
Das MQTT2 Template für den Shelly RGBW2 funktioniert bei mir leider so gar nicht. Ich betreibe schon mehrere Shellys mit MQTT aber hier stehe ich vor einem Rätsel.

FW ist die 20201124-092159/v1.9.0@57ac4ad8

Internals:
   CFGFN     
   CID        shellyrgbw2_80E6E7
   DEF        shellyrgbw2_80E6E7
   DEVICETOPIC MQTT2_shellyrgbw2_80E6E7
   FUUID      6026b84f-f33f-c2c3-a065-cadffde571732ecf
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 70
   MQTT2_TIME 2021-02-12 19:01:20
   MSGCNT     70
   NAME       MQTT2_shellyrgbw2_80E6E7
   NR         3718
   STATE      set_on
   TYPE       MQTT2_DEVICE
   READINGS:
     2021-02-12 18:59:55   attrTemplateVersion 20201215
     2021-02-12 19:01:20   online          false
     2021-02-12 18:48:54   state           set_on
     2021-02-12 18:59:55   x_mqttcom       set announce
Attributes:
   DbLogExclude .*
   IODev      MQTT2
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot"; my $light = ReadingsVal($name,"state","off"); my $cons = ReadingsVal($name,"power","unknown"); "<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>"}
   genericDeviceType light
   homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
   icon       light_control
   model      shelly2rgbw_color
   readingList shellies/shellyrgbw2-80E6E7/color/0/status:.* {json2nameValue($EVENT)}
  shellies/shellyrgbw2-80E6E7/color/0:.* state
  shellies/shellyrgbw2-80E6E7/online:.* online
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-80E6E7...mac.*, ? json2nameValue($EVENT) : return }
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shellyrgbw2-80E6E7/color/0/command off
  on:noArg shellies/shellyrgbw2-80E6E7/color/0/command on
  brightness:colorpicker,BRI,0,1,255 shellies/shellyrgbw2-80E6E7/white/0/set {"mode":"white","brightness":"$EVTPART1"}
  white:colorpicker,BRI,0,1,255 shellies/shellyrgbw2-80E6E7/color/0/set {"white":"$EVTPART1"}
  gain:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-80E6E7/color/0/set {"gain":"$EVTPART1"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-80E6E7/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-80E6E7/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  white_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-80E6E7/color/0/set {"turn":"on","white":"$EVTPART1"}
  gain_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-80E6E7/color/0/set {"turn":"on","gain":"$EVTPART1"}
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-80E6E7/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-80E6E7/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  effect:selectnumbers,0,1,6,0,lin  shellies/shellyrgbw2-80E6E7/color/0/set {"effect":"$EVTPART1"}
  x_update:noArg shellies/shellyrgbw2-80E6E7/command update_fw
  x_mqttcom shellies/shellyrgbw2-80E6E7/command $EVTPART1
   setStateList on off
   userReadings rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
   webCmd     on:off:white:gain:rgb:effect
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: kabanett am 12 Februar 2021, 19:42:14
Vieleicht eine blöde Frage, aber was funktioniert denn so gar nicht?
Bis auf dein Hombridge und Dblog, schauts bei mir genau so aus.
Scheinbar war er auch noch nicht online     2021-02-12 19:01:20   online          false, da die ganzen Readings fehlen.....?!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Dersch am 12 Februar 2021, 20:02:49
Genau das ist ja das Problem. Er ist online aber es entstehen keine Readings.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 12 Februar 2021, 20:07:24
Na ja, das Reading "online" ist auf false, was man so deuten kann, dass er für den Server (MQTT2_SERVER?) offline ist.
Die Frage ist eher, warum, denn das ist ja recht frisch...
subscriptions sind auch keine zu sehen, was anders sein sollte, wenn SERVER verwendet wird.
WLAN-Probleme kannst du ausschließen? (Log-Einträge?)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Dersch am 12 Februar 2021, 20:18:35
War ein typischer DAU Fall. Ich habe das Passwort vom MQTT2 Server falsch im Shelly gesetzt. Da er aber dennoch via autocreate in FHEM das Device angelegt hat bin ich nicht davon ausgegangen das hier ein Fehler wäre. Jetzt geht natürlich alles.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MrTom am 25 Februar 2021, 21:16:57
Hallo zusammen

ich habe heute meine Shelly Motions bekommen und mal ein wenig damit rumgespielt. Die gefallen mir gar nicht schlecht.

Anbei mal ein erster Vorschlag für ein Template
name:shellymotion
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellymotion using original firmware.
order:A_19
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
par:ICON;ICON as set, defaults to motion_detector;{ AttrVal("DEVICE","icon","motion_detector") }
attr DEVICE icon ICON
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot"; \
my $moti = ReadingsVal($name,"motion","false") eq "true"?"message_presence\@red":"message_presence\@white"; \
"<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($moti)."</a>"}
attr DEVICE readingList shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/sensor/status:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }
attr DEVICE setList x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE model shellymotion
setreading DEVICE attrTemplateVersion 20210225


Man möge mir etwaige Fehler verzeihen. Ich bin Informatiker jedoch kein Programmier, dafür umsomehr FHEM-Enthusiast. Ich freue micht auch über Korrekturen und Verbesserungen.

Schönen Gruss aus der Schweiz
Thomas
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 26 Februar 2021, 07:48:18
Danke, ist (mit Symbolwechsel statt Farbe) eingecheckt!

(Das Farbthema sollte ich wohl nochmal irgendwie klarstellen: Das ist keine Kritik, es geht da nur darum, dass es mit allen Farbschemata "hübsch" aussieht, und z.B. in f18-dark ist erzwungenes weiß nicht so prickelnd...). Daher versuche ich das via attrTemplate möglichst so anzubieten, dass es neutral/ohne Farbe ist.)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 26 Februar 2021, 09:58:54
Zitates geht da nur darum, dass es mit allen Farbschemata "hübsch" aussieht,
Das geht "richtig" nur mit CSS-Klassen.
Leider doof, wenn man etwas haben will, was in der CSS noch nicht exisiert.
Ich bin aber bereit "meine" Styles zu erweitern.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 05 März 2021, 16:20:38
Hallo zusammen,
nachdem ich jetzt aus privaten Gründen viele viele Monate vollkommen raus bin aus FHEM, Shelly und Homekit (alles lief stabil die ganze Zeit!)
mal ne ganz blöde Anfängerfrage. Wie update ich die Templates und aktualisieren die sich dann auch auf für bestehende devices?
Einfach indem ich alle FHEM Module update?
Gruß
Jan
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 März 2021, 16:30:09
Zitat von: stratege-0815 am 05 März 2021, 16:20:38
Wie update ich die Templates und aktualisieren die sich dann auch auf für bestehende devices?
Die attrTemplate-files selbst werden via normalem update (mit) aktualisiert, wirken sich aber nur aus, wenn man sie (wieder) anwendet.

Wenn du funktionierende Devices hast, würde ich eher dazu neigen, alles zu lassen, wie es ist... (es hat sich an vielen Stellen auch nicht viel getan).
Ggf. kannst du dir auch vorher anzeigen lassen, was das template machen würde, und über model/attrTemplateVersion ist es möglich nachzuvollziehen, ob überhaupt was geändert wurde (und via svn auch, was).

Zitat von: rudolfkoenig am 26 Februar 2021, 09:58:54
Das geht "richtig" nur mit CSS-Klassen.
Leider doof, wenn man etwas haben will, was in der CSS noch nicht exisiert.
Ich bin aber bereit "meine" Styles zu erweitern.
Mein Beitrag war nicht als Kritik gemeint, und wenn es darum ging, mich für irgendeine konkrete Aktion "aufzuschlauen", kann ich leider mit dem Stichwort zu wenig anfangen, um daraus Kapital zu schlagen.
Das war von meiner Seite nur so gemeint, dass ich die attrTemplate-Vorschläge teils deswegen ändere, weil ich niemandem irgendein Farbschema aufzwingein will...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: th0nix am 23 März 2021, 23:34:37
Super - Danke für's shellymotion template.

Kleiner Verbesserungsvorschlag für das Template (shellymotion)

In devStateIcon sollte meines Erachtens nach das Leerzeichen nach people_sensor in Zeile 2 raus? Dann gehen die Icons  ;)


attr Esszimmer.Motion devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; \
my $moti = ReadingsVal($name,"motion","false") eq "true"?"people_sensor ":"message_presence";; \
"<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($moti)."</a>"}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 27 Mai 2021, 15:01:15
Hallo,

seit gestern habe ich meine Shelly Duo RGB GU10 :)

Mit MQTT mache ich nicht wirklich viel.
Prinzip glaube ich verstanden zu haben, so halbwegs...
...aber die Konfiguration in fhem übersteigt mich ;)

Bzw. klar "attrTemplate", dann werden (gefühlt) tausend Attribute etc. gesetzt und alles gut (wenn es passt)... :)
Mehr "kann" ich bzgl. MQTT nicht 8)

Daher habe ich zunächst versucht auch diesen Shelly (wie meine anderen) mittels Shelly-Modul einzubinden (ShellyMonitor geht bei mir nicht, irgendwie kriege ich das mit meinem VLAN-Setup nicht zum Laufen, egal).
Allerdings gibt es da auch noch kein "model" bzw. "model/mode" Kombination die mir "gefällt".

Gut dachte ich mir: MQTT :)

Gesagt getan. MQTT im Shelly aktiviert und "schwupps" war das Device in meinem fhem da :)
Dann geschaut nach einem attrTemplate.

Hmmm.
Ich habe ein paar ausprobiert und aktuell bin ich eigentlich mit dem "ShellyBulb" attrTemplate ganz zufrieden...

Also es lassen sich die Weißwerte setzen und auch die farbwerte, alles prime.

Nur der Status stimmt nicht.
Also ich kann per set Device on/off ein-/ausschalten aber es bleibt auf set_on/set_off "hängen" und damit auch auf dem "Ausrufezeichen-Icon"...

Ich hab auch schon andere attrTemplates durch, also z.B. das Duo. Aber da geht ja nur Weiß!?

Also wie geschrieben, wenn noch der Status stimmen würde, dann wäre es PERFEKT :)

Was kann ich tun, damit das funktioniert?

P.S.: wäre es möglich zu sehen, welches attrTemplate gerade angewendet ist? Z.B. im attr comment? Oder ich bin zu blind zu finden wo man das jetzt schon rausfinden kann...

DANKE, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 27 Mai 2021, 15:12:55
Auf die Gefahr hin, dass ich zu schnell bin und Zwischenedits übersehe...:
Zitat von: MadMax-FHEM am 27 Mai 2021, 15:01:15
Also ich kann per set Device on/off ein-/ausschalten aber es bleibt auf set_on/set_off "hängen" und damit auch auf dem "Ausrufezeichen-Icon"...
Dann kommt entweder nichts passendes vom Shelly zurück (das auf state geschrieben werden könnte), oder es fehlt die Info, was passen würde (dann kann man das fixen).

ZitatWas kann ich tun, damit das funktioniert?
Infos liefern :) . Aus meiner Sicht fehlt:
a) ein RAW-listing, damit "andere" einfacher spielen können, die die Hardware nicht haben ;) ;
b) ein Mittschnitt des MQTT-Verkehrs zum und vom Shelly (RAW-Events vom M2S (?) oder mosquitto_sub, ich brauche aber in jedem Fall auch die Topics, nicht nur die Payload)

Zitat
P.S.: wäre es möglich zu sehen, welches attrTemplate gerade angewendet ist? Z.B. im attr comment? Oder ich bin zu blind zu finden wo man das jetzt schon rausfinden kann...
Es sollte "model" gesetzt sein (Attribut), und ein Reading sollte Aufschluss über die Version geben, welche es konkret war ;) . (Wo war nochmal das RAW-listing...?)

Ansonsten: Willkommen bei MQTT2 8) . Ist nicht so schwer, wie es aussieht...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 27 Mai 2021, 15:22:23
Äh ja klar, RawDef ;)


defmod MQTT2_shellycolorbulb_8CAAB555E45D MQTT2_DEVICE shellycolorbulb_8CAAB555E45D
attr MQTT2_shellycolorbulb_8CAAB555E45D devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"power","unknown");; "<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>"}
attr MQTT2_shellycolorbulb_8CAAB555E45D genericDeviceType light
attr MQTT2_shellycolorbulb_8CAAB555E45D homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
attr MQTT2_shellycolorbulb_8CAAB555E45D icon light_control
attr MQTT2_shellycolorbulb_8CAAB555E45D jsonMap brightness:pct
attr MQTT2_shellycolorbulb_8CAAB555E45D model shellybulb
attr MQTT2_shellycolorbulb_8CAAB555E45D readingList shellies/shellycolorbulb-8CAAB555E45D/color/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/online:.* online\
shellycolorbulb_8CAAB555E45D:shellies/announce:.* { json2nameValue($EVENT) }\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/announce:.* { json2nameValue($EVENT) }\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/info:.* { json2nameValue($EVENT) }\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/color/0:.* color_0\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/light/0/power:.* light_0_power\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/light/0/energy:.* light_0_energy
attr MQTT2_shellycolorbulb_8CAAB555E45D room MQTT2_DEVICE
attr MQTT2_shellycolorbulb_8CAAB555E45D setList off:noArg shellies/shellycolorbulb-8CAAB555E45D/color/0/command off\
  on:noArg shellies/shellycolorbulb-8CAAB555E45D/color/0/command on\
  pct:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-8CAAB555E45D/color/0/set {"gain":"$EVTPART1","brightness":"$EVTPART1"}\
  pct_on:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-8CAAB555E45D/color/0/set {"turn":"on","gain":"$EVTPART1","brightness":"$EVTPART1"}\
  ct:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);;"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
  ct_on:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);;"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;;if($1 ne $2 || $2 ne $3){"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;;if($1 ne $2 || $2 ne $3){"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  x_update:noArg shellies/shellycolorbulb-8CAAB555E45D/command update_fw\
  x_mqttcom shellies/shellycolorbulb-8CAAB555E45D/command $EVTPART1
attr MQTT2_shellycolorbulb_8CAAB555E45D setStateList on off
attr MQTT2_shellycolorbulb_8CAAB555E45D userReadings ct:temp.* {ReadingsVal($name,"temp",3000)}, rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);;"$a$a$a"}}
attr MQTT2_shellycolorbulb_8CAAB555E45D webCmd on:off:pct:ct:rgb

setstate MQTT2_shellycolorbulb_8CAAB555E45D set_off
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:37:19 IODev MQTT2Server
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 actions_stats_skipped 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 attrTemplateVersion 20200522 or prior
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 blue 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:26:32 brightness 100
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 cfg_changed_cnt 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 cloud_connected false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 cloud_enabled false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 color_0 off
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 ct 3000
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 effect 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:24:02 energy 1
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 fs_free 159385
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 fs_size 233681
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 fw_ver 20210429-095910/v1.10.4-g3f94cd7
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 gain 11
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 green 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 has_timer false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 has_update false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 id shellycolorbulb-8CAAB555E45D
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 ip 192.168.10.167
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 ison false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 light_0_energy 26
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 light_0_power 0.00
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_blue 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_brightness 11
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_effect 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_gain 11
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_green 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_has_timer false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_ison true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_mode white
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_red 255
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_source http
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_temp 3000
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_timer_duration 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_timer_remaining 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_timer_started 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_white 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 mac 8CAAB555E45D
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_counters_1 1.378
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_counters_2 1.378
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_counters_3 1.378
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_is_valid true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_power 1.38
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_timestamp 1622126303
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_total 24
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 mode white
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 model SHCB-1
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 mqtt_connected true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 new_fw false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 online true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 pct 11
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 ping_check true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:24:02 power 0.00
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 ram_free 37776
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 ram_total 50200
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 red 255
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 rgb FFFFFF
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 serial 42
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 source mqtt
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:28:23 state set_off
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 temp 3000
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 time 14:38
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 timer_duration 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 timer_remaining 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 timer_started 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 unixtime 1622119103
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 update_has_update false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 update_new_version
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 update_old_version 20210429-095910/v1.10.4-g3f94cd7
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 update_status unknown
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 uptime 1020
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 15:47:23 white 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 wifi_sta_connected true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 wifi_sta_ip 192.168.10.167
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 wifi_sta_rssi -67
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 wifi_sta_ssid My-Network
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 x_mqttcom set announce



EDIT: rawDef jatzt vom korrekten Device, peinlich...

Ok, RawEvents da muss ich mal schauen wie ich das mache...
...kommt gleich (oder später je nachdem ;) )...

Und ja, ganz simpel: MQTT2Server in fhem und gut is :)

EDIT: ok, model. Wenn man's weiß isses einfach (wie so oft ;)  )...

EDIT: was mich "wundert": ich habe beim Auswählen des attrTemplate angegeben "ignore speech..." trotzdem sind genericDeviceType und homebridgeMapping gesetzt. Nicht, dass es mich stören würde (habe ja keinen alexaName von daher kein Problem). Braucht man das? Kann man das einfach löschen? Und: wenn ich das attrTemplate erneut anwende was passiert mit meinen Änderungen? Verm. "alle weg"?!

Danke schon mal, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 27 Mai 2021, 15:34:19
Hmm, mag ja einfach sein das MQTT(2)-Zeugs ;)

Aber hierfür bin ich zu doof:

Zitat
rawEvents <topic-regexp>
Send all messages as events attributed to this MQTT2_SERVER instance. Should only be used, if there is no MQTT2_DEVICE to process the topic.

Also ich habe mal folgendes gesetzt:

attr MQTT2Server rawEvents .*shellycolorbulb.*

Sollte doch eine dafür geeignete RegExp sein?
Und dann?

Beim Device steht ja:
Zitat
DEVICETOPIC MQTT2_shellycolorbulb_8CAAB555E45D

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 27 Mai 2021, 15:45:17
attr MQTT2Server rawEvents shellies/shellyrgbw2-80E656/.*

Damit sieht man im Eventmonitor was unter diesen Topics reinkommt:
attr MQTT2_shellyrgbw2_80E656 readingList shellies/shellyrgbw2-80E656/color/0/status:.* {json2nameValue($EVENT)}\
  shellies/shellyrgbw2-80E656/color/0:.* state\
  shellies/shellyrgbw2-80E656/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-80E656...mac.*, ? json2nameValue($EVENT) : return }\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/announce:.* { json2nameValue($EVENT) }\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/info:.* { json2nameValue($EVENT) }\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/color/0/energy:.* color_0_energy\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/input/0:.* input_0\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/color/0/power:.* color_0_power\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/color/0/overpower:.* color_0_overpower


Und nicht vergessen das rawEvents-Attribut wieder zu löschen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 27 Mai 2021, 15:47:28
Oh VERDAMMT!!

SORRY, das war das falsche Device.

Ich habe parallel noch wieder meinen RGBW2-Controller in Betrieb genommen...
...um zu sehen wie er mir besser gefällt: Shelly-Modul oder MQTT2Device...

Also ich nehm das oben als RawDef raus und das richtige rein...

ENTSCHULDIGUNG!!!!

Und rawEvents jetzt so: shellies/shellycolorbulb-8CAAB555E45D/.*
müsste ja passen.

Trotzdem: und dann?
Gut vielleicht sehe ich ja was wenn ich's richtig mache ;)

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 27 Mai 2021, 15:49:08
Grummel, das RAW (unabhängig davon, ob es das richtige war) sieht so aus, als hätten die Shelly-Macher jetzt auch vollends diesen unseligen "Mega-JSON-Virus" mit "true" statt "on" usw....

Vielleicht ein paar erweiterte Hinweise:

Der Teil kommt aus dem attrTemplate:

attr MQTT2_shellyrgbw2_80E656 readingList shellies/shellyrgbw2-80E656/color/0/status:.* {json2nameValue($EVENT)}\
  shellies/shellyrgbw2-80E656/color/0:.* state\
  shellies/shellyrgbw2-80E656/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-80E656...mac.*, ? json2nameValue($EVENT) : return }\

Der Teil wird von autocreate ergänzt:
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/announce:.* { json2nameValue($EVENT) }\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/info:.* { json2nameValue($EVENT) }\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/color/0/energy:.* color_0_energy\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/input/0:.* input_0\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/color/0/power:.* color_0_power\
shellyrgbw2_80E656:shellies/shellyrgbw2-80E656/color/0/overpower:.* color_0_overpower


Es kommt uU. aber doch irgendwann und irgendwie ein "on" zurück:
setstate MQTT2_shellyrgbw2_80E656 on
setstate MQTT2_shellyrgbw2_80E656 2021-05-27 15:18:53 state on

Wenn es lange dauert, bis das der Fall ist, klingt es nach einem Kommunikationsproblem (außerhalb FHEM).

Z.B. das hier deutet darauf hin, dass es ziemlich verschachtelter JSON ist, der übermittelt wird:
setstate MQTT2_shellyrgbw2_80E656 2021-05-27 15:10:08 actions_stats_skipped 0
Leider kann man daran nicht mehr sehen, über welchen Topic das reinkam (wie bei anderem auch nicht). Eventuell wäre es gut, mal darüber nachzudenken, was man überhaupt braucht und den Rest ggf. schlicht nicht auszuwerten.
(Evtl. kannst du auch den jeweiligen JSON zusätzlich in ein "Klartextreading" (passend zum Topic) einfangen, indem du (zusätzlich) jede j2nv()-Zeile doppelst und dann einen eindeutigen Namen vergibst (z.B. "json_<short_topic>").

Zitat von: MadMax-FHEM am 27 Mai 2021, 15:22:23
EDIT: was mich "wundert": ich habe beim Auswählen des attrTemplate angegeben "ignore speech..." trotzdem sind genericDeviceType und homebridgeMapping gesetzt. Nicht, dass es mich stören würde (habe ja keinen alexaName von daher kein Problem). Braucht man das?
Klingt nach nicht beabsichtigt; wundert mich, dass sich da bisher keiner gewundert hätte (oder ich habe das übersehen).
Mal sehen, ob ich das bei Gelegenheit fixen kann (falls nicht jemand schneller Ideen dazu hat).

Zitat
Kann man das einfach löschen? Und: wenn ich das attrTemplate erneut anwende was passiert mit meinen Änderungen? Verm. "alle weg"?!
Den Teil kann man löschen, bei anderen Attributen ist das teils nicht so einfach, weil manches nur in Kombination funktioniert (klassisch: j2nv() und jsonMap iVm. stateFormat/devStateIcon).

Du kannst vor dem neuerlichen Anwenden eines attrTemplate sehen, was es macht. Meistens wird eben ein Satz Attribute gesetzt und die meisten Readings gelöscht. Alles andere bleibt unverändert.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 27 Mai 2021, 15:57:05
Also beim RGBW2 geht eigentlich alles (irgendwie), habe aber noch nicht wirklich viel gemacht... ;)

Wenn ich ehrlich bin: ich verstehe nur die Hälfte von dem was du geschrieben hast. Bzw. brauche ich da etwas Ruhe, um das mal durchzuspielen...
(bin von der schnellen Reaktion ja fast ein wenig "überfahren" ;)  )

Gibt es was, dass ich "schnell" noch liefern kann?
EDIT: Attribut rawEvents habe ich gesetzt aber irgendwie weiß ich nicht was dann?

Ansonsten muss ich sehen, dass ich mir mal richtig Zeit dafür nehme und das dann mal versuche zu verstehen und zu liefern...

Danke, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 27 Mai 2021, 16:00:29
Hat das was mit den "Sprachatributen" zu tun:


2021.05.27 15:08:53 2: autocreate: define MQTT2_shellyrgbw2_80E656 MQTT2_DEVICE shellyrgbw2_80E656 MQTT2Server
2021.05.27 15:08:53 2: autocreate: define FileLog_MQTT2_shellyrgbw2_80E656 FileLog ./log/MQTT2_shellyrgbw2_80E656-%Y.log MQTT2_shellyrgbw2_80E656
2021.05.27 15:10:08 3: MQTT2_DEVICE set MQTT2_shellyrgbw2_80E656 x_mqttcom announce
2021.05.27 15:10:27 1: ERROR evaluating { RADIO_SKIP_SCONTROLL }: Bareword "RADIO_SKIP_SCONTROLL" not allowed while "strict subs" in use at (eval 3595) line 1.


Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 27 Mai 2021, 16:07:33
Zitat von: MadMax-FHEM am 27 Mai 2021, 16:00:29
Hat das was mit den "Sprachatributen" zu tun:


2021.05.27 15:10:27 1: ERROR evaluating { RADIO_SKIP_SCONTROLL }: Bareword "RADIO_SKIP_SCONTROLL" not allowed while "strict subs" in use at (eval 3595) line 1.

Ja. Da fehlt ein "P" => RADIO_SKIPP_SCONTROLL (Zeile 116 in speechcontrol.template).

Fixe ich bei Gelegenheit.

Ansonsten: Lass dir Zeit, das Thema ist wegen der vielen Details leider etwas unübersichtlich; für dich im jetzigen Zusammenhang wichtig ist eigentlich erst mal zu verstehen, wie aus dem JSON-BLOBS Readings werden. Vielleicht wird der Teil etwas klarer, wenn du so einen "großen" JSON mal in einen Online-Editor packst (z.B. https://jsoneditoronline.org/).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 27 Mai 2021, 16:13:01
Naja das mit json kriege ich schon irgendwie raus/hin ;)

Aber: wo kriege ich denn den "großen json" her?

Das kommt im EventMonitor:


2021-05-27 16:05:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0/status:{"ison":false,"source":"mqtt","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","red":255,"green":0,"blue":0,"white":0,"gain":11,"temp":3000,"brightness":11,"effect":0}
2021-05-27 16:05:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/power:0.00
2021-05-27 16:05:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/energy:26
2021-05-27 16:06:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0:off
2021-05-27 16:06:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0/status:{"ison":false,"source":"mqtt","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","red":255,"green":0,"blue":0,"white":0,"gain":11,"temp":3000,"brightness":11,"effect":0}
2021-05-27 16:06:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/power:0.00
2021-05-27 16:06:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/energy:26
2021-05-27 16:06:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0:off
2021-05-27 16:06:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0/status:{"ison":false,"source":"mqtt","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","red":255,"green":0,"blue":0,"white":0,"gain":11,"temp":3000,"brightness":11,"effect":0}
2021-05-27 16:06:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/power:0.00
2021-05-27 16:06:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/energy:26
2021-05-27 16:07:10 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0:on
2021-05-27 16:07:10 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0/status:{"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","red":255,"green":0,"blue":0,"white":0,"gain":11,"temp":3000,"brightness":11,"effect":0}
2021-05-27 16:07:10 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/power:0.00
2021-05-27 16:07:10 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/energy:26
2021-05-27 16:07:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0:on
2021-05-27 16:07:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0/status:{"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","red":255,"green":0,"blue":0,"white":0,"gain":11,"temp":3000,"brightness":11,"effect":0}
2021-05-27 16:07:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/power:1.38
2021-05-27 16:07:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/energy:26
2021-05-27 16:07:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0:on
2021-05-27 16:07:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0/status:{"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","red":255,"green":0,"blue":0,"white":0,"gain":11,"temp":3000,"brightness":11,"effect":0}
2021-05-27 16:07:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/power:1.38
2021-05-27 16:07:53 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/light/0/energy:26


Und ja sieht wohl so aus:

ison:true
ison:false

;)

Ich muss jetzt mal andere Sachen machen, sorry und danke!

Ich denke heute Abend ist Zeit für so "Spielereien"...
...wenn ich weiß was ich tun kann, dann lege ich los :)

Gruß, Joachim

P.S.: gibt es eine Möglichkeit die Infoflut des Shelly per MQTT einzuschränken? Also gibt es DORT was, was ich einstellen kann, damit nicht so viel gesendet wird? Macht bei Nutzung von MQTT das Flashen von Tasmota Sinn?
Obwohl ich ja mit der Original-Shelly-SW (bislang) gut zurecht komme etc.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 27 Mai 2021, 16:38:18
Na ja, ."..color/0" nach "state" sollte doch eigentlich schon fast ausreichen, und "status" sieht mir überflüssig aus ( => {} als "Pseudo-Perl"-Auswertung für "den großen JSON").

So ganz beurteilen kann man das aber vermutlich erst, wenn man mal etwas mit Farbe rumgespielt hat.

"Geschwätzigkeit" war bei den Shelly gerne auch in der Vergangenheit ein Thema, bisher habe ich dazu leider keine abschließend verwertbare Info erhalten, was da ggf. wie Sinn macht (Tasmota ist zwischenzeitlich kaum besser...!). Es gibt aber irgendwo eine "reporting-rate", die man auf 0 stellen kann, um es etwas einzuschränken, was die firmware so sendet. (sollte im Wiki zu m2-Praxisbeispiele stehen).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 12:54:52
Zitat von: Beta-User am 27 Mai 2021, 16:38:18
Na ja, ."..color/0" nach "state" sollte doch eigentlich schon fast ausreichen, und "status" sieht mir überflüssig aus ( => {} als "Pseudo-Perl"-Auswertung für "den großen JSON").

Ok, da muss ich mal sehen.
(ob ich das verstehe ;)  )
Ich werf mal meine Duo RGBW noch mal an...


Zitat von: Beta-User am 27 Mai 2021, 16:38:18
So ganz beurteilen kann man das aber vermutlich erst, wenn man mal etwas mit Farbe rumgespielt hat.

Also Farbe einstellen etc. funktioniert.
Also egal, ob ich am MQTT2Device rumspiele oder über die Shelly-Oberfläche.
Das einzige (bislang) was nicht geht ist eben das Icon (bedingt durch state: set_ )...
Wenn ich auf "on" oder "off" klicke (webCmd) dann geht es ja.
Nur das Icon kann ich zum Schalten nicht nehmen und es zeigt eben den Status mit "Ausrufezeichen"...

Wenn das weg/anders wäre: perfekt (also für mich)

Ich versuche mal rumzuspielen, vielleicht verstehe ich ja was... ;)

Zitat von: Beta-User am 27 Mai 2021, 16:38:18
"Geschwätzigkeit" war bei den Shelly gerne auch in der Vergangenheit ein Thema, bisher habe ich dazu leider keine abschließend verwertbare Info erhalten, was da ggf. wie Sinn macht (Tasmota ist zwischenzeitlich kaum besser...!). Es gibt aber irgendwo eine "reporting-rate", die man auf 0 stellen kann, um es etwas einzuschränken, was die firmware so sendet. (sollte im Wiki zu m2-Praxisbeispiele stehen).

Ok, mal sehen.
Und wenn Tasmota da (auch) keinen Unterschied (mehr) macht, dann bleibe ich (erst mal) bei der Shelly-FW...

Bei den "simplen" Shelly (1, 1L) nehme ich wohl weiterhin das Shelly-Modul, damit ist die Geschwätzigkeit ja nicht gegeben...

...allerdings muss ich sagen, dass mir die Farbeinstellung etc. mittels MQTT schon deutlich besser gefällt! :)
(gut vielleicht ist die DUO RGB ja [auch] beim Shelly-Modul noch nicht so richtig integriert)

D.h. ich werde wohl (erst mal) nur für die Farb-Dinger auf MQTT wechseln...
...sofern ich die überhaupt nehme.

Da ist aktuell noch der Vergleich zwischen Zigbee und WLAN...
Jaja, ich weiß: WLAN ist "böse" ;)
Aber die Infrastruktur bei mir sollte das hergeben ein paar WLAN-Aktoren zu haben...
(die Shelly 1L sind schon unschlagbar klein und einfach handzuhaben)

Wenn ich noch was liefern kann: bitte sagen!

Ansonsten spiele ich mal rum und schaue wie weit ich alleine komme...

Danke, Joachim

P.S.: das mit den "alexa-Attributen" hat verm. noch niemand gemerkt, weil entweder werden die aktiviert oder, wenn nicht (wie in meinem Fall), dann sind sie zwar da aber ohne alexaName (und der wird ja korrekt nicht gesetzt) sind sie ja "funktionslos" ;)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 28 Mai 2021, 13:18:53
Doofe Frage ist  color_0 nicht der Status und müsste einfach nach state oder steht da auch mal was anderes drin ?

2021-05-27 16:06:23 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0:off
2021-05-27 16:07:10 MQTT2_SERVER MQTT2Server shellies/shellycolorbulb-8CAAB555E45D/color/0:on


shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/color/0:.* color_0

=>

shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/color/0:.* state

edit:

Upps steht ja oben schon  8)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 13:23:44
Also ich hab mal rumgespielt, auch mit json2nameValue.
Gut, wenn json kommt -> Readings bauen.

Halbwegs verstanden (naja so lala ;) ).

Aber gerade habe ich versucht herauszufinden, wie state "gebildet" wird... ;)

@TomLee: Ich werde das mal versuchen (sofern ich verstehe was zu tun ist ;)  )
EDIT: ok verstanden :) UND: es klappt! :) DANKE!

Aktuell habe ich bei /color/0: immer nur on/off gesehen :)

Danke, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 28 Mai 2021, 13:26:48
attr MQTT2_shellycolorbulb_8CAAB555E45D readingList shellies/shellycolorbulb-8CAAB555E45D/color/0:.* color_0


ändern in

attr MQTT2_shellycolorbulb_8CAAB555E45D readingList shellies/shellycolorbulb-8CAAB555E45D/color/0:.* state

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 28 Mai 2021, 13:30:43
Zitatund "status" sieht mir überflüssig aus ( => {} als "Pseudo-Perl"-Auswertung für "den großen JSON")

und das war so gemeint:

attr MQTT2_shellyrgbw2_80E656 readingList shellies/shellyrgbw2-80E656/color/0/status:.* {}

Die Readingsmusst danach löschen, von alleine verschwinden die nicht.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 13:33:46
Zitat von: TomLee am 28 Mai 2021, 13:18:53
edit:

Upps steht ja oben schon  8)

Du meinst das:

Zitat von: Beta-User am 27 Mai 2021, 16:38:18
Na ja, ."..color/0" nach "state" sollte doch eigentlich schon fast ausreichen, und "status" sieht mir überflüssig aus ( => {} als "Pseudo-Perl"-Auswertung für "den großen JSON").

Naja, wenn man weiß was das bedeuten soll, dann: ja ;)

Ich hab es erst jetzt verstanden (naja: so lala ;) ) ;)

D.h. es gibt dann irgendwann ein neues Tamplate?
Oder wird das bestehende angepasst, weil es Shelly generell in der FW ab Version X so macht?

Dann gleich eine weitere Frage (Antwort glaube ich kenne ich aber wohl schon ;)  ): wenn es ein Update gibt, dann muss ich die attrTemplate (die geändert wurden: wie erkenne ich dass es zu einem verwendeten attrTemplate eine neue Version gibt?) neu anwenden...
...oder lassen, wenn es läuft... 8)

Wie ist es mit selbst gemachten Änderungen?
Notieren und wieder nachziehen (fürchte ich)?

So, jetzt mache ich dann mal weiter mit: Datenflut einschränken (soweit möglich) und entscheiden ob nun ZigBee oder WLAN...
(wobei mir die Steuerung mit den Shelly und MQTT schon sehr gut gefällt [jetzt wo es geht :) ]  :)  )

Frage (weil ja Beta-User hier mit liest ;)  ): wie ist denn bzgl. "Steuerung" etc. der Unterschied zwischen deCONZ und HUEBridge-Modul zu zigbee2mqtt und MQTT?
(ok, ich hab noch einen RaspBee rumfliegen, mal sehen, ob der auch zigbee2mqtt-tauglich ist / dann werde ich das halt auch [noch] ausprobieren)
EDIT: oder anders: ist die "Darstellung" und "Steuerung" ähnlich wie hier? Also gibt/gäbe es einen (großen) Unterschied zu einer RGBW-Lampe die ZigBee mittels zigbee2mqtt ist gegenüber der Shelly hier?

Danke, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 13:34:33
Zitat von: TomLee am 28 Mai 2021, 13:30:43
und das war so gemeint:

attr MQTT2_shellyrgbw2_80E656 readingList shellies/shellyrgbw2-80E656/color/0/status:.* {}

Das Reading musst danach löschen, von alleine verschwindet es nicht.

Jep, nun ist es mir klar(er) :)

Danke, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 28 Mai 2021, 13:54:17
ZitatD.h. es gibt dann irgendwann ein neues Tamplate?
Oder wird das bestehende angepasst, weil es Shelly generell in der FW ab Version X so macht?

Wenn das Shelly generell so macht denk ich wird das Template angepasst.

Zitatwenn es ein Update gibt, dann muss ich die attrTemplate ...

Die aktuelle attrTemplateVersion sieht man (zumindest bei Bulbs) wenn man das entsprechende Template aus der Liste des setters attrTemplate wählt, musst ja nicht setzen nur auswählen.

ZitatWie ist es mit selbst gemachten Änderungen?
Notieren und wieder nachziehen (fürchte ich)?

Jep

Zitatist die "Darstellung" und "Steuerung" ähnlich wie hier?

Genau das gleiche nur halt andere Readings.

Beispiel Zigbee-Bulb, Farbe hab ich nicht:

defmod MQTT2_zigbee_bulb MQTT2_DEVICE zigbee_0x00158d0002fdc5d7
attr MQTT2_zigbee_bulb IODev MQTT2_Server
attr MQTT2_zigbee_bulb alexaName merkur
attr MQTT2_zigbee_bulb devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_bulb devicetopic zigbee2mqtt/0x00158d0002fdc5d7
attr MQTT2_zigbee_bulb genericDeviceType light
attr MQTT2_zigbee_bulb group Kuechenflur
attr MQTT2_zigbee_bulb homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
attr MQTT2_zigbee_bulb icon light_control
attr MQTT2_zigbee_bulb imageLink /fhem/deviceimages/mqtt2/404006-404008-404004.jpg
attr MQTT2_zigbee_bulb model zigbee2mqtt_light_dimmer
attr MQTT2_zigbee_bulb readingList $DEVICETOPIC:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_bulb room MQTT2_DEVICE
attr MQTT2_zigbee_bulb setList on:noArg $DEVICETOPIC/set {"state":"ON","transition": 200}\
  off:noArg $DEVICETOPIC/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,5,255 $DEVICETOPIC/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr MQTT2_zigbee_bulb setStateList on off
attr MQTT2_zigbee_bulb verbose 2
attr MQTT2_zigbee_bulb webCmd brightness
attr MQTT2_zigbee_bulb webCmdLabel Helligkeit\
:

setstate MQTT2_zigbee_bulb OFF
setstate MQTT2_zigbee_bulb 2021-05-23 15:56:50 IODev MQTT2_Server
setstate MQTT2_zigbee_bulb 2020-06-26 14:09:28 associatedWith MQTT2_zigbee_Bridge
setstate MQTT2_zigbee_bulb 2020-12-05 13:10:01 attrTemplateVersion 20200904
setstate MQTT2_zigbee_bulb 2021-05-28 10:11:48 brightness 254
setstate MQTT2_zigbee_bulb 2021-05-28 10:11:48 linkquality 36
setstate MQTT2_zigbee_bulb 2021-05-28 10:11:48 state OFF
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 13:58:59
Ok, danke (noch mal)!

Werde mal sehen, ob ich mit meiner vorhandenen Test-HW zigbee2mqtt zum Laufen kriege...

Mannmannmann immer diese vielen Möglichkeiten (mit fhem) ;)

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 28 Mai 2021, 14:07:53
Ist schon klar wie das Device jetzt aussieht, zeig aber trotzdem nochmal zum nachvollziehen eine Raw-Definition.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 14:23:44
Zitat von: TomLee am 28 Mai 2021, 14:07:53
Ist schon klar wie das Device jetzt aussieht, zeig aber trotzdem nochmal zum nachvollziehen eine Raw-Definition.

Klar, here it comes (aber noch mit genericDeviceType und homebridgeMaping: ungenutzt/ungewollt und gesetztem event-on-change-reading):


defmod MQTT2_shellycolorbulb_8CAAB555E45D MQTT2_DEVICE shellycolorbulb_8CAAB555E45D
attr MQTT2_shellycolorbulb_8CAAB555E45D devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";; my $light = ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"power","unknown");; "<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>"}
attr MQTT2_shellycolorbulb_8CAAB555E45D event-on-change-reading .*
attr MQTT2_shellycolorbulb_8CAAB555E45D genericDeviceType light
attr MQTT2_shellycolorbulb_8CAAB555E45D homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
attr MQTT2_shellycolorbulb_8CAAB555E45D icon light_control
attr MQTT2_shellycolorbulb_8CAAB555E45D jsonMap brightness:pct
attr MQTT2_shellycolorbulb_8CAAB555E45D model shellybulb
attr MQTT2_shellycolorbulb_8CAAB555E45D readingList shellies/shellycolorbulb-8CAAB555E45D/color/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/online:.* online\
shellycolorbulb_8CAAB555E45D:shellies/announce:.* { json2nameValue($EVENT) }\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/announce:.* { json2nameValue($EVENT) }\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/info:.* { json2nameValue($EVENT) }\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/color/0:.* state\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/light/0/power:.* light_0_power\
shellycolorbulb_8CAAB555E45D:shellies/shellycolorbulb-8CAAB555E45D/light/0/energy:.* light_0_energy
attr MQTT2_shellycolorbulb_8CAAB555E45D room MQTT2_DEVICE
attr MQTT2_shellycolorbulb_8CAAB555E45D setList off:noArg shellies/shellycolorbulb-8CAAB555E45D/color/0/command off\
  on:noArg shellies/shellycolorbulb-8CAAB555E45D/color/0/command on\
  pct:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-8CAAB555E45D/color/0/set {"gain":"$EVTPART1","brightness":"$EVTPART1"}\
  pct_on:colorpicker,BRI,0,1,100 shellies/shellycolorbulb-8CAAB555E45D/color/0/set {"turn":"on","gain":"$EVTPART1","brightness":"$EVTPART1"}\
  ct:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);;"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
  ct_on:colorpicker,CT,3000,10,6500 {$EVTPART1=3000 if ($EVTPART1<3000);;"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"temp\":\"$EVTPART1\"}"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;;if($1 ne $2 || $2 ne $3){"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;;if($1 ne $2 || $2 ne $3){"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellycolorbulb-8CAAB555E45D/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  x_update:noArg shellies/shellycolorbulb-8CAAB555E45D/command update_fw\
  x_mqttcom shellies/shellycolorbulb-8CAAB555E45D/command $EVTPART1
attr MQTT2_shellycolorbulb_8CAAB555E45D setStateList on off
attr MQTT2_shellycolorbulb_8CAAB555E45D userReadings ct:temp.* {ReadingsVal($name,"temp",3000)}, rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);;"$a$a$a"}}
attr MQTT2_shellycolorbulb_8CAAB555E45D webCmd on:off:pct:ct:rgb

setstate MQTT2_shellycolorbulb_8CAAB555E45D on
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:37:19 IODev MQTT2Server
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 actions_stats_skipped 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 attrTemplateVersion 20200522 or prior
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 blue 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 16:18:53 brightness 11
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 cfg_changed_cnt 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 cloud_connected false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 cloud_enabled false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:06:46 ct 3000
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 effect 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:24:02 energy 1
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 fs_free 159385
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 fs_size 233681
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:12:47 fw_ver 20210429-095910/v1.10.4-g3f94cd7
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 gain 1
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 green 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 has_timer false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 has_update false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:12:47 id shellycolorbulb-8CAAB555E45D
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:12:47 ip 192.168.10.167
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 ison true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 light_0_energy 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 light_0_power 1.08
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_blue 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_brightness 11
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_effect 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_gain 11
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_green 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_has_timer false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_ison true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_mode white
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_red 255
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_source http
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_temp 3000
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_timer_duration 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_timer_remaining 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_timer_started 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 lights_1_white 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:12:47 mac 8CAAB555E45D
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_counters_1 1.378
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_counters_2 1.378
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_counters_3 1.378
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_is_valid true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_power 1.38
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_timestamp 1622126303
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 meters_1_total 24
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 mode white
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:12:47 model SHCB-1
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 mqtt_connected true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:12:47 new_fw false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:14:53 online false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 pct 1
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 ping_check true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:24:02 power 0.00
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 ram_free 37776
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 ram_total 50200
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 red 255
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 13:41:35 rgb 1C1C1C
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 serial 42
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 source mqtt
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 state on
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 temp 3000
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 time 14:38
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 timer_duration 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 timer_remaining 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 timer_started 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 unixtime 1622119103
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 update_has_update false
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 update_new_version
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 update_old_version 20210429-095910/v1.10.4-g3f94cd7
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 update_status unknown
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 uptime 1020
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-28 14:13:17 white 0
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 wifi_sta_connected true
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 wifi_sta_ip 192.168.10.167
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 wifi_sta_rssi -67
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 wifi_sta_ssid My-Network
setstate MQTT2_shellycolorbulb_8CAAB555E45D 2021-05-27 14:38:22 x_mqttcom set announce


Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 28 Mai 2021, 14:41:00
Das noch ein "unsauberes" Device du hast die Readings aus dem Json noch nicht gelöscht.

Am einfachsten ist es alle Readings zu löschen und dann einen Neustart des Shelly zu machen, danach sind alle nötigen Readings wieder da.

edit:

Achso den rL-Eintrag zu status hast auch gar nicht wie oben erwähnt ergänzt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 14:57:23
?

Es gab doch nur ein "unsauberes" Reading: color_0?
Das habe ich gelöscht...

Und dann statt color_0 eben state?

Jetzt verstehe ich nicht was du meinst...

Also es hat so funktioniert wie ich wollte.
Gut das mit alle Readings löschen und neu "anlernen" kann ich machen.
Später, muss das Ding erst wieder rauskramen...

Ich stecke ja eigentlich in der Entscheidung: WLAN (Shelly) und da dann Shelly-Device oder MQTT2Device (aktuell also eher: MQTT2DEVICE :) ) oder ZigBee und da dann deCONZ und HUEBridge-Modul (hab ich schon) oder eben zigbee2mqtt und MQTTBridge/MQTT2DEVICE...

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 28 Mai 2021, 15:14:03
Zitat von: TomLee am 28 Mai 2021, 13:30:43
und das war so gemeint:

attr MQTT2_shellyrgbw2_80E656 readingList shellies/shellyrgbw2-80E656/color/0/status:.* {}

Die Readingsmusst danach löschen, von alleine verschwinden die nicht.

ZitatJetzt verstehe ich nicht was du meinst...

Ich habs so verstanden das die Readings die hier in dem status-Zweig :

attr MQTT2_shellycolorbulb_8CAAB555E45D readingList shellies/shellycolorbulb-8CAAB555E45D/color/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}

mit json2nameValue aus dem JSON erstellt werden unnötig sind oder nicht ?
Beta-User würd jetzt sagen die werden mit {} einfach ins Nirvana befördert.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 15:53:30
Zitat von: TomLee am 28 Mai 2021, 15:14:03
Ich habs so verstanden das die Readings die hier in dem status-Zweig :

attr MQTT2_shellycolorbulb_8CAAB555E45D readingList shellies/shellycolorbulb-8CAAB555E45D/color/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}

mit json2nameValue aus dem JSON erstellt werden unnötig sind oder nicht ?
Beta-User würd jetzt sagen die werden mit {} einfach ins Nirvana befördert.

Naja, ich habe alles aus dem Template genommen (das status-Zeugs stammt da her / ob das "notwendig"/"sinnvoll" ist: keine Ahnung ;)  ), dann eben das mit state gemacht, also color_0 -> state und gut.
Das color_0 Reading habe ich gelöscht.

Mehr nicht...
...und für mich funktioniert es wie es soll, bzw. ich es will/wollte :)

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 28 Mai 2021, 16:07:38
ZitatMehr nicht...
...und für mich funktioniert es wie es soll, bzw. ich es will/wollte :)

Wird ja auch weiterhin funktionieren ohne Einschränkungen, das Device wird nur sauberer/übersichtlicher.

Ich kann dich ja nicht zwingen, aber probiers halt mal aus, schätze dann fällt der Groschen.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 28 Mai 2021, 16:12:51
Was das macht weiß ich schon (mittlerweile) ;)

ABER: es kam ja aus dem (alten) attrTemplate ;)

Wenn es im neuen nicht sein soll/nicht mehr drin ist: ok :)
Übersichtlicher: mich stört es nicht. Ich schaue da eh nie/kaum rein (also wegen mir kann "alles" weg was nicht für die Funktion nutze ist / aber: es stört mich auch nicht, wenn es da ist)...
Übertragen wird es ja selbst, wenn ich es da raus nehme...
...gut das ganze json2nameValue müsste nicht "bearbeitet" werden aber naja...

Wenn ich es hier ohne den Eintrag noch mal posten soll: gerne (dauert aber etwas weil ich das Ding schon wieder in die Kiste habe / aktuell grad dabei zigbee2mqtt auszuprobieren)

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 03 Juli 2021, 08:17:28
Hallo zusammen,
Wird eigentlich die Shelly Duo RGBW E27 als smartes leuchtmittel auch unterstützt? Ich überlege mir diese zuzulegen.
Gruß
Jan
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Juli 2021, 09:21:31
Zitat von: stratege-0815 am 03 Juli 2021, 08:17:28
Wird eigentlich die Shelly Duo RGBW E27 als smartes leuchtmittel auch unterstützt?
Falls noch nicht, ist es sicher kein allzu großes Problem....
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: stratege-0815 am 03 Juli 2021, 09:57:43
Zitat von: Beta-User am 03 Juli 2021, 09:21:31
Falls noch nicht, ist es sicher kein allzu großes Problem....

Für mich schon  :D :D :D
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Juli 2021, 07:42:46
Zitat von: stratege-0815 am 03 Juli 2021, 09:57:43
Für mich schon  :D :D :D
Das kann und mag ich nicht beurteilen, aber ansonsten war es so gemeint: Das bekommen wir schon hin, _falls_ überhaupt Bedarf besteht. Würde vermuten, dass "shellyrgbw2_color" paßt, und falls nicht, wäre hier oder https://forum.fhem.de/index.php/topic,94494.0.html (auch wegen dem, was man liefern sollte) die richtige Stelle, um nach Hilfe zu fragen ;) .

Die attrTemplate-Benennung folgt eher "Fähigkeiten" (innerhalb von  Gerätefamilien), spezielle Modelle sind eher nicht so wichtig - in der Regel ist es so, dass z.B. Shelly-Geräte, die RGBW steuern können, auf der MQTT-Seite gleich aussehen, egal, ob es jetzt eine Bulb ist oder ein Controller für LED-Stips. Wenn es Unterschiede gibt, sind die in der Regel minimal... (dto. innerhalb der Tasmota-"Familie" - deswegen ist es auch nach dem Umflashen egal, welcher chinesischer Hersteller konkret das Teil geliefert hat, oder ob es sich um einen Eigenbau handelt, oder ....)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Romoker am 01 August 2021, 14:00:44
Zu meinem Problem konnte ich keine Informationen finden. Ich hoffe, ich bin hier richtig unterwegs.
Mir ist jetzt aufgefallen, dass alle info-Readings meiner Shellies (Shelly Plug S und Shelly 2.5) seit mehreren Monaten nicht mehr aktualisiert wurden. Auch ein Reboot der Devices aktualisiert die info-Readings nicht. Nur mit dem manuellen FHEM-Publish-Kommando "set <device name> x_mqttcom announce" erfolgt die Aktualisierung in FHEM. Ich bin mir nicht mehr sicher, aber ich meine, dass die info-Readings in der Vergangenheit auch automatisch aktualisiert wurden.

Ich führe hin und wieder Firmware-Updates aus. Könnte der Grund eine neuere Shelly-Firmware sein, die info-Topics nicht mehr periodisch sendet?
Hat jemand auch diese Beobachtung gemacht oder eine andere Erklärung dafür?

Hier ein List von einem Shelly Plug S mit veralteten info-Readings, das mit dem Template shellyplug angelegt wurde:
IInternals:
   CID        shellyplug_s_E18BA4
   DEF        shellyplug_s_E18BA4
   DEVICETOPIC SmartPlug12
   FUUID      5ff76c48-f33f-df6c-80d2-f21470cb7bbb3f6d
   IODev      myMQTT2
   LASTInputDev myMQTT2
   MSGCNT     269037
   NAME       SmartPlug12
   NR         524
   STATE      on
   TYPE       MQTT2_DEVICE
   myMQTT2_MSGCNT 269037
   myMQTT2_TIME 2021-08-01 13:58:35
   READINGS:
     2021-07-18 11:36:17   IODev           myMQTT2
     2021-01-07 21:23:34   attrTemplateVersion 20200522 or prior
     2021-08-01 10:22:03   fw_ver          20210727-201754/v1.11.2-g25b6953
     2021-08-01 10:22:03   id              shellyplug-s-E18BA4
     2021-01-07 21:23:34   info_actions_stats_skipped 0
     2021-01-07 21:23:34   info_cfg_changed_cnt 6
     2021-01-07 21:23:34   info_cloud_connected false
     2021-01-07 21:23:34   info_cloud_enabled false
     2021-01-07 21:23:34   info_fs_free    161644
     2021-01-07 21:23:34   info_fs_size    233681
     2021-01-07 21:23:34   info_has_update false
     2021-01-07 21:23:34   info_mac        8CCE4EE18BA4
     2021-01-07 21:23:34   info_meters_1_counters_1 0.000
     2021-01-07 21:23:34   info_meters_1_counters_2 0.000
     2021-01-07 21:23:34   info_meters_1_counters_3 0.000
     2021-01-07 21:23:34   info_meters_1_is_valid true
     2021-01-07 21:23:34   info_meters_1_overpower 0.00
     2021-01-07 21:23:34   info_meters_1_power 0.00
     2021-01-07 21:23:34   info_meters_1_timestamp 1610054614
     2021-01-07 21:23:34   info_meters_1_total 0
     2021-01-07 21:23:34   info_mqtt_connected true
     2021-01-07 21:23:34   info_overtemperature false
     2021-01-07 21:23:34   info_ram_free   38748
     2021-01-07 21:23:34   info_ram_total  51032
     2021-01-07 21:23:34   info_relays_1_has_timer false
     2021-01-07 21:23:34   info_relays_1_ison false
     2021-01-07 21:23:34   info_relays_1_overpower false
     2021-01-07 21:23:34   info_relays_1_source http
     2021-01-07 21:23:34   info_relays_1_timer_duration 0
     2021-01-07 21:23:34   info_relays_1_timer_remaining 0
     2021-01-07 21:23:34   info_relays_1_timer_started 0
     2021-01-07 21:23:34   info_serial     21
     2021-01-07 21:23:34   info_temperature 30.82
     2021-01-07 21:23:34   info_time       21:23
     2021-01-07 21:23:34   info_tmp_is_valid true
     2021-01-07 21:23:34   info_tmp_tC     30.82
     2021-01-07 21:23:34   info_tmp_tF     87.48
     2021-01-07 21:23:34   info_unixtime   1610051014
     2021-01-07 21:23:34   info_update_has_update false
     2021-01-07 21:23:34   info_update_new_version 20201228-092848/v1.9.3@ad2bb4e3
     2021-01-07 21:23:34   info_update_old_version 20201228-092848/v1.9.3@ad2bb4e3
     2021-01-07 21:23:34   info_update_status idle
     2021-01-07 21:23:34   info_uptime     714
     2021-01-07 21:23:34   info_wifi_sta_connected true
     2021-01-07 21:23:34   info_wifi_sta_ip 192.168.66.72
     2021-01-07 21:23:34   info_wifi_sta_rssi -63
     2021-01-07 21:23:34   info_wifi_sta_ssid nightingale_nomap
     2021-08-01 10:22:03   ip              192.168.66.72
     2021-08-01 10:22:03   mac             8CCE4EE18BA4
     2021-08-01 10:22:03   model           SHPLG-S
     2021-08-01 10:22:03   new_fw          false
     2021-08-01 10:22:03   online          true
     2021-08-01 13:58:35   overtemperature 0
     2021-08-01 13:58:35   relay0          on
     2021-08-01 13:58:35   relay_0_energy  4932
     2021-08-01 13:58:35   relay_0_power   0.00
     2021-08-01 13:58:35   statU_energy_total Hour: 0.0252000000000 Day: 0.3362999999960 Month: 0.3362999999960 Year: 142.4811000000450 (since: 2021-02-07 )
     2021-08-01 13:58:35   statU_energy_totalDay 0.3362999999960
     2021-07-31 23:59:56   statU_energy_totalDayLast 0.5814999999910
     2021-08-01 13:58:35   statU_energy_totalHour 0.0252000000000
     2021-08-01 12:59:55   statU_energy_totalHourLast 0.0185999999990
     2021-08-01 12:59:55   statU_energy_totalLast Hour: 0.0185999999990 Day: 0.5814999999910 Month: 20.0345999998370 Year: -
     2021-08-01 13:58:35   statU_energy_totalMonth 0.3362999999960
     2021-07-31 23:59:56   statU_energy_totalMonthLast 20.0345999998370
     2021-08-01 13:58:35   statU_energy_totalYear 142.4811000000450
     2021-08-01 13:58:35   state           on
     2021-08-01 13:58:35   temperature     34.69
     2021-08-01 13:58:35   temperature_f   94.44
     2021-08-01 13:44:05   u_energy_total  144.300800000045
   helper:
     _98_statistics st_smartPlugs
Attributes:
   IODev      myMQTT2
   alias      Gefrierschrank
   comment    relay_0_energy in Joule = Watt Minuten (Rechnung 1/60)
   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'? 'ios-off':'ios-on-green';my $cons=sprintf("%.1f",ReadingsVal($name,'relay_0_power',0));my $total=sprintf("%.2f",ReadingsVal($name,'u_energy_total',0));my $temp=sprintf("%.1f",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>$cons W / $total kWh / $temp °C</div>"}
   event-on-change-reading relay_0_power:0.2,.*
   genericDeviceType switch
   getList    power:noArg shellies/shellyplug-s-E18BA4/relay/power power
   group      PowerMeter
   icon       black_Steckdose.on
   model      shellyplug
   readingList shellies/shellyplug-s-E18BA4/relay/0:.* state
shellies/shellyplug-s-E18BA4/relay/0:.* relay0
shellies/shellyplug-s-E18BA4/input/0:.* input0
shellies/shellyplug-s-E18BA4/online:.* online
shellies/shellyplug-s-E18BA4/announce:.* { json2nameValue($EVENT) }
shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-E18BA4...mac.*, ? json2nameValue($EVENT) : return }
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/info:.* { json2nameValue($EVENT, 'info_', $JSONMAP) }
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/relay/0/power:.* relay_0_power
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/relay/0/energy:.* relay_0_energy
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/temperature:.* temperature
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/overtemperature:.* overtemperature
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/temperature_f:.* temperature_f
   room       Administration->MQTT2
   setList    off:noArg shellies/shellyplug-s-E18BA4/relay/0/command off
on:noArg shellies/shellyplug-s-E18BA4/relay/0/command on
x_update:noArg shellies/shellyplug-s-E18BA4/command update_fw
x_mqttcom shellies/shellyplug-s-E18BA4/command $EVTPART1
   userReadings u_energy_total:relay_0_energy:.* monotonic {sprintf("%.4f",ReadingsNum($name,'relay_0_energy',0)/60000)}


Viele Grüße
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: frober am 01 August 2021, 16:22:22
Zitat von: Romoker am 01 August 2021, 14:00:44
Zu meinem Problem konnte ich keine Informationen finden. Ich hoffe, ich bin hier richtig unterwegs.
Mir ist jetzt aufgefallen, dass alle info-Readings meiner Shellies (Shelly Plug S und Shelly 2.5) seit mehreren Monaten nicht mehr aktualisiert wurden. Auch ein Reboot der Devices aktualisiert die info-Readings nicht. Nur mit dem manuellen FHEM-Publish-Kommando "set <device name> x_mqttcom announce" erfolgt die Aktualisierung in FHEM. Ich bin mir nicht mehr sicher, aber ich meine, dass die info-Readings in der Vergangenheit auch automatisch aktualisiert wurden.

Ich führe hin und wieder Firmware-Updates aus. Könnte der Grund eine neuere Shelly-Firmware sein, die info-Topics nicht mehr periodisch sendet?
Hat jemand auch diese Beobachtung gemacht oder eine andere Erklärung dafür?

Hier ein List von einem Shelly Plug S mit veralteten info-Readings, das mit dem Template shellyplug angelegt wurde:
IInternals:
   CID        shellyplug_s_E18BA4
   DEF        shellyplug_s_E18BA4
   DEVICETOPIC SmartPlug12
   FUUID      5ff76c48-f33f-df6c-80d2-f21470cb7bbb3f6d
   IODev      myMQTT2
   LASTInputDev myMQTT2
   MSGCNT     269037
   NAME       SmartPlug12
   NR         524
   STATE      on
   TYPE       MQTT2_DEVICE
   myMQTT2_MSGCNT 269037
   myMQTT2_TIME 2021-08-01 13:58:35
   READINGS:
     2021-07-18 11:36:17   IODev           myMQTT2
     2021-01-07 21:23:34   attrTemplateVersion 20200522 or prior
     2021-08-01 10:22:03   fw_ver          20210727-201754/v1.11.2-g25b6953
     2021-08-01 10:22:03   id              shellyplug-s-E18BA4
     2021-01-07 21:23:34   info_actions_stats_skipped 0
     2021-01-07 21:23:34   info_cfg_changed_cnt 6
     2021-01-07 21:23:34   info_cloud_connected false
     2021-01-07 21:23:34   info_cloud_enabled false
     2021-01-07 21:23:34   info_fs_free    161644
     2021-01-07 21:23:34   info_fs_size    233681
     2021-01-07 21:23:34   info_has_update false
     2021-01-07 21:23:34   info_mac        8CCE4EE18BA4
     2021-01-07 21:23:34   info_meters_1_counters_1 0.000
     2021-01-07 21:23:34   info_meters_1_counters_2 0.000
     2021-01-07 21:23:34   info_meters_1_counters_3 0.000
     2021-01-07 21:23:34   info_meters_1_is_valid true
     2021-01-07 21:23:34   info_meters_1_overpower 0.00
     2021-01-07 21:23:34   info_meters_1_power 0.00
     2021-01-07 21:23:34   info_meters_1_timestamp 1610054614
     2021-01-07 21:23:34   info_meters_1_total 0
     2021-01-07 21:23:34   info_mqtt_connected true
     2021-01-07 21:23:34   info_overtemperature false
     2021-01-07 21:23:34   info_ram_free   38748
     2021-01-07 21:23:34   info_ram_total  51032
     2021-01-07 21:23:34   info_relays_1_has_timer false
     2021-01-07 21:23:34   info_relays_1_ison false
     2021-01-07 21:23:34   info_relays_1_overpower false
     2021-01-07 21:23:34   info_relays_1_source http
     2021-01-07 21:23:34   info_relays_1_timer_duration 0
     2021-01-07 21:23:34   info_relays_1_timer_remaining 0
     2021-01-07 21:23:34   info_relays_1_timer_started 0
     2021-01-07 21:23:34   info_serial     21
     2021-01-07 21:23:34   info_temperature 30.82
     2021-01-07 21:23:34   info_time       21:23
     2021-01-07 21:23:34   info_tmp_is_valid true
     2021-01-07 21:23:34   info_tmp_tC     30.82
     2021-01-07 21:23:34   info_tmp_tF     87.48
     2021-01-07 21:23:34   info_unixtime   1610051014
     2021-01-07 21:23:34   info_update_has_update false
     2021-01-07 21:23:34   info_update_new_version 20201228-092848/v1.9.3@ad2bb4e3
     2021-01-07 21:23:34   info_update_old_version 20201228-092848/v1.9.3@ad2bb4e3
     2021-01-07 21:23:34   info_update_status idle
     2021-01-07 21:23:34   info_uptime     714
     2021-01-07 21:23:34   info_wifi_sta_connected true
     2021-01-07 21:23:34   info_wifi_sta_ip 192.168.66.72
     2021-01-07 21:23:34   info_wifi_sta_rssi -63
     2021-01-07 21:23:34   info_wifi_sta_ssid nightingale_nomap
     2021-08-01 10:22:03   ip              192.168.66.72
     2021-08-01 10:22:03   mac             8CCE4EE18BA4
     2021-08-01 10:22:03   model           SHPLG-S
     2021-08-01 10:22:03   new_fw          false
     2021-08-01 10:22:03   online          true
     2021-08-01 13:58:35   overtemperature 0
     2021-08-01 13:58:35   relay0          on
     2021-08-01 13:58:35   relay_0_energy  4932
     2021-08-01 13:58:35   relay_0_power   0.00
     2021-08-01 13:58:35   statU_energy_total Hour: 0.0252000000000 Day: 0.3362999999960 Month: 0.3362999999960 Year: 142.4811000000450 (since: 2021-02-07 )
     2021-08-01 13:58:35   statU_energy_totalDay 0.3362999999960
     2021-07-31 23:59:56   statU_energy_totalDayLast 0.5814999999910
     2021-08-01 13:58:35   statU_energy_totalHour 0.0252000000000
     2021-08-01 12:59:55   statU_energy_totalHourLast 0.0185999999990
     2021-08-01 12:59:55   statU_energy_totalLast Hour: 0.0185999999990 Day: 0.5814999999910 Month: 20.0345999998370 Year: -
     2021-08-01 13:58:35   statU_energy_totalMonth 0.3362999999960
     2021-07-31 23:59:56   statU_energy_totalMonthLast 20.0345999998370
     2021-08-01 13:58:35   statU_energy_totalYear 142.4811000000450
     2021-08-01 13:58:35   state           on
     2021-08-01 13:58:35   temperature     34.69
     2021-08-01 13:58:35   temperature_f   94.44
     2021-08-01 13:44:05   u_energy_total  144.300800000045
   helper:
     _98_statistics st_smartPlugs
Attributes:
   IODev      myMQTT2
   alias      Gefrierschrank
   comment    relay_0_energy in Joule = Watt Minuten (Rechnung 1/60)
   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'? 'ios-off':'ios-on-green';my $cons=sprintf("%.1f",ReadingsVal($name,'relay_0_power',0));my $total=sprintf("%.2f",ReadingsVal($name,'u_energy_total',0));my $temp=sprintf("%.1f",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>$cons W / $total kWh / $temp °C</div>"}
   event-on-change-reading relay_0_power:0.2,.*
   genericDeviceType switch
   getList    power:noArg shellies/shellyplug-s-E18BA4/relay/power power
   group      PowerMeter
   icon       black_Steckdose.on
   model      shellyplug
   readingList shellies/shellyplug-s-E18BA4/relay/0:.* state
shellies/shellyplug-s-E18BA4/relay/0:.* relay0
shellies/shellyplug-s-E18BA4/input/0:.* input0
shellies/shellyplug-s-E18BA4/online:.* online
shellies/shellyplug-s-E18BA4/announce:.* { json2nameValue($EVENT) }
shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-E18BA4...mac.*, ? json2nameValue($EVENT) : return }
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/info:.* { json2nameValue($EVENT, 'info_', $JSONMAP) }
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/relay/0/power:.* relay_0_power
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/relay/0/energy:.* relay_0_energy
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/temperature:.* temperature
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/overtemperature:.* overtemperature
shellyplug_s_E18BA4:shellies/shellyplug-s-E18BA4/temperature_f:.* temperature_f
   room       Administration->MQTT2
   setList    off:noArg shellies/shellyplug-s-E18BA4/relay/0/command off
on:noArg shellies/shellyplug-s-E18BA4/relay/0/command on
x_update:noArg shellies/shellyplug-s-E18BA4/command update_fw
x_mqttcom shellies/shellyplug-s-E18BA4/command $EVTPART1
   userReadings u_energy_total:relay_0_energy:.* monotonic {sprintf("%.4f",ReadingsNum($name,'relay_0_energy',0)/60000)}


Viele Grüße

Ich vermute, dass der Mqtt2server die Daten nicht weiterreicht. Evtl. kennt er durch irgend eine Änderung die Clients nicht mehr. Hast du Fhem upgedatet? Vielleicht reicht es schon das Templates neu einzurichten. Evtl. musst du auch das Device löschen, damit es über autocreate neu angelegt wird...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Romoker am 01 August 2021, 17:05:07
ZitatIch vermute, dass der Mqtt2server die Daten nicht weiterreicht. Evtl. kennt er durch irgend eine Änderung die Clients nicht mehr. Hast du Fhem upgedatet? Vielleicht reicht es schon das Templates neu einzurichten. Evtl. musst du auch das Device löschen, damit es über autocreate neu angelegt wird...

Danke für den Hinweis, aber das kann ich mir nicht vorstellen, denn mit "set <device name> x_mqttcom announce" erfolgt ja die Aktualisierung der info-Attribute in FHEM, also reicht der Mqtt2server die Daten schon weiter und die readingList-Umsetzung ist dann auch korrekt. Das Template neu einzurichten hatte ich schon ohne Erfolg probiert. Meine FHEM-Version ist aktuell.

Mich würde interessieren, ob die info-Readings bei anderen MQTT2-Shelly-Nutzern aktualisiert werden und welcher Shelly-Firmware-Stand dahinter steht.

Viele Grüße
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: frober am 01 August 2021, 17:52:50
Bei mir, einige Shelly 2.5, die funktionieren einwandfrei.
Ich bin nicht so tief in der Materie, behaupte aber mal, dass es ein Unterschied ist, ob du Daten anforderst oder die Daten von Shelly gesendet und zugeordnet werden müssen.

Aber ich sehe gerade, lösche zum Test mal das event-on-change-reading.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Romoker am 01 August 2021, 20:01:18
@frober

Die Variante, das event-on-change-reading zu löschen, hatte ich auch schon ausprobiert. Ohne Erfolg.
Um ganz sicher zu gehen, habe ich ein Shelly Plug S-Device gelöscht und durch autocreate (autocreate complex) neu anlegen lassen. Ohne Erfolg.
Ich habe jetzt im MQTT Explorer die Topics nach eine Reboot eines Shelly Plug S aufgezeichnet. Es wird nach einem Reboot kein info-Topic gesendet!

Ich stelle jetzt mal die These auf, dass mit einer Shelly-Firmwareaktualisierung Anfang diesen Jahres (so um  v1.9.3) keine info-Topics mehr selbständig vom Device gesendet werden. Das Topic kann nur manuell über ein publish command angefordert werden.
Ich bin gespannt, ob jemand meine These widerlegen oder bestätigen kann.

Welche Firmware-Version hat denn Dein Shelly 2.5 und sind Deine info-Topics wirklich alle aktuell??

Viele Grüße
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: frober am 01 August 2021, 22:27:48
Meine FW ist aktuell 20210323-104714/v1.10.1-gf276b51

Die Info-Topics wie WiFi etc. werde bei mir auch nicht aktualisiert. Soweit ich mich erinnere, wurden die einmalig angelegt mit dem Template oder Neustart des Shelly und dann nicht mehr aktualisiert.
Da habe ich mich nie darum gekümmert.

Ich dachte, du meinst alle Topics...sorry habe ich falsch interpretiert.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Romoker am 02 August 2021, 10:06:39
@frober

Dann scheint sich ja meine These zu bestätigen.
Übrigens: die zurzeit aktuelle Shelly-Firmware ist v1.11.2.

Viele Grüße
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 August 2021, 10:16:55
Ähm, was diskutiert ihr hier eigentlich grade?

Das (intern überall aufgerufene) "basis"-shelly-attrTemplate ruft schon sehr lange die "announce"-Funktion auf, um _einmalig_ Daten abzurufen, das sieht man doch eigentlich relativ gut, wenn man sich eines der Shelly-attrTemplate anzeigen läßt.

Um die Aktualisierung des Zeitstempels zu verhindern, müßte auch timestamp-on-change-reading gesetzt sein. Das würde zwar zum Teil Sinn machen, aber bisher hat keiner die Anregung in diese Richtung aufgegriffen, dazu einen vollständigen Vorschlag zu machen.

[OT]
Eigentlich sollte man doch froh sein, wenn nicht ständig "alles mögliche" (ungefragt) gesendet wird! Also bitte insbesondere nicht den Hersteller anfragen, ob er automatische updates implementieren könnte... Eher sollten weitere Konfigurationsoptionen in der firmware angeboten werden, um updates zu begrenzen...!
[/OT]
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 12 November 2021, 22:51:08
Hallo

Ich habe eine Frage/Problem. Und zwar habe ich einen Shelly RGBW2 per MQTT und dem template color eingebunden. Erstmal  läuft alles super. Allerdings ist mir aufgefallen, dass es eigentlich kein rgbw sondern eher ein rgb und ein w ist. Wenn ich zb im Colorpicker Weiß anwähle, mischt er Weiß aus rgb und nimmt nicht Weiß. Wenn ich über die Home App Weiß anwähle das gleiche, über Siri Weiß gewählt kommt Rot. Kann man das Template so anpassen, dass bei Weiß auch Weiß kommt in der Helligkeit die zur Zeit herrscht? Oder kann der Shelly das einfach nicht? Bis dato hatte ich Milight da ging das also scheint es ja nicht an der Home App zu liegen. Die haben nur immer Probleme gemacht deswegen der Umstieg auf den Shelly. Wieso ist der Weiß Kanal eigentlich getrennt? Das macht doch eigentlich wenig sinn. Ich habe mal ein list angehangen. Leider verstehe ich das setlist nicht da reichen meine Kenntnisse nicht für. Würde gerne so manches anpassen aber das ist zu hoch für mich. 

Ich würde mich sehr freuen, wenn mir da jemand helfen könnte.

Mit freundlichen Grüßen
Christian




Internals:
   CFGFN     
   CID        shellyrgbw2_F9920A
   DEF        shellyrgbw2_F9920A
   DEVICETOPIC Licht_Kueche
   FUUID      618ba2e1-f33f-b214-5f16-95f1ae1a357ce627
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 2200
   MQTT2_TIME 2021-11-12 22:20:04
   MSGCNT     2200
   NAME       Licht_Kueche
   NR         1943460
   STATE      on
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2021-11-10 11:47:43   attrTemplateVersion 20200831
     2021-11-12 22:20:04   blue            240
     2021-11-12 22:20:04   effect          0
     2021-11-12 20:08:01   fw_ver          20190822-083406/master@4148d2b7
     2021-11-12 22:20:04   gain            100
     2021-11-12 22:20:04   green           255
     2021-11-12 20:08:01   id              shellyrgbw2-F9920A
     2021-11-12 20:08:01   ip              192.168.0.56
     2021-11-12 22:20:04   ison            true
     2021-11-12 20:08:01   mac             F4CFA2F9920A
     2021-11-12 22:20:04   mode            color
     2021-11-12 20:08:01   new_fw          false
     2021-11-12 20:08:01   online          true
     2021-11-12 22:20:04   overpower       false
     2021-11-12 22:20:04   power           13.56
     2021-11-12 22:20:04   red             243
     2021-11-12 22:20:04   rgb             F3FFF0
     2021-11-12 21:58:43   state           on
     2021-11-12 22:20:04   white           0
     2021-11-10 11:47:43   x_mqttcom       set announce
Attributes:
   IODev      MQTT2
   devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot"; my $light = ReadingsVal($name,"state","off"); my $cons = ReadingsVal($name,"power","unknown"); "<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>"}
   group      Licht
   icon       light_control
   model      shelly2rgbw_color
   readingList shellies/shellyrgbw2-F9920A/color/0/status:.* {json2nameValue($EVENT)}
  shellies/shellyrgbw2-F9920A/color/0:.* state
  shellies/shellyrgbw2-F9920A/online:.* online
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-F9920A...mac.*, ? json2nameValue($EVENT) : return }
   room       Erdgeschoss,Homekit
   setList    off:noArg shellies/shellyrgbw2-F9920A/color/0/command off
  on:noArg shellies/shellyrgbw2-F9920A/color/0/command on
  white:colorpicker,BRI,0,1,255 shellies/shellyrgbw2-F9920A/color/0/set {"white":"$EVTPART1"}
  gain:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-F9920A/color/0/set {"gain":"$EVTPART1"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-F9920A/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-F9920A/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  white_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-F9920A/color/0/set {"turn":"on","white":"$EVTPART1"}
  gain_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-F9920A/color/0/set {"turn":"on","gain":"$EVTPART1"}
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-F9920A/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-F9920A/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  effect:selectnumbers,0,1,6,0,lin  shellies/shellyrgbw2-F9920A/color/0/set {"effect":"$EVTPART1"}
  x_update:noArg shellies/shellyrgbw2-F9920A/command update_fw
  x_mqttcom shellies/shellyrgbw2-F9920A/command $EVTPART1
   setStateList on off
   userReadings rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
   webCmd     on:off:white:gain:rgb
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 12 November 2021, 23:41:00
Der Shelly kann nur entweder oder.
Siehst du, wenn du direkt mit der Shelly Oberfläche bedienst.

Da ändert der Shelly die interne Konfig (oder lädt sogar eine andere FW) und braucht dazu sogar Internetzugriff...
Bzw. hat die Umschaltung bei mir nicht geklappt, als ich dem Shelly das Internet "gekappt" hatte...

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 13 November 2021, 07:36:48
Hi

Also umschalten kann ich ohne internet. Allerdings kann man doch bestimmt was schreiben, dass wenn ich in HomeKit  weiß anwähle er mir die Farben auf 0 stellt und weiß auf 100 zum Beispiel. Oder wäre sowas nicht machbar?

Viele Grüße
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 13 November 2021, 07:48:40
Direkt in der Shelly Oberfläche?
Und tatsächlich zw. RGB und W?

Hmm, muss ich mal noch mal testen...
(evtl. geht das ja mit neuerer FW)

Ob das beim Schalten durch Homekit geht keine Ahnung.
Irgendwo hier im Forum gibt's was wo parrallel zu mqtt auch http-Requests an Shellys geschickt werden, für "echtes" on-for-timer (also im Shelly laufend)...

Das kann man verm. auch hierfür nehmen...

Gruß, Joachim
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 13 November 2021, 14:09:58
Eventuell würde auch das (neulich etwas überarbeitete) shellybulb-Template helfen. Das behandelt Weißtöne in rgb etwas "speziell"...

Ansonsten sind rgbw-Geräte gerne mal "zickig" - ich kenne das von den MiLights und hatte das neulich auch bei einer ZigBee-(nicht-tint-Aldi-) Birne, dass "weiß" in RGB - freundlich gesagt - "nicht gut" aussah.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 14 November 2021, 13:37:06
Hallo

ich denke ich muss mich von dem Weiß in den Streifen oder von den Shellys verabschieden. Echt traurig das die als RGBW beworben werden.

Eine andere Frage habe ich noch. Ich schalte den Trafo mit einem Shelly 2.5, weil ich nicht die ganze Zeit den Trafo laufen haben möchte. Kann man das SetList so anpassen, dass wenn ich an dem RGBW auf off drücke er den Rgbw und den 2.5 aus schaltet? Wenn ich das umschreibe auf den Shelly 2.5, dann geht es allerdings bekomme ich es nicht hin das er beide schaltet.

off:noArg (shellies/shellyrgbw2-F9920A/color/0/) and (shellies/shellyswitch25-C45BBE620428/relay/0/)command off

das habe ich versucht geht allerdings nicht.

Grüße

Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 November 2021, 13:44:35
Geht ziemlich sicher, aber du musst "reines Perl" in der setList-Zeile verwenden. Falls der LED-Shelly keinen Strom hat, brauchst du dazu noch eine Verzögerung... Nicht ganz trivial, aber möglich. Ggf. nach den ersten Versuchen separaten Thread starten, wenn es nicht klappt...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 14 November 2021, 14:27:59
Hallo

meinst du mit reinem Perl das hier? off:noArg {fhem "set Licht_WZ off; set Licht_Kueche off;";}

Das geht leider auch nicht.

Im Shelly habe ich (ON - Configure Shelly device to Turn ON, when it has power.)  eingestellt also sobalt der Strom bekommt geht das licht an.

Grüße
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 November 2021, 14:38:03
Nein. "Topic Payload" muss zurückgegeben werden.... Dazwischen kann "alles mögliche" passieren, z.B. auch ein weiteres publish usw.. Wie gesagt: nicht ganz trivial.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 14 November 2021, 15:15:02
Danke für die schnelle Antwort allerdings sagt mir das nur Bahnhof  :o

Hast du da evtl eine Quelle wo das beschrieben ist oder wonach ich suchen muss? Oder evtl sogar einen Lösungsansatz?

Da wäre ich dir sehr dankbar. Ich hatte überlegt eine structure anzulegen, denn ein einzelnes anderes device schalten bekomme ich ja hin. Ginge das auch ?

Viele Grüße
Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 November 2021, 15:21:18
Wie gesagt: das paßt hier nicht in diesen Thread, und leider müßte ich ein passendes Beispiel auch suchen (afaik macht sowas ähnliches sonos-mqtt).
Ansonsten ist es ok, wenn du ein anderes Device schalten kannst und das Problem damit lösen... (evtl. braucht es zwei ;;?)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 14 November 2021, 22:19:09
Zitatmeinst du mit reinem Perl das hier? off:noArg {fhem "set Licht_WZ off; set Licht_Kueche off;";}

Nein, er meint:
off:noArg {fhem "set Licht_WZ off;; set Licht_Kueche off"}
oder
off:noArg {fhem "set Licht_WZ off";; "<topic-fuer-licht_kueche-off> <message-fuer-licht_kueche-off>" }


@Beta-User: waere es sinnvoll fuer solche Faelle eine neue Syntax zu ueberlegen, wie z.Bsp.
off:noArg <cmd1Topic> <cmd1Msg>#<cmd2Topic> <cmd2Msg>#...
Bin nicht sicher, dass das so viel besser waere, als die vorherigen Varianten.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 November 2021, 09:13:32
Zitat von: rudolfkoenig am 14 November 2021, 22:19:09
@Beta-User: waere es sinnvoll fuer solche Faelle eine neue Syntax zu ueberlegen, wie z.Bsp.
off:noArg <cmd1Topic> <cmd1Msg>#<cmd2Topic> <cmd2Msg>#...
Bin nicht sicher, dass das so viel besser waere, als die vorherigen Varianten.
Bin auch unsicher, v.a. fürchte ich Probleme bei der Erkennung des Musters vor dem Hintergrund, dass die JSON-Payloads anscheinend immer komplexer werden "müssen"...

Hier kommt ggf. auch ein Senden an einen group-Topic in Frage (mind. Tasmota kennt so etwas, für Shelly kann ich es nicht sagen). Es gibt also neben dieser Perl-Variante hier auch noch weitere Lösungsansätze, was auch dafür spricht, lieber die User in die Pflicht zu nehmen, sich erst mal mit Alternativen zu beschäftigen. Die jeweiligen Fälle sind m.E. immer so oder so etwas "speziell".
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 15 November 2021, 20:31:28
Hallo,

die beiden Codezeilen von rudolfkoenig funktionieren auch nicht. Ich hab es jetzt so gelöst, dass ich die Befehle "an" und "aus" noch hinzugefügt habe, die dann eine structure ansteuern, die die beiden Device enthält. Das funktioniert einwandfrei. Im HomeKit schaltet es nach einem HomebridgeMapping auch und zeigt den Status fehlerfrei an.

Das neue setList:
aus:noArg {fhem("set structure_LED_Kueche off")}
an:noArg {fhem("set structure_LED_Kueche on")}
off:noArg shellies/shellyrgbw2-F9920A/color/0/command off
  on:noArg shellies/shellyrgbw2-F9920A/color/0/command on
  white:colorpicker,BRI,0,1,255 shellies/shellyrgbw2-F9920A/color/0/set {"white":"$EVTPART1"}
  gain:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-F9920A/color/0/set {"gain":"$EVTPART1"}
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-F9920A/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-F9920A/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  white_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-F9920A/color/0/set {"turn":"on","white":"$EVTPART1"}
  gain_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-F9920A/color/0/set {"turn":"on","gain":"$EVTPART1"}
  rgb_on:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-F9920A/color/0/set {\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-F9920A/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}
  effect:selectnumbers,0,1,6,0,lin  shellies/shellyrgbw2-F9920A/color/0/set {"effect":"$EVTPART1"}
  x_update:noArg shellies/shellyrgbw2-F9920A/command update_fw
  x_mqttcom shellies/shellyrgbw2-F9920A/command $EVTPART1


Das homebridgeMappung:
On=state,valueOn=on,valueOff=off,cmdOn=an,cmdOff=aus

Das setStateList:
on off an aus

Das webCmd
an:aus:white:gain:rgb

Viele Grüße und vielen Dank für eure Hilfe und Denkanstöße.

Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 15 November 2021, 20:37:00
Zitatdie beiden Codezeilen von rudolfkoenig funktionieren auch nicht.
Ich muss zu meiner Verteidigung sagen, dass ich meine Zeilen nur mit einem "dummy" MQTT-Client geprueft habe, nicht mit einem RGBW-Shelly, auch die Shelly-Templates habe ich nicht angewendet.
Aber ich habe verifiziert, dass per MQTT hintereinander beide Topics in der richtigen Reihenfolge gepublisht werden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 15 November 2021, 20:51:58
Hallo,

alles gut. War nicht persönlich gemeint. Die Zeilen schalten auch aber nur ein Device. Die Lösung mit der structure funktioniert super. Ich weiß jetzt nur nicht, ob man das evtl irgendwie einfacher zu finden machen kann, wenn jemand auch vor dem RGBW den Trafo abschalten will. Ich habe keine große Ahnung vom Programmieren und habe jetzt sehr viel Zeit darauf verwendet. Vielleicht kann man die Zeit anderen ersparen?

Mit freundlichen Grüßen

Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 November 2021, 11:39:27
Zitat von: seule3008 am 15 November 2021, 20:51:58
Ich weiß jetzt nur nicht, ob man das evtl irgendwie einfacher zu finden machen kann, wenn jemand auch vor dem RGBW den Trafo abschalten will. Ich habe keine große Ahnung vom Programmieren und habe jetzt sehr viel Zeit darauf verwendet. Vielleicht kann man die Zeit anderen ersparen?
Das ist zwar eine hehre Zielsetzung, aber m.E. ist sowohl das Problem wie die Lösung m.E. "zu speziell". Vermutlich würde es in solchen Fällen reichen, die on und off-Commands (kann man per setStateList auf die "von FHEM aus geschaltet"-Fälle begrenzen) an die "weggeschalteten" Geräte per 'notify' (usw.) abzufangen und dann darüber einfach den "Vorschaltaktor" (mit) zu schalten. Simpel, schnell, generalistisch, im Kern nicht auf MQTT2_DEVICE beschränkt (und Gegenstand der Einsteigerliteratur).
Aber hier weiter [OT].
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 16 November 2021, 22:40:56
Hallo,

Das Problem ist ja, das in der setList das off command scheinbar bei dem Shelly nur mit einem Device funktioniert. Steht auch schonmal irgendwo hier im Forum. Alle Versuche schalten immer nur ein Device, deswegen der Umweg über die structure. Evtl liegt es auch an dem Shelly template, aber das so umzuschreiben das das evtl doch geht übersteigt meine Fähigkeiten was das angeht.

Viele Grüße

Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 November 2021, 09:42:06
Nochmal zur Klarstellung, weil du scheinbar immer noch mehreren Missverständnissen aufsitzt:
- Man kann mit Perl in der setList "allen möglichen Unfug" machen. Von mir gibt es z.B. für ebus Code (verteilt via attrTemplate), der bis zu 7 publishes absetzt, und Rudi hatte auch ein getestetes Beispiel, mit dem man mehrere Geräte schalten kann. Es ist also völlig flexibel, was man machen _kann_. Bei der ebus-Sache halte ich das für sinnvoll (weil man ein Wochenprofil aus technischen Gründen in 7 Tagesprofile aufsplitten muss), in anderen Fällen eher nicht, denn
- zu machen, was möglich ist, ist aber nicht immer sinnvoll, schon gleich nicht via "template":
-- andere Devices zu schalten, ist nicht unbedingt das, was der User erwartet => verwirrend, schlecht wartbar => "don't try this at home...". Das gilt insbesondere auch für die "Lösung" mit der structure (die ist überkomplex, siehe unten)
-- für "paralleles Schalten" gibt es andere, externe Lösungen (z.B. notify), die generischer sind, und bei denen dann die Querbeziehungen auch vial FHEMWEB visualisiert werden.

Kurz gesagt: Deine Lösung ist keine "gute Lösung" in dem Sinne, dass man das zur Nachahmung empfehlen sollte. Damit sollten wir diese OT-Diskussion jetzt aber beenden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 24 Dezember 2021, 11:57:58
Hey zusammen,

das Template vom Shellyplus1pm ist noch nicht ganz rund.
Die JSON Map muss angepasst werden und sollte so aussehen:
attr MQTT2_shellyplus1pm_7c87ce657e74 jsonMap params_switch_0_aenergy_total:aenergy_total switch_0_apower:apower switch_0_temperature_tC:temperature switch_0_temperature_tF:0 params_wifi_sta_ip:ip

Die radingsList:
attr MQTT2_shellyplus1pm_7c87ce657e74 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:.* { json2nameValue($EVENT, 'switch_0_', $JSONMAP) }\
  fhem/rpc:.* { json2nameValue($EVENT,'rpc_',$JSONMAP) }


Und das devicetopic wird leider nicht gesetzt. Ich hab das manuell nachgetragen.
Zeile 3333 im Template solle von "attr DEVICE devicetopic DEV_TOPIC" glaube ich auf "attr DEVICE devicetopic BASE_TOPIC"

Und bei devStateIcon braucht man, keine doppelten ;;

Gruß,
87Insane
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 24 Dezember 2021, 13:15:28
Hmm, vermutlich ist es jetzt immer noch nicht rund...

Warum DEV_TOPIC nicht aufgelöst wird, ist mir im Moment noch unklar, ich hatte das auf Basis eines vermutlich schon "versauten" listings gebastelt (=> wenn möglich ein "frisches" RAW liefern, wie autocreate es erzeugt).

"fhem/rpc" sieht in der readingList komisch aus, mir unklar, wer das wann warum erzeugt, aber für alle passend ist es ziemlich sicher nicht.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Dezember 2021, 10:59:52
Ja mach ich dieses WE.

Das RPC erscheint auch erst nach dem ersten schalten. Ist quasi ein zusätzlicher back Channel. Aktuell sendet das Template mit fhem rein.
Der Eintrag erscheint auch erst nachdem man einmal einen Befehl aus fhem heraus sendet. Mir ist noch nicht klar, wie das Gerät gebunden bleibt bei mehreren shelly. Normal ist da shelly-id:fhem/....

Ein neues autocreate wird aber helfen....meld mich.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 25 Dezember 2021, 11:23:13
Hmm, scheint dann vom ESP aus dem JSON entnommen zu werden und nochmal als Bestätigung gepublisht... Dann sollte man es ignorieren, oder der Sendepfad im JSON müßte angepaßt werden.
(Wer denkt sich so einen m.E. unnötig komplizierten Code aus...)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 25 Dezember 2021, 13:12:56
Hey - Anbei mal alles was ich so getestet habe...

frisches RAW von einem PLUS 1PM:
defmod MQTT2_shellyplus1pm_7c87ce658380 MQTT2_DEVICE shellyplus1pm_7c87ce658380
attr MQTT2_shellyplus1pm_7c87ce658380 readingList shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/online:.* online\
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/sys:.* { json2nameValue($EVENT) }\
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/mqtt:.* { json2nameValue($EVENT) }\
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/switch_0:.* { json2nameValue($EVENT) }\
shellyplus1pm_7c87ce658380:mqttexplorer/rpc:.* { json2nameValue($EVENT) }\
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/events/rpc:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1pm_7c87ce658380 room MQTT2_DEVICE

setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 12:56:54 IODev MQTT2_FHEM_Server
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 aenergy_by_minute_1 0.000
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 aenergy_by_minute_2 0.000
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 aenergy_by_minute_3 0.000
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 aenergy_minute_ts 1640433748
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 aenergy_total 0.000
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 apower 0.0
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 available_updates_beta_version 0.9.2-beta2
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 cfg_rev 4
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 connected true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 current 0.0
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 dst shellyplus1pm-7c87ce658380/events
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 fs_free 233472
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 fs_size 458752
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 id 0
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 mac 7C87CE658380
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 method NotifyStatus
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 online true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 output false
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_cfg_rev 4
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_component mqtt
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_event config_changed
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_restart_required true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_events_1_ts 1640433773.82
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_mqtt_connected true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_switch_0_id 0
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_switch_0_voltage 224.9
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 params_sys_available_updates_beta_version 0.9.2-beta2
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:53 params_sys_restart_required true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 params_ts 1640433790.80
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_wifi_rssi -45
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_wifi_ssid KA-nG-WLan_2.4Ghz
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_wifi_sta_ip 192.168.20.138
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 params_wifi_status got ip
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 ram_free 178512
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 ram_size 249536
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 restart_required false
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:30 result_was_on true
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 source init
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 src shellyplus1pm-7c87ce658380
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 temperature_tC 44.4
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 temperature_tF 111.9
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 time 13:03
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 unixtime 1640433790
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:03:09 uptime 14
setstate MQTT2_shellyplus1pm_7c87ce658380 2021-12-25 13:02:57 voltage 224.9


Im Shelly MQTT kann eingestellt werden:
- RPC status notifications over MQTT - an/aus
- Generic status update over MQTT - an/aus
auch MQTTS wäre möglich.

Zur Erklärung der readingsList:
Wenn beide o.g. Optionen aus sind, bekommt man nur folgendes Reading:
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/online:.* online

Wenn Generic status update over MQTT aktiv ist bekommt man:
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/sys:.* { json2nameValue($EVENT) }
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/mqtt:.* { json2nameValue($EVENT) }
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/status/switch_0:.* { json2nameValue($EVENT) }


Wenn RPC status notifications over MQTT aktiv ist bekommt man:
shellyplus1pm_7c87ce658380:shellyplus1pm-7c87ce658380/events/rpc:.* { json2nameValue($EVENT) }

Die Zeile aus dem Pfad:
shellyplus1pm_7c87ce658380:mqttexplorer/rpc:.* { json2nameValue($EVENT) }
ergibt sich aus dem sende JSON... Ich habe das mal extra angepasst um zu zeigen was sich ändert...

Das hier wäre ein normales toggle via MQTT:
{
  "id": 0,
  "src": "mqttexplorer",
  "method": "Switch.Toggle",
  "params": {
    "id": 0
  }
}

die src Zeile entscheidet über den Namen der dann erscheint.

Was damit wieder auf deine Aussage trifft. Ggf den Sender mit "BASE_TOPIC" versehen?



Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 27 Dezember 2021, 06:44:42
Zitat von: 87insane am 25 Dezember 2021, 13:12:56
Was damit wieder auf deine Aussage trifft. Ggf den Sender mit "BASE_TOPIC" versehen?
Weiß nicht recht, das ist unschön, v.a., weil das "unendlich" ist: mqttexplorer/rpc
Mein Eindruck ist weiter, dass das nicht richtig durchdacht ist.

Im Moment neige ich eher dazu, den "fhem"-Zweig mit einem leeren Perl ins Nirvana zu schicken bzw. ggf. fhem2shelly daraus zu machen, damit man das direkt mit einer ignoreRegexp am IO rausfiltern kann. Wenn man den originalen Topic nehmen würde, hat man eine Doppelung von Senden und Empfangen auf demselben Topic, und das geht gefühlt gar nicht.

Siehe auch https://forum.fhem.de/index.php/topic,124995.0.html, da schlagen sich auch ein paar Leute mit Fragen rund um plus1pm@MQTT rum...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 30 Dezember 2021, 17:09:39
Habe meinen Ansatz mal eingefügt...

https://forum.fhem.de/index.php/topic,124995.msg1196882.html#msg1196882
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Januar 2022, 22:00:41
Zitat von: 87insane am 30 Dezember 2021, 17:09:39
Habe meinen Ansatz mal eingefügt...
Danke für's Testen.

Habe aus den weiteren Bausteinchen jetzt wieder eine aktualisierte Fassung für die attrTemplates gebastelt, da war leider manches eher noch unausgereift.
Jetzt sollte es für den plus1pm passen, und ich hoffe auch für den normalen plus1.

Weiter habe ich eine erste Variante für den shelly4pro eingecheckt, damit sollten sich die Dinger auch zumindest mal schalten lassen.

Insgesamt gefallen mir die Teile nicht, die sind nochmal gesprächiger als normale Shelly, und das Format, in dem die Daten dann ausgetauscht werden, ist auch nicht "meins". Dazu dann noch unerklärliche Unterschiede in dem, was die 1-er machen zu dem, wie es beim 4-er ist. Grausam...

Mittelfristig würde ich anregen, die ganze Vorverarbeitungs-Arbeit in eine myUtils auszulagern und da auch gleich "eocr"-Prüfungen mit einzubauen. Da es zuhauf schon Beispielcode für ähnliche Aufgaben gibt, wäre ich ausgesprochen erfreut, wenn sich darum mal jemand anders kümmern würde - wenn ich auf den Gedanken käme, einen Shelly neuerer Bauart zu erwerben, hätte ich nämlich sofort den Impuls, das Ding auf Tasmota umzuflashen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gvzdus am 04 Januar 2022, 22:16:59
Herzlichen Dank!

Ich denke, "als FHEM" kommen wir nicht daran vorbei, die Shellys allesamt zu unterstützen - so fehlgriffig das Protokoll auch sein mag. Schön, wenn es jetzt einen Weg für gleich 3 Geräte mehr gibt!

Nein, ich kann Dir nicht folgen :-). Du bist mir jetzt mit 2 Schritten voraus:
a) das Problem zu verstehen
b) das Problem zu lösen
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 Januar 2022, 22:57:36
Zitat von: gvzdus am 04 Januar 2022, 22:16:59
Herzlichen Dank!
Gerne :) . Danke zurück für's "Spielzeug".

Zitat
Ich denke, "als FHEM" kommen wir nicht daran vorbei, die Shellys allesamt zu unterstützen
Schon klar, aber Werbung mache ich für den Sch... nicht. Es werden Unmengen an unnützer Info recht regelmäßig in einem völlig kruden Format versendet. Ist imo nicht "MQTT"-like, das sollte "leichtgewichtig" sein und sparsam. Basta!

Zitat
Nein, ich kann Dir nicht folgen :-). Du bist mir jetzt mit 2 Schritten voraus:
a) das Problem zu verstehen
b) das Problem zu lösen
Das "Problem" besteht aus mehreren Stufen:
Zum einen muss man erst mal rausfinden, in welchem Format der Shelly das jeweils haben will. Schon das scheint etwas speziell zu sein, verschärft wird das leider durch $DEVICETOPIC-Nutzung - wenn man das via attrTemplate und "copy"-Befehlen macht, muss man nämlich erst die internen Daten bereinigen, was am einfachsten geht, wenn man die DEF anfasst - dabei geht aber leider das Internal DEVICETOPIC hops.... Hat etwas länger gebraucht, bis ich da draufgekommen bin ::) .

Dann ist der "Rückweg" auch mehrfach nicht so einfacht:
- unterschiedliche Topics bei shellyplus1 und shelly4pro;
- "true" statt "on" => man braucht Ersetzungen, die aber nicht zu unscharf sein sollten, damit man nicht an anderer Stelle unbeabsichtigte Nebenwirkungen hat;
- und zu guter Letzt ist die interne Datenstruktur verschachtelt, so dass man erst mal ziemlich lange (und nicht "standardkonforme") Reading-Namen bekommt, die man dann wieder gradeziehen darf... Das ganze beim shelly4pro über einen "Einheitstopic", so dass man erst mal aussortieren muss, für was man sich beim einzelnen Kanal eigentlich interessiert...

Klarer jetzt?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 05 Januar 2022, 11:05:26
Ich versuche im Thread zur Anbindung weiter zu helfen. Hier sind aber eher FHEM Themen das Problem...
Egal...

Zeile 3364 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L3364) ist noch nicht korrekt.
So sieht es bei einem 1pm bei mir aus:
params_switch_0_aenergy_total:aenergy_total switch_0_apower:apower switch_0_temperature_tC:temperature switch_0_temperature_tF:0 params_wifi_sta_ip:ip

Nun hast du fhem2shelly aus dem RPC gemacht. Ich habe noch keinen wirklichen Nutzen gefunden für den Zweig. Ggf. an der Bridge ganz rauß nehmen?
Ich hoffe das Allterco auch wieder normal wird und nicht den ganzen Inhalt einen Zweiges, einfach in ein JSON packt. Ich schließe mich da Beta-User an -> schlimm!
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Januar 2022, 11:28:51
Hmm, vermutlich paßt das noch nicht so ganz mit dem jsonMap, aber das "Problem" ist auch, dass die readingList geändert ist. Damit müßten die "0_"-Wurmfortsätze in der Regel eigentlich insgesamt ziemlich weg sein (?).

Den Topic-Beginn "fhem2shelly/" kann man mAn. guten Gewissens in die ignoreRegexp eines jeden IO mit reinnehmen, das ist im attrTemplate nur drin, weil vermutlich ein Teil der User nicht mitbekommt, dass es "Murks" ist, die Anweisung wieder auszuwerten... Anscheinend ist das mit der "src" aber "mandatory" (die Doku des Herstellers ist nicht ganz eindeutig). Daher ist es eben jetzt "zwangsabgeleitet" auch via readingList - doppelt genäht hält besser...

Sorry für den etwas unvollständigen Zwischenstand, mir war erst mal wichtig, dass das mit dem Schalten reibungslos funktioniert und hatte dann gestern keine Lust mehr, das komplett auch noch auszutesten und zu optimieren. Ist ja jetzt kein Hexenwerk mehr...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 07 Januar 2022, 09:40:21
Wegen eurer Ratereien im shellyplus1pm-Thread:
Das Mapping für state hatte ich mit einer "remote"-Instanz ausgetestet, aber ohne die Einstellungen zu sehen, welche die firmware hatte. Ich gehe davon aus, dass die "default" war, firmwarestand könnte ich notfalls nochmal checken.
Falls (!) die shelly-2.gen. aber "alle" so ticken wie der  4er, könnte man auch einfach dessen readingList (für den 1. Kanal, ggf. etwas verändert) nehmen, und die weiteren Topics einfach nach Nirvana "ableiten".

Man sollte sich halt auf einen Stand einigen, auf dem die Einstellungen sein sollten (möglichst: nichts ändern), und dann die aktuellste firmware zugrunde legen (notfalls: die beta!, falls die "einfacher" oder "anders" ist, was die Datenstrukturen angeht).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 09 Januar 2022, 19:47:37
Heute einige Tests mit dem ShellyPlus1PM durchgeführt und Folgendes festgestellt:

... MQTT2_CLIENT_general_bridge
    ... bridgeRegexp unterstützt noch nicht die neuen shellyp(lus|ro4pm)

... shellyPlus_1pm
    ... Firmware version 0.9.1
        - "Generic status update over MQTT" scheint notwendig
        - params-Readings werden nur sporadisch gesetzt ... temperature, voltage fast nie - ausser bei Schaltvorgängen
        - status/sys ändert Readings scheinbar nur beim Start des Geräts ... uptime und ähnliche Readings bislang sinnlos
        - status/switch_0 scheint momentan eine Schlüsselrolle einzunehmen, da nur dessen Readings ständig aktualisiert werden
        - jsonMap ... switch_aenergy_total existiert
          ... daher von params_switch_0_aenergy_total:aenergy_total auf switch_aenergy_total:aenergy_total ändern
        - devStateIcon nutzt Reading new_fw; dieses existiert aber nicht - überflüssig ?
    ... Firmware 0.9.2-beta2
        - erscheint aktuell unbrauchbar, da selbst die status/switch_0-Readings so gut wie nie aktualisiert werden
        - wieder zurück auf 0.9.1
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: smoudo am 11 Januar 2022, 00:19:32
Ich denke wir machen in dem Thread weiter. Vielen Dank erstmal an @87insane , @OdfFhem und @Beta-User ! mir sind jetzt einige Sachen klarer.
Mein ShellyPlus_1pm ist auch angekommen und nr.1 verbaut. Mit dem neuen Template funktioniert das teil top! Allerdings nur mit aktiviertem Generic status update.

Das vorhandene Problemkind ShellyPlus_1 habe ich nochmal komplett gelöscht und neu anlegen lassen mit dem aktuellen Template. Für die Temperaturausgabe ist mir im jsonMap noch ein Fehler aufgefallen.
Das Reading vom Gerät heißt switch_temperature_tC. Anbei meine geänderte jsonMap zum testen.
switch_state:state params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower switch_temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip
Allerdings aktualisiert sich der Shelly in FHEM nicht. Nur Restart oder Schaltvorgang setzt readings neu.
im ShellyPlus_1pm kommt jede Minute eine Aktualisierung. 

Kann man irgendwo in den Intervalleinstellungen eingreifen?

Noch eine verständnisfrage: sobald mit set attrTemplate ein Template gesetzt ist sollte das ganze laufen?! Muss das attr model weiterhin gesetzt werden?

Anbei noch das RAW vom Problemfall ShellyPlus_1
defmod Strom_Strasse MQTT2_DEVICE shellyplus1_a8032abcdffc
attr Strom_Strasse 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';;;; $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>)}
attr Strom_Strasse devicetopic shellyplus1-a8032abcdffc
attr Strom_Strasse event-on-change-reading .*
attr Strom_Strasse group Aussensteckdosen
attr Strom_Strasse icon message_socket
attr Strom_Strasse jsonMap switch_state:state params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower switch_temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip
attr Strom_Strasse model shellyPlus_1
attr Strom_Strasse 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:.* {}
attr Strom_Strasse room Outdoor
attr Strom_Strasse 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"}
attr Strom_Strasse setStateList on off toggle
attr Strom_Strasse webCmd : on:off

setstate Strom_Strasse off
setstate Strom_Strasse 2022-01-10 23:47:50 IODev MQTT2_FHEM_Server
setstate Strom_Strasse 2022-01-10 23:50:07 attrTemplateVersion 20220104
setstate Strom_Strasse 2022-01-11 00:05:40 dst shellyplus1-a8032abcdffc/events
setstate Strom_Strasse 2022-01-10 23:50:28 ip 192.168.1.50
setstate Strom_Strasse 2022-01-11 00:05:40 method NotifyStatus
setstate Strom_Strasse 2022-01-10 23:50:28 mqtt_connected true
setstate Strom_Strasse 2022-01-10 23:50:28 online true
setstate Strom_Strasse 2022-01-10 23:50:28 params_mqtt_connected true
setstate Strom_Strasse 2022-01-11 00:05:40 params_switch_0_id 0
setstate Strom_Strasse 2022-01-11 00:05:40 params_switch_0_output false
setstate Strom_Strasse 2022-01-11 00:05:40 params_switch_0_source MQTT
setstate Strom_Strasse 2022-01-10 23:50:38 params_sys_available_updates_beta_version 0.9.2-beta2
setstate Strom_Strasse 2022-01-11 00:05:40 params_ts 1641855941.17
setstate Strom_Strasse 2022-01-10 23:50:28 params_wifi_rssi -58
setstate Strom_Strasse 2022-01-10 23:50:28 params_wifi_ssid homenet 24
setstate Strom_Strasse 2022-01-10 23:50:28 params_wifi_status got ip
setstate Strom_Strasse 2022-01-11 00:05:40 src shellyplus1-a8032abcdffc
setstate Strom_Strasse 2022-01-11 00:05:40 state off
setstate Strom_Strasse 2022-01-11 00:05:40 switch_id 0
setstate Strom_Strasse 2022-01-11 00:05:40 switch_source MQTT
setstate Strom_Strasse 2022-01-10 23:51:42 switch_temperature_tC 45.5
setstate Strom_Strasse 2022-01-11 00:05:40 switch_temperature_tF 114.4
setstate Strom_Strasse 2022-01-10 23:50:38 sys_available_updates_beta_version 0.9.2-beta2
setstate Strom_Strasse 2022-01-10 23:50:38 sys_cfg_rev 45
setstate Strom_Strasse 2022-01-10 23:50:38 sys_fs_free 241664
setstate Strom_Strasse 2022-01-10 23:50:38 sys_fs_size 458752
setstate Strom_Strasse 2022-01-10 23:50:38 sys_mac A8032ABCDFFC
setstate Strom_Strasse 2022-01-10 23:50:38 sys_ram_free 180928
setstate Strom_Strasse 2022-01-10 23:50:38 sys_ram_size 249676
setstate Strom_Strasse 2022-01-10 23:50:38 sys_restart_required false
setstate Strom_Strasse 2022-01-10 23:50:38 sys_time 23:50
setstate Strom_Strasse 2022-01-10 23:50:38 sys_unixtime 1641855038
setstate Strom_Strasse 2022-01-10 23:50:38 sys_uptime 11
setstate Strom_Strasse 2022-01-11 00:05:40 temperature 45.8



viele Grüße

Matze
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 11 Januar 2022, 00:21:40
Hallo an alle und ein Frohes neues Jahr wünsche ich euch.

Ich habe ein Problem und evtl hat einer von euch eine Lösung dafür. Es geht um das readingList im Shelly RGBW2 Weiß template. Ich würde gerne die readings des RGBW2 durch die eines Shelly 2.5 ersetzen. Wieso möchte ich das? Ich habe einen Shelly 2.5 der den Trafo schaltet hinter dem dann der RGBW2 angeschlossen ist. Beim Einschalten habe ich also beim 2.5 den state on und beim RGBW2 den state set_on bis er sich im Wlan angemeldet hat. Dann wechselt der state auf on. Beim Abschalten wiederum habe ich beim 2.5 den state off und beim RGBW2 den state set_off. Dieser wechselt allerdings nich auf off da der RGBW2 kein Strom mehr hat. Daraus ergibt sich das Problem, dass im HomeKit der RGBW2 auf on bleibt. Nun habe ich im RGBW2 die zweite Zeile des readingList, die ersten 2 Zeilen des SetList umgeschrieben und es gibt noch ein NOTIFY, dass die Schaltzustände abgleicht egal ob ich über den Taster, in Fhem oder im HomeKit schalte. Das on bzw off wird nun vom 2.5 genommen und angezeigt. Allerdings funktioniert das Dimmen jetzt nicht mehr. Es kommt immer set_brightness und weiter passiert nichts. Ich verstehe nicht ganz was der State mit dem dimmwert zu tun hat. Einen anderen Ansatz das Problem über das HomebridgeMapping zu lösen habe ich versucht aber set_off als off zu übergeben klappt scheinbar nicht.

Anbei noch ein List der Ansätze die nicht funktioniert haben:

HomebridgeMapping
On=state,values=on:on;set_on:on;off:off;set_off:off,cmdOn=on,cmdOff=off
Brightness=brightness,cmd=brightness


HomebridgeMapping die 2.
On=state,valueOn=/on|set_on/;ValueOff=/off|set_off/,cmdOn=on,cmdOff=off
Brightness=brightness,cmd=brightness


readingList
shellies/shellyrgbw2-DE53C8/white/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}
  shellies/shellyswitch25-E8DB84ACE5FC/relay/0:.* state
  shellies/shellyrgbw2-DE53C8/white/0/set:.* { json2nameValue($EVENT) }
  shellies/shellyrgbw2-DE53C8/online:.* online
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-DE53C8...mac.*, ? json2nameValue($EVENT) : return }


setList
off:noArg shellies/shellyswitch25-E8DB84ACE5FC/relay/1/command off
  on:noArg shellies/shellyswitch25-E8DB84ACE5FC/relay/1/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-DE53C8/white/0/set {"mode":"white","brightness":"$EVTPART1"}
brightness_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-DE53C8/white/0/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
  x_update:noArg shellies/shellyrgbw2-DE53C8/command update_fw
  x_mqttcom shellies/shellyrgbw2-DE53C8/command $EVTPART1


und ein List des ganzen Device

Internals:
   CID        shellyrgbw2_DE53C8
   DEF        shellyrgbw2_DE53C8
   DEVICETOPIC Dimmer_Spitze
   FUUID      61dc11d1-f33f-b214-0112-5e6c07f3ae9b7543
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 108
   MQTT2_TIME 2022-01-11 00:11:59
   MSGCNT     108
   NAME       Dimmer_Spitze
   NR         102
   STATE      set_off
   TYPE       MQTT2_DEVICE
   READINGS:
     2022-01-10 12:05:03   associatedWith  MQTT2_shellyrgbw2_DE53C8_CH2,MQTT2_shellyrgbw2_DE53C8_CH3,MQTT2_shellyrgbw2_DE53C8_CH4
     2022-01-10 12:05:02   attrTemplateVersion 20200531
     2022-01-11 00:10:19   brightness      69
     2022-01-11 00:10:19   has_timer       false
     2022-01-11 00:10:19   ison            true
     2022-01-11 00:10:19   mode            white
     2022-01-11 00:11:59   online          false
     2022-01-11 00:10:19   overpower       false
     2022-01-10 16:50:52   pct             47
     2022-01-11 00:10:19   power           9.83
     2022-01-11 00:10:19   source          mqtt
     2022-01-11 00:12:06   state           set_off
     2022-01-11 00:10:19   timer_duration  0
     2022-01-11 00:10:19   timer_remaining 0
     2022-01-11 00:10:19   timer_started   0
     2022-01-11 00:10:19   transition      0
     2022-01-10 12:05:03   x_mqttcom       set announce
Attributes:
   IODev      MQTT2
   autocreate 0
   comment    Channel 1 for MQTT2_shellyrgbw2_DE53C8, see also MQTT2_shellyrgbw2_DE53C8_CH2, MQTT2_shellyrgbw2_DE53C8_CH3 and MQTT2_shellyrgbw2_DE53C8_CH4
   genericDeviceType light
   group      Licht
   homebridgeMapping On=state,values=on:on;set_on:on;off:off;set_off:off,cmdOn=on,cmdOff=off
Brightness=brightness,cmd=brightness
   icon       light_control
   model      shelly2rgbw_4w_split
   readingList shellies/shellyrgbw2-DE53C8/white/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}
  shellies/shellyrgbw2-DE53C8/white/0:.* state
  shellies/shellyrgbw2-DE53C8/white/0/set:.* { json2nameValue($EVENT) }
  shellies/shellyrgbw2-DE53C8/online:.* online
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-DE53C8...mac.*, ? json2nameValue($EVENT) : return }
   room       Dachgeschoss,Homekit
   setList    off:noArg shellies/shellyswitch25-E8DB84ACE5FC/relay/1/command off
  on:noArg shellies/shellyswitch25-E8DB84ACE5FC/relay/1/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-DE53C8/white/0/set {"mode":"white","brightness":"$EVTPART1"}
brightness_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-DE53C8/white/0/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
  x_update:noArg shellies/shellyrgbw2-DE53C8/command update_fw
  x_mqttcom shellies/shellyrgbw2-DE53C8/command $EVTPART1
   setStateList on off brightness
   webCmd     on:off:brightness


Ich hoffe das jemand sowas schonmal hatte. Ich denke ja nicht, dass das so ungewöhnlich ist den Trafo abzuschalten oder??

Vielen Dank im Voraus und viele Grüße

Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 11 Januar 2022, 05:11:12
Zitat von: smoudo am 11 Januar 2022, 00:19:32
Für die Temperaturausgabe ist mir im jsonMap noch ein Fehler aufgefallen ...
switch_state:state params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower switch_temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip
Hier gibt es (vermutlich) noch mehr Korrekturbedarf:
- "temperature_tF:0" müsste "switch_temperature_tF:0 " lauten; Deine RAW zeigt, dass das tF-Reading bislang weiterhin aktualisiert wird
- apower bzw. aenergy_total gibt es mangels Leistungsmessung beim reinen 1er nicht (s.a. RAW) und sollte entfernt werden

Zitat von: smoudo am 11 Januar 2022, 00:19:32
Kann man irgendwo in den Intervalleinstellungen eingreifen?
Scheint aktuell noch nicht möglich, kommt aber vielleicht noch ...
Bei meiner Analyse der 1pm-Variante änderte sich relativ oft das temperature- bzw. voltage-Reading; weiterhin aber auf jeden Fall jede Minute mindestens ein ts-Reading (z.B. params_ts). Ich hatte bei mir deshalb die ts-Readings via jsonMap-Attribut geerdet; erscheinen auf den ersten Blick doch ähnlich nutzlos wie die tF-Readings. So wirkt die "Flut" der FHEM-Events etwas erträglicher ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: smoudo am 11 Januar 2022, 08:35:31
Das ist korrekt. Um das Tf mapping habe ich mich erstmal nicht gekümmert, da nicht in Benutzung. Muss der vollständigkeit halber noch getan werden.
Nichts destotrotz wird Kein Reading ohne Schalthandlung aktualisiert. Das heißt da steht bis zum nächsten Zeitschaltpunkt alles auf Readingtime 2022-01-11 00:05:40.
Beim Shellyplus_1pm bekomme ich jede volle Minute eine Aktualisierung von div. Readings.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Januar 2022, 09:46:05
Zitat von: seule3008 am 11 Januar 2022, 00:21:40
Ich habe ein Problem und evtl hat einer von euch eine Lösung dafür. Es geht um das readingList im Shelly RGBW2 Weiß template.
Hmm, würde vorschlagen, für dieses etwas spezielle Thema einen eigenen Thread zu starten, das ist kein Konfigurationsthema im engeren Sinne. Tendenziell würde ich das nur "one-way" via notify lösen und das state -reading im "off"-Fall übertragen, sonst nicht.

Das mit set_brightness kommt daher, dass du das in setStateList aufgenommen hast, im attrTemplate "shelly2rgbw_4w_split" steht da (aus gutem Grund, wie ich meine) nur on und off...

Zitat von: smoudo am 11 Januar 2022, 08:35:31
Nichts destotrotz wird Kein Reading ohne Schalthandlung aktualisiert. Das heißt da steht bis zum nächsten Zeitschaltpunkt alles auf Readingtime 2022-01-11 00:05:40.
Beim Shellyplus_1pm bekomme ich jede volle Minute eine Aktualisierung von div. Readings.
MAn. ist das doch super: der "normale" 1-er kann eigentlich nur on/off, und die Temperatur ist eh "für den Arsch", weil intern gemessen. Da sollte auch nach meinem Gefühl nur eine Aktualisierung kommen, wenn sich was ändert (das mit den ständigen unnötigen updates war an den alten schlecht!).
Beim 1pm wird gemessen, also regelmäßige updates. Da stellt sich dann nur die Frage, was wann in FHEM zu aktualisieren ist, also wie ggf. eocr&Co. (v.a. für "state") zu setzen sind :) .

Eure Vorschläge (auch zum M2C-bridgeRegexp-Ding) sollten mit dem heutigen update eigentlich soweit eingearbeitet sein. DANKE, dass da jetzt (endlich) konstruktive Bewegung reinkommt :) .



Nachdem sich in letzter Zeit wieder die Beiträge gehäuft haben, bei denen diverse Leute mit meinen Anregungen überfordert gewesen zu sein scheinen, habe ich mal einen Wiki-Artikel angefangen zur Frage, wie man eigentlich vorgehen sollte, wenn man sich einem "unbekannten MQTT-Gerät" nähert: https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt

Wer dazu konstruktive Anmerkungen hat, darf gerne mit drin rumbasteln und/oder Fragen im Wiki-Bereich des Forums loswerden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: smoudo am 11 Januar 2022, 17:23:23
Ansich hast du recht, eine Logik im Gerät, auch gerade mit den wechselnden Readings kann ich nicht immer erkennen. Und wenn man zum Schluss nicht 100% weiß wie sich das Gerät verhält, wird am Template ewig rumgebastelt. Gibt es von Seiten Shelly irgendeine offizielle readinglist o.ä. Welche man bemühen kann?
Ansonsten ist das anstrengend. Ich werde nachher das Teil mal vom Strom nehmen um zu schauen ob die online/offline bzw. Present/absent Funktion geht. Das bezweifle ich nämlich stark wenn das Teil sich nicht meldet.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 11 Januar 2022, 17:35:51
Zitat von: smoudo am 11 Januar 2022, 17:23:23
Gibt es von Seiten Shelly irgendeine offizielle readinglist o.ä. Welche man bemühen kann?
Es gibt die offiziellen API-Beschreibungen, mit denen kann man sich das eine oder andere zusammenpuzzeln, wenn man etwas Übung oder Phantasie hat...

Zitat
Ansonsten ist das anstrengend. Ich werde nachher das Teil mal vom Strom nehmen um zu schauen ob die online/offline bzw. Present/absent Funktion geht. Das bezweifle ich nämlich stark wenn das Teil sich nicht meldet.
Ist eine "LWT"-Funktionalität, und die wird vom MQTT-Server überwacht. Wenn also überhaupt irgendeine online-Meldung mal ankam, geht das Ding auch offline...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: smoudo am 11 Januar 2022, 19:57:04
Online/offline Anzeige funktioniert.
Temperatur ist so ziemlich nutzlos.
Ich finde Temperaturwerte garnicht so doof, die könnte man überwachen lassen das die Teile nicht abfackeln.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 11 Januar 2022, 22:55:13
Zitat von: Beta-User am 11 Januar 2022, 09:46:05
Hmm, würde vorschlagen, für dieses etwas spezielle Thema einen eigenen Thread zu starten, das ist kein Konfigurationsthema im engeren Sinne. Tendenziell würde ich das nur "one-way" via notify lösen und das state -reading im "off"-Fall übertragen, sonst nicht.

Das mit set_brightness kommt daher, dass du das in setStateList aufgenommen hast, im attrTemplate "shelly2rgbw_4w_split" steht da (aus gutem Grund, wie ich meine) nur on und off...
MAn. ist das doch super: der "normale" 1-er kann eigentlich nur on/off, und die Temperatur ist eh "für den Arsch", weil intern gemessen. Da sollte auch nach meinem Gefühl nur eine Aktualisierung kommen, wenn sich was ändert (das mit den ständigen unnötigen updates war an den alten schlecht!).
Beim 1pm wird gemessen, also regelmäßige updates. Da stellt sich dann nur die Frage, was wann in FHEM zu aktualisieren ist, also wie ggf. eocr&Co. (v.a. für "state") zu setzen sind :) .

Eure Vorschläge (auch zum M2C-bridgeRegexp-Ding) sollten mit dem heutigen update eigentlich soweit eingearbeitet sein. DANKE, dass da jetzt (endlich) konstruktive Bewegung reinkommt :) .



Nachdem sich in letzter Zeit wieder die Beiträge gehäuft haben, bei denen diverse Leute mit meinen Anregungen überfordert gewesen zu sein scheinen, habe ich mal einen Wiki-Artikel angefangen zur Frage, wie man eigentlich vorgehen sollte, wenn man sich einem "unbekannten MQTT-Gerät" nähert: https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt

Wer dazu konstruktive Anmerkungen hat, darf gerne mit drin rumbasteln und/oder Fragen im Wiki-Bereich des Forums loswerden.

Hallo Beta-User

Wenn ich beide Brightness Zeilen entferne, kann ich nicht mehr dimmen. Allerdings, wenn ich nur die Zeile brightness_on lösche, kommt auch set_brightness aber es verschwindet nach maximal 30sec, wenn das reading vom Shelly zurück kommt. Aber damit kann ich leben, denn im HomeKit funktioniert alles perfekt.

Vielen Dank für den Tip.

Ich begebe mich jetzt mal an das Notify von dir und versuche es von 2 auf 3 Device  umzuschreiben. Mal sehen ob ich das hinbekomme die Schaltzustände abzugleichen.

Grüße

Christian

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 15 Januar 2022, 00:14:25
Aktuelle Beobachtungen beim Einsatz von ShellyPlus1PM:

... Template shellyPlus_1
    ... analog zu on-for-timer nutze ich derzeit auch off-for-timer
        ... Gerät wird mit Ausführung sofort ausgeschaltet (sofern nicht sowieso schon aus)
        ... Gerät wird nach der angegebenen Anzahl Sekunden autom. "umgeschaltet"
        ... mögliche Ergänzung von setList

off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\


... Template shellyPlus_1pm
    ... keine neuen Vorschläge

... Firmware version 0.9.2
    ... offiziell verfügbar seit 14.01.2022
    ... die Anzahl der MQTT-Aktualisierungen ist stark zurückgegangen
        ... falls eingeschaltet, finden (erwartungsgemäß) regelmäßige Aktualisierungen statt
        ... falls ausgeschaltet, gilt: es muss etwas ausgelöst werden, ansonsten herrscht Funkstille
    ... es gibt jetzt auch einen zunächst experimentellen "Economy mode" (betamäßig auch für die alten Shellies)
        ... wird dieser aktiviert, wird der Shelly im "low-power mode" betrieben
        ... dadurch kann/soll dann z.B. die (meist hohe) Betriebstemperatur im eingeschalteten Zustand um bis zu 15° sinken
        ... kann nur indirekt aktiviert/deaktiviert werden (u.a. nicht über Oberfläche) ... vermutlich ein Feature für setList - interessant ?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 15 Januar 2022, 07:59:17
off-for-timer sollte mit allen 2.gen-Shelly funktionieren, hab's (überall&korrekt?) eingebaut.

Den reduzierten Traffic finde ich jedenfalls vom Ansatz her gut - mal schauen, wie die allgemeine Resonanz dazu ist.

Was den low-power-Modus angeht: Prinzipiell finde ich es gut, wenn man als Anwender nicht zu sehr frickeln muss, um sinnvolle Dinge umzusetzen. Da es vermutlich frickelig ist, stellt sich eigentlich nur die Frage, ob es sinnvoll ist bzw. welche Nebenwirkungen das ggf. hat...? Warte daher mal auf Rückmeldungen dazu, es wäre aber nicht verkehrt, wenn die MQTT-Kommandos dazu bekannt wären, dann kann man es ggf. auch einfach in comment/das Wiki, ... übernehmen oä..
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 16 Januar 2022, 08:50:37
Aktuelle Beobachtungen beim Einsatz von ShellyPlus1PM:

... Template shellyPlus_1pm
    ... vorhandenes MQTT2-Device komplett gelöscht
    ... Anwendung von Version 20220114 bzw. eigentlich 20220115 wegen integriertem shellyPlus_1-Template
    ... funktioniert grundsätzlich wie vorgesehen - soweit getestet
    ...
    ... nachdem ich über FHEM geschaltet hatte, fiel mir im Attribut readingList neben "fhem2shelly/rpc:.* {}" auch "shellies/testSwitch2/rpc:.* { json2nameValue($EVENT) }" auf
        ... folglich könnte/sollte noch "$\DEVICETOPIC/rpc:.* {}" unterstützt werden
    ... Attribut devStateIcon habe ich bzgl. aenergy_total von 1 auf 3 Nachkommastellen erweitert
        ... sonst sieht man sehr lange Zeit nur 0.0 - hängt halt nur ein Klein(st)verbraucher dran

... low-power-mode
    ... ein möglicher Eintrag für setList wäre
        x_eco:true,false $\DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
    ... als Reaktion wird u.a. das sys-Subtopic generiert und teilt mit, dass ein reboot notwendig ist
        ... entspricht dem Attribut sys_restart_required
        ... sollte man (vielleicht sogar generell) beachten und dementsprechend im Attribut devStateIcon integrieren
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Januar 2022, 09:04:06
Anmerkungen (ist immer schwierig, wenn man die Interaktion mit dem Device nicht hat):

Zitat von: OdfFhem am 16 Januar 2022, 08:50:37
    ... nachdem ich über FHEM geschaltet hatte, fiel mir im Attribut readingList neben "fhem2shelly/rpc:.* {}" auch "shellies/testSwitch2/rpc:.* { json2nameValue($EVENT) }" auf
...stellt sich die Frage, ob das nicht eine prinzipielle Änderung in 0.9.2 in Richtung auf das hin ist, was bei 4er schon der Fall war: automatische Updates, ohne dass man den "generic update" aktivieren muss. Anders gesagt: ich vermute, dass man eigentlich eher den bisher genutzten Topic stillegen sollte und nur noch diesen rpc hier verwenden? (Code analog 4-er, erste Kanal)

Zitat
    ... Attribut devStateIcon habe ich bzgl. aenergy_total von 1 auf 3 Nachkommastellen erweitert
        ... sonst sieht man sehr lange Zeit nur 0.0 - hängt halt nur ein Klein(st)verbraucher dran
...was auch immer ein für alle sinnvoller Wert sein mag wird eingebaut. Hatte das aus den alten Shelly übertragen (?).

Zitat
... low-power-mode
    ... ein möglicher Eintrag für setList wäre
        x_eco:true,false $\DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
    ... als Reaktion wird u.a. das sys-Subtopic generiert und teilt mit, dass ein reboot notwendig ist
        ... entspricht dem Attribut sys_restart_required
        ... sollte man (vielleicht sogar generell) beachten und dementsprechend im Attribut devStateIcon integrieren
Stellt sich die Frage, ob man die reboot-Anweisung nicht generell hinterherschieben sollte? Müßt man halt dann in Perl notieren, aber tragisch wäre das nicht, jedenfalls einfacher, als devStateIcon anzupassen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 16 Januar 2022, 09:47:11
Zitat von: Beta-User am 16 Januar 2022, 09:04:06
...stellt sich die Frage, ob das nicht eine prinzipielle Änderung in 0.9.2 in Richtung auf das hin ist, was bei 4er schon der Fall war: automatische Updates, ohne dass man den "generic update" aktivieren muss. Anders gesagt: ich vermute, dass man eigentlich eher den bisher genutzten Topic stillegen sollte und nur noch diesen rpc hier verwenden? (Code analog 4-er, erste Kanal)
Hat definitiv nichts mit der Firmware-Änderung zu tun. Ich hatte jetzt noch einmal genauer geschaut und hängt wohl mit den gepflegten MQTT-Parametern zusammen. Von Anfang an (vor ca. 2 Monaten) hatte mein Attribut devicetopic schon den Wert "shellies/testSwitch2"; auch in meiner ersten readingList stand schon besagtes rpc-Topic.

Zitat von: Beta-User am 16 Januar 2022, 09:04:06
Stellt sich die Frage, ob man die reboot-Anweisung nicht generell hinterherschieben sollte? Müßt man halt dann in Perl notieren, aber tragisch wäre das nicht, jedenfalls einfacher, als devStateIcon anzupassen...
Ich überlege gerade, wie hinterschieben funktionieren könnte ... denn die eigentliche Aktion muss ja definitiv erst einmal abgeschlossen sein ... also wäre der offensichtlichste Weg, dass man auf die Änderung von Reading sys_restart_required reagiert ... notify oder so ähnlich oder ??? ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 16 Januar 2022, 09:52:35
Hm, was den reboot angeht, müßte einfach kurz warten und dann den Befehl "ins blaue" hinterherschieben eigentlich ok sein. Das Problem ist nur, dass man das IODev ermitteln muss, um sowas abzuschießen oder einen eigenen (Freitext-) setter haben muss, um den Konfigurationskommand loszuwerden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 16 Januar 2022, 10:35:28
Das "blaue" scheint mir nicht so gut kontrollierbar, daher habe ich einfach mal devStateIcon angepasst ...

{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 $cons = ReadingsNum($name,'apower',0); my $total = round(ReadingsNum($name,'aenergy_total',0)/1000,3); my $temp = ReadingsVal($name,'temperature','-100'); my $ip = ReadingsVal($name,'ip','none'); my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':''; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Verbrauch: $cons W / Total: $total kwh / Temp: $temp °C</div>)}

Besteht aus Änderungen an 2 Stellen:

my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';

$reb


Ausprobiert und hat funktioniert ... erfordert aber natürlich manuelles Eingreifen vom Anwender, das wäre der Haken ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: smoudo am 16 Januar 2022, 21:58:11
Das Reading new_fw fehlt bei mir. Ich bekomme auch nirgends die aktuelle Fw Version angezeigt. Nur die neu verfügbare. Deshalb bleibt mein kreis grün und ändert nicht auf gelb.
Hab gerade gesehen ihr habt den Check komplett rausgenommen. Gibts da einen Lösungsansatz?
Gerät: Plus_1pm & Plus_1

Viele Grüße

Matze
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 17 Januar 2022, 10:56:24
Zitat von: smoudo am 16 Januar 2022, 21:58:11
Hab gerade gesehen ihr habt den Check komplett rausgenommen. Gibts da einen Lösungsansatz?
Bisher eher nicht. Es gibt halt zwei Readings, in denen steht, ob es neue (beta-)firmware gibt. Theoretisch könnte man die auswerten, aber das mit den updates ist m.E. eigentlich sowieso eher ein Problem des Anwenders, weniger des attrTemplate.

Werde erst mal die low-power-Sache (bei plus 1/1pm) einbauen (mit der devStateIcon-Lösung, da man wohl davon ausgehen darf, dass der User sich mit dem Teil beschäftigt hat, bevor er mit solchen Kommandos rumkaspert und daher auch wahrnehmen müßte, dass er einen reboot anschubsen muss).
Was die Topics angeht:

Habe den Verdacht, dass der weitere rpc-Topic (den ich erst mit was anderem vermischt hatte) von einem Tastendruck/einer lokalen Schaltung (via Web-Interface?) kommt? Wenn Tastendruck, könnte man daraus ggf. was in Richtung "manual" oder button-Event basteln. Allerdings sind diese "direkten rpc"-Topics anscheinend hochgradig "volatil" - also v.a. vom "Wunsch des Users" abhängig. Sind mir hochgradig suspekt...

Dann ist mir noch ein ".*/status/cloud:.*"-Topic über den Weg gelaufen - vorsorglich werde ich den auch erst mal "erden"...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: jkriegl am 17 Januar 2022, 18:00:06
Bin mir unsicher, ob ich hier richtig bin.
Shelly1 (switch) über MQTT2 angebunden, alles funktioniert.
Ein "set shelly1 toggle" benötigt einen weiteren Parameter, warum? bzw. was soll da rein?
Ein "set shelly1 toggle <leer>" schaltet immer ein, ist also "set shelly1 on"
Internals:
   CID        shelly1_483FDAA1FCC2
   DEF        shelly1_483FDAA1FCC2
   DEVICETOPIC shelly1_2
   FUUID      6172ccec-f33f-9f96-0fb4-4d25655d457cbda2
   IODev      MQTT2_Server
   LASTInputDev MQTT2_Server
   MQTT2_Server_CONN MQTT2_Server_192.168.178.51_25192
   MQTT2_Server_MSGCNT 115570
   MQTT2_Server_TIME 2022-01-17 17:56:29
   MSGCNT     115570
   NAME       shelly1_2
   NR         133
   STATE      17 17:48
on
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2022-01-13 16:45:22   event           
     2022-01-13 16:45:22   event_cnt       2
     2022-01-13 16:45:22   fw_ver          20211109-124958/v1.11.7-g682a0db
     2021-12-28 16:44:28   has_update      false
     2022-01-13 16:45:22   id              shelly1-483FDAA1FCC2
     2022-01-17 17:56:23   input           0
     2022-01-13 16:45:22   ip              192.168.178.51
     2022-01-13 16:45:22   mac             483FDAA1FCC2
     2022-01-13 16:45:22   model           SHSW-1
     2022-01-13 16:45:22   new_fw          false
     2022-01-13 16:45:22   online          true
     2022-01-17 17:56:29   relay           on
     2022-01-17 17:48:14   seit            17 17:48
     2022-01-17 17:56:29   state           on
Attributes:
   alias      Küche
   event-on-change-reading .*
   readingList shelly1_483FDAA1FCC2:shellies/shelly1-483FDAA1FCC2/online:.* online
shelly1_483FDAA1FCC2:shellies/shelly1-483FDAA1FCC2/announce:.* { json2nameValue($EVENT) }
shelly1_483FDAA1FCC2:shellies/shelly1-483FDAA1FCC2/relay/0:.* relay
shelly1_483FDAA1FCC2:shellies/shelly1-483FDAA1FCC2/relay/0:.* state
shelly1_483FDAA1FCC2:shellies/shelly1-483FDAA1FCC2/input/0:.* input
shelly1_483FDAA1FCC2:shellies/shelly1-483FDAA1FCC2/input_event/0:.* { json2nameValue($EVENT) }
shelly1_483FDAA1FCC2:shellies/shelly1-483FDAA1FCC2/info:.* {}
shelly1_483FDAA1FCC2:shellies/shelly1-483FDAA1FCC2/longpush/0:.* longpush_0
shelly1_483FDAA1FCC2:shellies/announce:.* { json2nameValue($EVENT) }
   room       2.5 Shelly
   setList    off:noArg shellies/shelly1-483FDAA1FCC2/relay/0/command off
on:noArg shellies/shelly1-483FDAA1FCC2/relay/0/command on
x_update:noArg shellies/shelly1-483FDAA1FCC2/command update_fw
x_mqttcom shellies/shelly1-483FDAA1FCC2/command $EVTPART1
   stateFormat seit
relay
   userReadings seit:relay:.* {sprintf("%s", substr(ReadingsTimestamp($NAME,"relay","--?--"),8,8))}
   webCmd     :


Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 18 Januar 2022, 07:54:43
Aktuelle Beobachtungen beim Einsatz von ShellyPlus1PM:

... Firmware version 0.9.3
    ... offiziell verfügbar seit 17.01.2022
    ... die Funkstille wurde als Bug gewertet
        ... "RPC status" meldet sich alle 60 Sekunden
        ... "Generic status" meldet sich alle 60 Sekunden

Aufgefallen ist mir zwischenzeitig, dass es zwei Readings gibt, die "Ärger" machen:
- on-for-timer und off-for-timer
- mit jedem z.B. "set on-for-timer 30" wird der dort abgelegte Wert immer länger.
- Jetzt steht dort aktuell "set set set 30"
- Wählt man auf der Detailseite beim set "on-for-timer" aus, wird dieser Wert als Parameter vorbelegt
- hängt vermutlich mit setStateList zusammen ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 18 Januar 2022, 10:05:29
Zitat von: jkriegl am 17 Januar 2022, 18:00:06
Bin mir unsicher, ob ich hier richtig bin.
Ich mir auch nicht. Du machst ein paar "Kleinigkeiten" anders als das attrTemplate, u.A. schreibst du was in "STATE", das vermutlich von SetExtensions nicht als "on" interpretiert wird.
Bin mir aber nicht sicher, ob es nicht vor ziemlich langer Zeit ein update gab, das das dahingehend korrigiert hat, dass zuerst im Reading "state" schaut und dann erst ersatzweise auf STATE schielt...
Falls das nicht der Fall ist: Das Verhalten könnte man korrigieren, indem man einen eigenen setter für toggle generiert ;) .

Zitat von: OdfFhem am 18 Januar 2022, 07:54:43
... Firmware version 0.9.3
    ... offiziell verfügbar seit 17.01.2022
    ... die Funkstille wurde als Bug gewertet
        ... "RPC status" meldet sich alle 60 Sekunden
        ... "Generic status" meldet sich alle 60 Sekunden
Bedeutet: "Generic status update" braucht es nicht mehr?
Muss dann die Auswertung für rpc-status geändert werden?

Zitat
- on-for-timer und off-for-timer
[...]
- hängt vermutlich mit setStateList zusammen ...
Sehe ich auch so, vermutlich sollte man "on-for-timer" und "off-for-timer" in setStateList aufnehmen. Kannst du testen?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 18 Januar 2022, 11:13:15
Zitat von: Beta-User am 18 Januar 2022, 10:05:29
Bedeutet: "Generic status update" braucht es nicht mehr?
Generic liefert immer einen bestimmten Pool von Werten an; RPC scheinbar oft nur die, die mit einer Aktion zusammenhängen. Generic für switch liefert z.B. immer die temperature, RPC nur beim Schaltvorgang. Generic scheint also bzgl. solcher Informationen "wertvoller" ...

Ich hatte bei mir jetzt mal versuchsweise den RPC-Schalter auf NO gestellt ... vermissen tue ich auf den ersten Blick nichts ... die IP hatte ich aber schon, die Information würde dann beim Neuanwender fehlen oder generell beim Wechsel der IP ... beim jetzigen Firmware-Stand schwierig - wäre sys doch informativer, dann ...

Zitat von: Beta-User am 18 Januar 2022, 10:05:29
Muss dann die Auswertung für rpc-status geändert werden?
Ich glaube nicht ...

Zitat von: Beta-User am 18 Januar 2022, 10:05:29
Sehe ich auch so, vermutlich sollte man "on-for-timer" und "off-for-timer" in setStateList aufnehmen. Kannst du testen?

Ja, setStateList erweitert (s.u.) und die beiden Readings gelöscht. Dann getestet ... die beiden Readings kamen nicht wieder ... state wurde ordnungsgemäß gefüllt ... Vorbelegung für die beiden Aktionen war leer

on off toggle on-for-timer off-for-timer
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 18 Januar 2022, 11:29:52
...also wirklich eine "Banane"...

Na ja, setStateList werde ich dann bei der nächsten Gelegenheit ergänzen, über den Wert der Temperatur fange ich keine Diskussion an, und warte ansonsten dann mal auf Vorschläge, wenn die nächste Iteration der Firmware kam bzw. wenn sonst noch was verbessert werden soll ::) ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 02 März 2022, 13:54:13
Hallo Zusammen,

habe jetzt meinen Shelly Plus 1 über MQTT angebunden, scheint auf den ersten Blick auch alles zu klappen.

wäre es möglich den Button Type (in_mode) mit auszulesen / Schaltbar zu machen? Damit man die Möglichkeit hat, den angeschlossenen Schalter "tot" zu stellen?
zum auslesen habe
<shellyip>/rpc/Switch.GetConfig?id=0
gefunden
zum schalten bestenfalls

{
  "jsonrpc": "2.0",
  "id": 1,
  "src": "user_1",
  "method": "Switch.SetConfig",
  "params": {
    "id": 0,
    "in_mode": "detached",
  }
}

wobei ich noch nicht zuordnen kann ob man damit was tun kann, kommt aus dem Shelly Forum (https://www.shelly-support.eu/forum/index.php?thread/12249-can-t-change-switch-configuration/)

kombiniert mit noch gar keine Ahnung von MQTT entsteht der Wunsch nach Hilfe ;)

thx schon mal
Jens

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 März 2022, 14:19:05
Grummel... Warum ist es neuerdings Mode geworden, praktisch alle Infos wegzulassen... Ein raw-List von deinem Shelly hätte doch nicht weh getan, oder?

Wenn ich die Bausteinchen von https://shelly-api-docs.shelly.cloud/gen2/Components/FunctionalComponents/Switch/#switchgetconfig-example (curl request) richtig interpretiere, müßte das in der getList zu einer Abfrage führen:
attr DEVICE getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1, "method": "Switch.GetConfig", "params": {"id": 0}}
Vermutlich läuft das in einen timeout, aber es sollte ein Ergebnis kommen, das man dann ggf. via jsonMap auf das richtige Reading (=> kein timeout mehr) umbiegen kann...

Betr. Schalten bitte ich um einen eigenen Versuch, das sollte nicht soooo schwer sein ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 02 März 2022, 14:46:35
öhhh - sorry :D

hatte das raw gespart, weil es noch unverändert war ;)

reading klappt leider (noch) nicht (jetzt mit raw)


defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 alias Jens Ceilinglight
attr MQTT2_shellyplus1_441793a3b110 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');; my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Temp: $temp °C</div>)}
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1, "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplus1_441793a3b110 icon light_ceiling_light@green
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 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) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* {}\
  fhem2shelly/rpc:.* {}\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/input_0:.* { json2nameValue($EVENT) }\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/script_1:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1_441793a3b110 room Jens,MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :

setstate MQTT2_shellyplus1_441793a3b110 on
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 10:12:16 IODev m2s
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 10:13:02 attrTemplateVersion 20220118
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 dst shellyplus1-441793a3b110/events
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:53 id 1
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 ip 192.168.177.47
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 method NotifyEvent
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 online true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 params_events_1_cfg_rev 19
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 params_events_1_component switch:0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 params_events_1_event config_changed
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 params_events_1_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 params_events_1_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 params_events_1_ts 1646228552.32
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:21:27 params_input_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:21:27 params_input_0_state false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:44 params_script_1_id 1
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:44 params_script_1_running false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:40:05 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:40:05 params_switch_0_output true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:40:05 params_switch_0_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_switch_0_temperature_tC 48.16
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_switch_0_temperature_tF 118.69
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 params_sys_available_updates_beta_version 0.10.0-beta5
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:15:58 params_sys_restart_required true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 params_ts 1646228552.32
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_wifi_rssi -51
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:53 running false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:42:32 src shellyplus1-441793a3b110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:40:05 state on
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:40:05 switch_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:40:05 switch_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_available_updates_beta_version 0.10.0-beta5
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_cfg_rev 17
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_fs_free 237568
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_fs_size 458752
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_mac 441793A3B110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_ram_free 178144
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_ram_size 249392
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_time 14:16
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_unixtime 1646226979
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_uptime 9
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:40:05 temperature 49.0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:08 x_reboot set


lg
Jens
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 März 2022, 15:00:02
Hmm, ab jetzt wird es experimentell... (Die Doku zu den 2nd Gen. devices ist m.E. irgendwie noch unausgereift, darüber sind wir auch an anderer Stelle schon gestolpert).

Zum einen kannst du mal versuchen, ob es klappt, wenn du "src":"fhem2shelly" da noch mit reinknödelst (das war bei set-Anweisungen mal das Problem) und/oder die ganzen Leerzeichen rausnimmst (das sollte eigentlich kein Problem machen, aber man weiß es nie).

Zum anderen: Bitte die curl-Variante testen. Prinzipiell scheint es (anders als früher) so zu sein, dass man alle Einstellungen auch per MQTT vornehmen können sollte, aber verifiziert ist das nicht...

(Spätestens) via curl sollte dann auch irgendeine Info kommen, wenn nicht, ist das vorläufig m.E. ein Fall für den Shelly-Support.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 02 März 2022, 15:16:42
hi,

ok muss jetzt eben weg, versuch dann nochmal mein glück ... hab mal in die setList jetzt

x_in_mode:flip:detached $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id": 0: {"in_mode": $EVTPART1}}}

gesetzt und mit set <devicename> x_in_mode detached in der fhem cmd ausgeführt und dadruch ein neues Reading:

x_in_mode  set detached

bekommen <-- WARUM set detached? hab ich beim pasten was übersehen? hab doch garkein zusätzliches set verbaut irgendwo oder? sollte $EVTPART1 nicht detached sein?

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 März 2022, 15:21:25
Zitat von: draddy am 02 März 2022, 15:16:42
WARUM set detached? hab ich beim pasten was übersehen? hab doch garkein zusätzliches set verbaut irgendwo oder? sollte $EVTPART1 nicht detached sein?
$EVTPART1 ist/war "detached", aber weil keine (passende!) Antwort kommt _und_ setStateList vorhanden ist, in der dein setter nicht auftaucht, ist eben am Reading-Wert zu erkennen, dass der Befehl noch "auf der Reise" ist (oder verschollen)...  :) works as designed  ;) .

PS: dein "widget" ist auch nicht optimal, das sollte z.B. so aussehen:
x_in_mode:flip,detached [...]
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 02 März 2022, 19:06:25
hi,

widget hab ich geändert, danke ;)

komme allerdings nicht wirklich weiter, habe in der getList mit und ohne Leerzeichen beide "id": auf 0 .. und was mir sonst so eingefallen wäre ..

wenn ich das curl  get ins linux terminal haue

curl -X POST -d '{"id": 1, "method": "Switch.GetConfig", "params": {"id": 0}}' http://192.168.177.47/rpc

bekomme ich diese ausgabe
{"id":1,"src":"shellyplus1-441793a3b110","result":{"id":0, "name":null,"in_mode":"flip","initial_state":"restore_last", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay": 60.00}}

verfeinern kann man die Ausgabe scheinbar nicht, also müsste das Ergebnis entsprechend verarbeitet werden, das eben "flip" bzw "detached" raus kommt. bekomme in FHEM aber nach wie vor gar nix.

ebenfalls übers terminal klappt der set mit
curl -X POST -d '{"id": 1, "method": "Switch.SetConfig", "params": {"id": 0, "config": {"in_mode": "detached"}}}' http://192.168.177.47/rpc
mit rückmeldung:

{"id":1,"src":"shellyplus1-441793a3b110","result":{"restart_required":false}}

der return bringt also nicht wirklich was ^^

habe dann versuch das wenigstens in die setList zu basteln

x_in_mode:flip,detached $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"config": {"in_mode": $EVTPART1}}}


kann aber nach wie vor durch "set <device> x_in_mode ... " in der fhem cmd den switch nicht zum umstellen bewegen.

hilfe wirklich willkommen ;)

lg
Jens
nochn raw

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 alias Jens Ceilinglight
attr MQTT2_shellyplus1_441793a3b110 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');; my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Temp: $temp °C</div>)}
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 getList in_mode 192.168.177.47/rpc {"id": 1, "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplus1_441793a3b110 icon light_ceiling_light@green
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 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) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* {}\
  fhem2shelly/rpc:.* {}\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/input_0:.* { json2nameValue($EVENT) }\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/script_1:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1_441793a3b110 room Jens,MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}\
  x_in_mode:flip,detached $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"config": {"in_mode": $EVTPART1}}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :

setstate MQTT2_shellyplus1_441793a3b110 on
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 10:12:16 IODev m2s
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 10:13:02 attrTemplateVersion 20220118
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 dst shellyplus1-441793a3b110/events
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 15:22:16 id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 ip 192.168.177.47
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 method NotifyStatus
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 online true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 18:53:34 params_events_1_cfg_rev 32
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 18:53:34 params_events_1_component switch:0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 18:53:34 params_events_1_event config_changed
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 18:53:34 params_events_1_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 18:53:34 params_events_1_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 18:53:34 params_events_1_ts 1646243615.33
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 15:22:16 params_input_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 15:22:16 params_input_0_state false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:44 params_script_1_id 1
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:44 params_script_1_running false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 params_switch_0_output true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 params_switch_0_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_switch_0_temperature_tC 48.16
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_switch_0_temperature_tF 118.69
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 params_sys_available_updates_beta_version 0.10.0-beta5
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:15:58 params_sys_restart_required true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 params_ts 1646244091.04
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_wifi_rssi -51
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:11 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:53 running false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 src shellyplus1-441793a3b110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 state on
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 switch_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 switch_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_available_updates_beta_version 0.10.0-beta5
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_cfg_rev 17
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_fs_free 237568
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_fs_size 458752
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_mac 441793A3B110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_ram_free 178144
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_ram_size 249392
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_time 14:16
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_unixtime 1646226979
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:19 sys_uptime 9
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:30 temperature 48.6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 19:01:23 x_in_mode set flip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 14:16:08 x_reboot set



p.s. hatte auch in die setStateList das x_in_mode aufgenommen, hat aber auch nix geändert
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 00:09:24
ich schon wieder ..

also - switch hab ich hinbekommen ... nur das reading ... keine Ahnung -.-


x_in_mode:flip,detached $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$EVTPART1"}}}


das "Geheimnis" war das $EVTPART1  in " " zu setzen, drauf gekommen bin ich weil ich versucht habe den eco_mode über curl zu schalten, was nicht geklappt hat, weil ich immer "true" geschrieben hab. da es wohl echtes bool ist, erkennt er einen string "true" natürlich nicht als bool true an ...

tipps fürs reading nehme ich weiterhin entgegen ;)

gn8
Jens
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 07:57:35

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 alias Jens Ceilinglight
attr MQTT2_shellyplus1_441793a3b110 devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot':'10px-kreis-gruen';; $onl = FW_makeImage($onl);; \
my $light = ReadingsVal($name,'state','off') eq 'off'?'light_ceiling_off':'light_ceiling@yellow';; $light = FW_makeImage($light);; \
my $lock = ReadingsVal($name,'x_in_mode','set flip') eq 'set flip'?'secur_open@green':'secur_locked@red';; $lock = FW_makeImage($lock);;\
my $ip = ReadingsVal($name,'ip','none');; \
my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq\
(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>\
<a href="/fhem?cmd.dummy=set $name modeToggle&XHR=1">${lock}</a>)}\

attr MQTT2_shellyplus1_441793a3b110 devStateStyle style="text-align:right;;;;"
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 icon light_ceiling_light@green
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 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) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* {}\
  fhem2shelly/rpc:.* {}\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/input_0:.* { json2nameValue($EVENT) }\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/script_1:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1_441793a3b110 room Favs,Jens,MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}\
  x_in_mode:flip,detached $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$EVTPART1"}}}\
modeToggle:noArg {if (ReadingsVal("MQTT2_shellyplus1_441793a3b110", 'x_in_mode', 'set flip' ) eq 'set flip' ) {fhem("set MQTT2_shellyplus1_441793a3b110 x_in_mode detached")}else{fhem("set MQTT2_shellyplus1_441793a3b110 x_in_mode flip")}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :

setstate MQTT2_shellyplus1_441793a3b110 off
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 10:12:16 IODev m2s
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 10:13:02 attrTemplateVersion 20220118
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 dst shellyplus1-441793a3b110/events
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 15:22:16 id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 00:02:01 in_mode set detached
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:20 ip 192.168.177.47
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 method NotifyEvent
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 02:25:23 modeToggle set
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:19 mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:19 online true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 params_events_1_cfg_rev 73
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 params_events_1_component switch:0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 params_events_1_event config_changed
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 params_events_1_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 params_events_1_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 params_events_1_ts 1646290171.94
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 15:22:16 params_input_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 15:22:16 params_input_0_state false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:20 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:44 params_script_1_id 1
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:44 params_script_1_running false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:48:46 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:48:46 params_switch_0_output false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:48:46 params_switch_0_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:20 params_switch_0_temperature_tC 47.57
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:20 params_switch_0_temperature_tF 117.63
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:40:09 params_sys_restart_required true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 params_ts 1646290171.94
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:20 params_wifi_rssi -51
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:20 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:20 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 11:30:53 running false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 src shellyplus1-441793a3b110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:48:46 state off
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:48:46 switch_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:48:46 switch_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_cfg_rev 44
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_fs_free 237568
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_fs_size 458752
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_mac 441793A3B110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_ram_free 179708
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_ram_size 249448
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_time 23:55
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_unixtime 1646261730
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:29 sys_uptime 11
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:48:46 temperature 48.0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:21:39 x_eco set false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 07:49:31 x_in_mode set flip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-02 23:55:16 x_reboot set


moin,

also, habe aufs reading einfach verzichtet, muss halt nach neustart kurz gechecked werden ob der schalter wirklich deaktiviert ist.

da ich irgendwie nicht fähig war das umschalten ins devStateIcon zu bekommen, habe ich kurzerhand noch einen modeToggle dazu gebaut, vermutlich nicht ganz elegant, aber es geht ^^

lg
Jens
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 09:28:18
Moin.

Bin irgendwie unzufrieden... (Liegt zum Teil wohl auch daran, dass ich nicht richtig erklärt zu haben scheine, wie vorzugehen ist :-[ , im Übrigen nervt mich dieses unselige Format, in dem die Daten da in der 2. Gen. kommen.)

Also: Ich gehe davon aus, dass man https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt kennt, dto. den Thread bzgl. des Shelly-plus-attrTemplate und des "4-pm" (2.Gen). Dem scheint nicht so zu sein.

Meine Rückmeldung zu dem "set"-Thema war eigentlich auch nicht so gemeint, dass das geändert werden sollte, das Reading gehört nicht in setStateList.

Der Reihe nach: Was wirklich passiert, sieht man nur, wenn man den MQTT-Verkehr mitliest. Wenn ich dazu helfen soll, brauche ich entsprechende Info, das Gesamtergebnis ist immer schwierig zu interpretieren.

Es gibt auch zwei neue Topics (die letzten Zeilen der rL), die bisher nicht berücksichtigt wurden und "schlecht" ausgepackt (weil über die Einzelreadings nicht zuordenbar). Außerdem könnte es sein, dass die Rückmeldung über den "fhem"-Topic kommt, der verworfen wird (wenn das für den JSON erforderlich ist?).

Würde also vorschlagen, die Flinte nicht vorzeitig ins Korn zu werfen, sondern da nochmal richtig unter das Auto zu liegen (und der Fa. erforderlichenfalls zurückzumelden, dass da noch Verbesserungspotential besteht).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 11:56:53
Moin,

tut mir leid dich unzufrieden zu sehen.

deine Annahme ist gut, es trifft aber auch zu, dass ich dieses Wiki nicht kenne. Hier bin ich mehr "Anwender mit Sonderwünschen" ^^

Thema setStateList - war auch nur ein Versuch im Prozess, darum ist es weg ;)

Das Reading, wie gesagt, kA das übersteigt meine aktuellen Skills ... und für mich funktioniert es auch ohne. Spätestens nach einem doppel Toggle stimmt der State in FHEM und Shelly ja überein. Schlimmsten falls steht der Switch auf detached - FHEM ist nach Neustart nicht sicher, geht von Flip aus sendet ein detached (beim toggle) und es ändert nichts, aber server und device sind sync. damit kann ICH leben.

Ob und wo der Wert für in_mode übertragen wird, kann ich dir nicht sagen, habe die http gets durch probiert und eben nur im besagten Switch.GetConfig den wert auslesen können (Oder halt direkt in der WebUI vom Shelly)

die 2 Readings im rL ... kommt das vom Template oder hats da bei mir was "Verbockt" ? ich habe sie sicher nicht selbst gesetzt  ^^

Womit ich persönlich nicht soo glücklich bin, ist meine if else in der setList - dieser "Notnagel" ist auch ehr aus der Unfähigkeit entstanden, das umschalten ins devStateIcon zu bekommen.

Allgemein, im gegensatz zu vielen anderen, mache ich das hier seit 2 Wochen, ich kann und will in der Zeit nicht alle möglichen Sprachen lernen ^^  Wenn ich im Auto ein anderes Radio will, und bei der Verkabelung Probleme habe frage ich auch jemanden der sich damit auskennt ;)
learning by doing - da bin ich dabei ;)

Wenn du also der Meinung bist, das hier könnte auch für andere von Interesse sein, musst dich wenigstens neben das Auto stellen, und mir sagen was du Wissen willst :D

für mich liegt ja nur die Reading-Flinte im Korn das set und damit mein Sonderwunsch klappt ja jetzt ;)

Lg
Jens

p.s. nur zur Sicherheit, ich greife hier niemanden an und bin Dankbar für jede Hilfe. Wollte nur zum Ausdruck bringen das ich A) Neuling bei FHEM und B) Anwender, und kein Developer, bin  :D Wiegesagt, zum Autofahren muss man auch kein Mechaniker sein ^^
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 12:09:09
...das war auch nicht als Schuldzuweisung gedacht, und ich sehe auch, dass du viele Dinge sehr schnell gelernt hast :) . Von daher war ich guter Hoffnung, dass ein paar "Schubser" in die richtige Richtung genügen ;) .

Jetzt halt nochmal etwas vertiefter:
Zitat von: draddy am 03 März 2022, 11:56:53
und mir sagen was du Wissen willst :D
Ging scheinbar etwas unter: Den MQTT-Verkehr, wie er insbesondere beim Umschalten des mode entsteht sowie bei der Abfrage. Das kann man auf vielerlei Weisen machen, aus alter Gewohnheit verwende ich mosquitto_sub.

Zitatich habe sie sicher nicht selbst gesetzt
Davon war ich ausgegangen, ich will nun eben wissen, was über diese Topics (aus welchem Anlass) kommt (s.o.).

Fyi: die meisten attrTemplate sind dadurch entstanden, dass ich ein User hingesetzt hat, und entweder (überwiegend) selbständig was ausgetüftelt hat, oder eben "doofe Fragen" beantwortet hat (und es zu einem gewissen Grad aushalten musste, wenn "jemand" unzufrieden war und meinte, das ginge doch bestimmt besser...). Anders gesagt: ich stehe bereits seit geraumer Zeit auch neben deinem Auto :P . (Weiß aber auch nicht alles und irre mich hin und wieder auch gewaltig...)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 13:48:28
irren ist menschlich aber Menschen nicht Irre oder wie war das xD

ok, das mosquitto_sub kann man auch innerhalb von fhem irgendwie reinsetzen das es mit snifft zur diagnose?

Mein Bruder hat mir MQTT client für Android vorhin Vorgeschlagen (nachdem ich  auth für den Server aktiviert hab) bin aber noch nicht dazu gekommen mir das anzuschauen. Könnte man damit auch was?

Wiegesagt, bin meist für Schandtaten bereit ^^

gehe ich dann recht in der Annahme, das diese 2 readings in der  rL nicht von Template kommen, sondern ich sie mir irgendwie "eingehandelt" habe?
Das 2. davon mit "Script" könnte ich mir bestenfalls so erklären, dass ich ein script auf dem shelly angelegt habe, um zu versuchen ob ich damit leichter meine funktion hin bekomme, habe das aber schnell verworfen und wieder gelöscht.
das andere,  keine Ahnung, kann sich das selbst gesetzt haben z.B. durch diesen readings Versuch oder weil ich mal auf add webhock geklickt habe, aber keins angelegt hab? kanns nicht sagen :P

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 14:02:04
Zitat von: draddy am 03 März 2022, 13:48:28
ok, das mosquitto_sub kann man auch innerhalb von fhem irgendwie reinsetzen das es mit snifft zur diagnose?
Es ist ein Kommandozeilen-Tool für die Linux-Konsole. Damit kann man prinzipiell auch einen MQTT2_SERVER "abhören". Aber eben "von außen".
"Von innen" ginge z.B. mit der Aktivierung von rawEvents im MQTT2-IO, wobei das zunächst mal nur den eingehenden Verkehr auf den Event-Monitor bringt, und daher per se erst mal nicht so umfassend wäre...

Zitat
MQTT client für Android [...]. Könnte man damit auch was?
Vermutlich geht es auch damit, aber ich kenne nicht alle Tools dieser Welt ;D . Welches Tool jemand gerne verwenden will, ist mir prinzipiell egal, solange die Infos kommen :P . (EDIT: ...in Textform kommen... screenshots einer App werde ich mir nicht ansehen!)

Zitatgehe ich dann recht in der Annahme, das diese 2 readings in der  rL nicht von Template kommen, sondern ich sie mir irgendwie "eingehandelt" habe?
Ausdrücklich nochmal: JA, die wurden automatisch außerhalb des attrTemplate erstellt, weil irgendwas vom ESP her gesendet wurde, aus welchem Grund auch immer.

Zitat
kanns nicht sagen :P
Ich auch nicht, würde aber in solchen Fällen dazu neigen, einen Werksreset durchzuführen (und auch die beiden Zeilen aus der rL zu löschen + alle Readings des Devices). Sonst kann es sein, dass wir Phantome jagen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 14:24:35
hab mal versucht mit der android app, aber, kA kann zwar toll "hallo" oder son blödsinn an meinen m2s senden - aber bin zu blöde irgendwas vom shelly zu bekommen ... xD


mein fhem läuft im docker - d.h. im terminal einfach apt-get install mosquitto_sub ?

bzg. reset:

shelly einfach auf werkseinstellungen, und das device in fhem löschen? muss ja dann im neuen nur meine 2 zeilen ergänzen und das devStateIcon austauschen oder? ^^

warum keine screenshots? wollte nach WA nummer fragen damit ich dir zusätzlich sprachnachrichten schicken kann :D /ironie off
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 14:34:05
Zitat von: draddy am 03 März 2022, 14:24:35
hab mal versucht mit der android app, aber, kA kann zwar toll "hallo" oder son blödsinn an meinen m2s senden - aber bin zu blöde irgendwas vom shelly zu bekommen ... xD
;D ...wird wohl Zeit, "was gscheids" zu benutzen :P 8) ;D

Zitat
mein fhem läuft im docker - d.h. im terminal einfach apt-get install mosquitto_sub ?
Bei docker bin ich froh, dass ich es nicht mehr benutzen muss - dafür kenne ich mich zu wenig aus... Auf einem debian-Derivat sollte das in etwa so funktionieren, wobei vermutlich sudo erforderlich ist und "apt-get" auch "old-fashionned" klingt.

Zitat
shelly einfach auf werkseinstellungen, und das device in fhem löschen? muss ja dann im neuen nur meine 2 zeilen ergänzen und das devStateIcon austauschen oder? ^^
Device löschen ist eine gute Idee, irgendwas dran rumzuschrauben erst mal eher nicht (grummel verheb)... (Wegspeichern des RAW kann aber nicht schaden, falls wir nicht eine bessere Lösung finden).

Zitat
warum keine screenshots? wollte nach WA nummer fragen damit ich dir zusätzlich sprachnachrichten schicken kann :D /ironie off
Bilder per MQTT zu versenden ist uncool und führt beim Testen erfahrungsgemäß nicht zum gewünschten Erfolg, und bei Audio ist es nur erträglich, wenn man es wegen RHASSPY auf dem MQTT-Weg machen muss... :P
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 15:21:18
reset done:

raw nach reset:

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 readingList shellyplus1_441793a3b110:shellyplus1-441793a3b110/online:.* online\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/mqtt:.* { json2nameValue($EVENT) }\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/events/rpc:.* { json2nameValue($EVENT) }\
shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/sys:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1_441793a3b110 room MQTT2_DEVICE

setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 IODev m2s
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 cfg_rev 5
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 dst shellyplus1-441793a3b110/events
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 fs_free 237568
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 fs_size 458752
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 mac 441793A3B110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 method NotifyStatus
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 online true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 params_switch_0_temperature_tC 49.69
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 params_switch_0_temperature_tF 121.44
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 params_ts 1646316512.55
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 params_wifi_rssi -52
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 params_wifi_sta_ip 192.168.177.47
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 ram_free 180008
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 ram_size 249444
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 src shellyplus1-441793a3b110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 time 15:08
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 unixtime 1646316512
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:32 uptime 14


raw nach Template wahl:

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 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');; my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Temp: $temp °C</div>)}
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 icon message_socket
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 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) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* {}\
  fhem2shelly/rpc:.* {}
attr MQTT2_shellyplus1_441793a3b110 room MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :

setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 IODev m2s
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:01 attrTemplateVersion 20220118
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 dst shellyplus1-441793a3b110/events
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 ip 192.168.177.47
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 method NotifyStatus
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 online true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 params_switch_0_temperature_tC 49.40
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 params_switch_0_temperature_tF 120.93
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 params_ts 1646316676.55
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 params_wifi_rssi -50
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:05 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 src shellyplus1-441793a3b110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_cfg_rev 5
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_fs_free 237568
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_fs_size 458752
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_mac 441793A3B110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_ram_free 179700
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_ram_size 249452
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_time 15:11
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_unixtime 1646316676
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:15 sys_uptime 11
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:01 x_reboot set


ich halte mich mit anpassungen zurück *mit klebeband im mund die hände zusammenbind* :D
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 15:43:49
Hmm, irgendwie muss ich mir das mit der jsonMap nochmal ansehen, diese params.*-Geschichten sind vermutlich dann eher so zu lösen wie im 4-er (mind: params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0).

Zum eigentlichen: Jetzt mal entweder die setList ergänzen mit
in_mode:flip,detached $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$EVTPART1"}}}(das darf ruhig so heißen, wie das Reading dann mal benannt werden soll).
Vielleicht im ersten Schritt das mit "src" weglassen und schauen, ob es so funktioniert.

oder: ein publish über den m2s absetzen geht auch:
set m2s publish shellyplus1-441793a3b110/rpc <json-blob hier rein>

Dabei den MQTT-Verkehr abhören (siehe "man mosquitto_sub" auf der Linux-Konsole, debug einschalten, damit man die Topics mit sieht; das Ganze vielleicht erst mal mit Schaltbefehlen ein/aus üben).

Aus der Linux-Konsole kann man auch Kopieren, aber mit strg+shift+c statt strg+c (zumindest unter meinem Linux-Rechner geht das so).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 16:05:56
also hab mosquitto_sub gestartet mit

mosquitto_sub -u <user> -P <password> -v -h <hostip> -t '#'


hoffe das passt erstmal!

"src" weglassen meint also so?

in_mode:flip,detached $DEVICETOPIC/rpc {"id":1,"method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$EVTPART1"}}}



ich versuche ... *hang on* ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 16:11:42
Ja, wobei das mit "anonymen Anweisungen" vermutlich nicht geht. Allerdings sollte es beim Abfragen klappen, das wäre "getList" gewesen:getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1, "method": "Switch.GetConfig", "params": {"id": 0}}

Falls es mit '#' nicht will: '+/#' sollte zumindest beim publish aus FHEM heraus irgendwas liefern.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 16:13:07
soo, ohne "src" tut sich am shelly nix

reading im m_sub

shellyplus1-441793a3b110/rpc {"id":1,"method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "detached"}}}


mit ursprünglichen befehl; reading in m_sub

shellyplus1-441793a3b110/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "detached"}}}
fhem2shelly/rpc {"id":1,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"restart_required":false}}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyEvent","params":{"ts":1646320194.72,"events":[{"component":"switch:0","id":0,"event":"config_changed","restart_required":false,"ts":1646320194.72,"cfg_rev":8}]}}


hab mal am shelly selbst nen switch gemacht ... von flip auf detached und zurück auf flip

shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyEvent","params":{"ts":1646320661.11,"events":[{"component":"switch:0","id":0,"event":"config_changed","restart_required":false,"ts":1646320661.11,"cfg_rev":9}]}}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyEvent","params":{"ts":1646320676.10,"events":[{"component":"switch:0","id":0,"event":"config_changed","restart_required":false,"ts":1646320676.10,"cfg_rev":10}]}}



p.s. linux term läuft über putty ... da brauch ich nur markieren und hab es im zwischenspeicher ;)

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 16:25:45
 :) Jetzt wird es heller.
(Details spare ich mir erst mal)

Funktioniert das mit "GetConfig"? Dann könnte man per userReadings auf das "config_changed" reagieren und den gesetzten Wert abholen...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 16:30:01
hast ja gesagt, screenshots sind genau deins gell! xD


also hab getList gesetzt

shellyplus1-441793a3b110/rpc {"id": 1, "method": "Switch.GetConfig", "params": {"id": 0}}


mehr passiert nicht und fhem meldet eben timeout (siehe screenshot)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 16:36:25
!

shellyplus1-441793a3b110/rpc {"id": 1, "src":"fhem2shelly", "method": "Switch.GetConfig", "params": {"id": 0}}
fhem2shelly/rpc {"id":1,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"id":0, "name":null,"in_mode":"flip","initial_state":"restore_last", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay": 60.00}}


hab geblickt was du gestern meintest mit "src" rein knoddeln - fhem webUI gibt immer noch timeout, ABER reading kommt wenigstens im m_sub timeout denke ich, kommt davon das fhem per default mit dem json nix anfängt?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 16:43:50
...noch heller...

Über den timeout kannst du dich noch lange beklagen, das fixen wir ggf. zum Schluss, bis dahin ist das (wie bereits erwähnt) völlig normal ;D !

Dann versuchen wir mal, ihm eine andere src unterzuschieben:shellyplus1-441793a3b110/rpc {"id": 1,"src":"shellyplus1-441793a3b110", "method": "Switch.GetConfig", "params": {"id": 0}}
Das hat den Hintergrund: Schaltanweisungen wollen wir nicht auf dem "habe die Anweisung erhalten"-Weg auswerten, sondern die "es wurde geschaltet"-Info verwenden, die zusätzlich da ist. Daher wird der "fhem"-Topic ins digitale Nirvana geschickt. Da landen aber grade auch die Infos aus der Anfrage... Falls er die "eigene" ID nicht will: "request2shelly"
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 16:52:59
getList:

in_mode:noArg in_mode shellyplus1-441793a3b110/rpc {"id": 1,"src":"shellyplus1-441793a3b110", "method": "Switch.GetConfig", "params": {"id": 0}}


m_sub

shellyplus1-441793a3b110/rpc {"id": 1,"src":"shellyplus1-441793a3b110", "method": "Switch.GetConfig", "params": {"id": 0}}
shellyplus1-441793a3b110/rpc {"id":1,"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110","result":{"id":0, "name":null,"in_mode":"flip","initial_state":"restore_last", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay": 60.00}}


und der obligatorische halt ^^
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 17:06:35
Jo, timeout, aber neue Readings, oder...?
Sowas wie "result_in_mode" ;)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 17:11:12
öh öh ehm, öh,  nein?

also, man sieht am m_sub das er über den topic namen angefragt hat ... aber readings habe ich sonst keine erhalten

hier ne raw

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 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');; my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Temp: $temp °C</div>)}
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 getList in_mode:noArg in_mode shellyplus1-441793a3b110/rpc {"id": 1,"src":"shellyplus1-441793a3b110", "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplus1_441793a3b110 icon message_socket
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 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) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* {}\
  fhem2shelly/rpc:.* {}
attr MQTT2_shellyplus1_441793a3b110 room MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}\
  in_mode:flip,detached $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$EVTPART1"}}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :

setstate MQTT2_shellyplus1_441793a3b110 off
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 IODev m2s
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:01 attrTemplateVersion 20220118
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 dst shellyplus1-441793a3b110/events
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:09:53 in_mode set detached
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 ip 192.168.177.47
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 method NotifyEvent
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 online true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 params_events_1_cfg_rev 11
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 params_events_1_component switch:0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 params_events_1_event config_changed
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 params_events_1_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 params_events_1_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 params_events_1_ts 1646320685.66
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:58:39 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:58:39 params_switch_0_output false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:58:39 params_switch_0_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_switch_0_temperature_tC 48.84
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_switch_0_temperature_tF 119.91
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 params_ts 1646320685.66
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_wifi_rssi -53
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 16:18:04 src shellyplus1-441793a3b110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:58:39 state off
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:58:39 switch_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:58:39 switch_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_cfg_rev 5
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_fs_free 237568
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_fs_size 458752
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_mac 441793A3B110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_ram_free 178940
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_ram_size 249488
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_time 15:46
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_unixtime 1646318812
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_uptime 11
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:58:39 temperature 49.6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:01 x_reboot set
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 17:13:58
 :-[ ... da hatte ich übersehen, dass dieser Topic ja auch "beerdigt" wird. Bitte mit dem "request"-src das ganze nochmal. Dann sollte ein neuer Eintrag in der rL erfolgen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 17:21:50
nochmal fanta4
solangs beiden gefällt und nicht dem einen nur zeit raubt ... :P


hoffe habs richtig gemacht
getList

in_mode:noArg in_mode shellyplus1-441793a3b110/rpc {"id": 1,"src":"request2shelly", "method": "Switch.GetConfig", "params": {"id": 0}}


m_sub

shellyplus1-441793a3b110/rpc {"id": 1,"src":"request2shelly", "method": "Switch.GetConfig", "params": {"id": 0}}
request2shelly/rpc {"id":1,"src":"shellyplus1-441793a3b110","dst":"request2shelly","result":{"id":0, "name":null,"in_mode":"flip","initial_state":"restore_last", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay": 60.00}}


readingList neu:

shellyplus1_441793a3b110:request2shelly/rpc:.* { json2nameValue($EVENT) }



neue readings

result_auto_off false 2022-03-03 17:16:41
result_auto_off_delay 60.00 2022-03-03 17:16:41
result_auto_on false 2022-03-03 17:16:41
result_auto_on_delay 60.00 2022-03-03 17:16:41
result_id 0 2022-03-03 17:16:41
result_in_mode flip 2022-03-03 17:16:41
result_initial_state restore_last 2022-03-03 17:16:41
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 17:29:50
 :)

Damit müßte dann (in "attrTemplate-Sprache") in etwa das hinhauen:
attr 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}}\
  off-for-timer $\DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
  in_mode:flip,detached $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$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"}\
  x_eco:true,false $\DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr DEVICE 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) }\
  $\DEVICETOPIC/status/cloud:.* {}\
  $\DEVICETOPIC/rpc:.* {}\
  fhem2shelly/rpc:.* {}\
  request2shelly/rpc:.* json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode') }
attr DEVICE getList in_mode:noArg in_mode $\DEVICETOPIC/rpc {"id": 1,"src":"request2shelly", "method": "Switch.GetConfig", "params": {"id": 0}}
attr DEVICE 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'); my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':''; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Temp: $temp °C</div>)}
attr DEVICE jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 req_result_in_mode:in_mode


Du darfst dir dann noch Gedanken machen, ob/wie du ggf. das automatisierte Abholen des geänderten Werts machen willst :P .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 17:45:51
jetzt nicht gleich übertreiben ^^

ich versuch da grade durch zu steigen ...

also

request2shelly/rpc:.* json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode') }

ist quasi das reading für in_mode ... ja?  und das soll in zukunft nicht mehr alles, sondern "nur" noch in_mode lesen und das läuft NICHT automatisch sonder müsste irgendwie angestossen werden? oO <-- passiert das nicht automatisch? kann man das irgendwie mit event-on-change-reading regeln?

wird die getList überhaupt noch gebraucht?

für mich, viel wichtiger .. was passiert in jsonMap mit

req_result_in_mode:in_mode


und Final (man stellt ja was einem selbst wichtig ist meist als letzte frage ...)
wie bekomm ich jetzt meinen toggle ins devStateIcon ohne wieder meine if / else in die setList zu mauscheln ... und, wenn die wieder da rein muss, wie kann man sie besser / schöner machen xD

und dann noch, DANKE bis hier hin ^^


€dit:

attr DEVICE jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 req_result_in_mode:in_mode

sicher das der so muss? irgendwie schreit mich da copy paste fehler an, aber ich kenn mich ja nicht aus xD
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 18:01:56
...du wirfst da grade ein paar Grundbegriffe reichlich frei durcheinander, und solltest davon ausgehen, dass schon so ziemlich alles seinen Sinn hat :P ...
Zitatist quasi das reading für in_mode ... ja?
Wenn man "quasi" sehr frei interpretieren wollte. Im Ergebnis vielleicht, in der Vorgehensweise ist es die Methode, um (zusammen mit anderen Angaben und dem, was der Shelly konkret hier liefert!) aus einem bestimmten Topic ein bestimmtes Reading rausziehen zu können...

Zitattoggle ins devStateIcon
Ich würde sagen: gar nicht :P .

Würde eher über webCmd gehen in Verbindung mit einem "widget" aus https://wiki.fhem.de/wiki/FHEMWEB/Widgets, das ganze ergänzt mit widgetOverride und (vermutlich) iconSwitch.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 18:28:00
durcheinander hauen kann ich manchmal ganz gut xD

Zitat von: Beta-User am 03 März 2022, 18:01:56
Ich würde sagen: gar nicht :P .

Würde eher über webCmd gehen in Verbindung mit einem ...
da würde ich sagen, meine if else steht, und mit der bekomm ich es schön hübsch ind devStateIcon :D :D :D

persönlich mag ich webCmd nicht, und, mich jetzt noch stunden rumschlagen, wie ich es schaffe, das mir im webCmd EIN icon zum toggeln angezeigt wird, welches sich auch noch ändert, jehnach status ... irgendwie nicht so ^^

und mit meinem if  else fürn toggle, ists halt rap zap im devStateIcon drin
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 03 März 2022, 18:48:13
Trotzdem kannst dir den Status zyklisch holen, für den Fall das mal nicht über Fhem die "Kindersicherung" eingeschaltet wurde (weil dieses Event bekommst bisher nicht mit), auch wenn das nicht unbedingt brauchst wie in dem anderen Thread erwähnt hast, im MQTT2_DEVICE ist das halt einfach umzusetzen mit peridicCmd.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 März 2022, 19:01:43
Stichworte: fhem-sleep und qq für den setter...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 19:11:15
hi TomLee
ok, scheint wohl zu klappen
periodicCmd in_mode:1

werds nur nicht jede minute machen, das war jetzt zum testen. Danke ;)

@Beta kopf zu für heute, für dich, hoffentlich, ne Fingerübung gewesen mit dem ein oder anderen Erkenntnis Zuwachs - für mich viel neues zeugs was ich noch versuche zu verstehen xD auch dir nochmal Danke ;)

in eine DOIF bekomm ich meinen toggle auch nicht gescheit rein oder? bzw. ists vermutlich dann egal ob ichs im DOIF oder im setList baue  :o

zur erinnerung, das teil xD

modeToggle:noArg {if (ReadingsVal("MQTT2_shellyplus1_441793a3b110", 'x_in_mode', 'set flip' ) eq 'set flip' ) {fhem("set MQTT2_shellyplus1_441793a3b110 x_in_mode detached")}else{fhem("set MQTT2_shellyplus1_441793a3b110 x_in_mode flip")}}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 03 März 2022, 19:48:52
Ich hab keinen Shelly Plus, gelesen hatte ich was von "momentary|toggle|edge|detached", von flip bisher nix  (scheinbar zu wenig gelesen), geht es eventuell einfach ein toggle zu senden statt detached|flip ?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 03 März 2022, 23:12:11
hi
nein direkt toggle senden geht halt nicht, wie man auch hier wieder sieht, ist es all gemein ehr krampfig diesen status extern zu schalten ^^

und, die anderen namen kommen halt durch die neue api von shelly, der plus 1 ist Generation 2, der im anderen Beitrag behandelte 2.5 noch Generation 1. Und da Gen2 leider (noch?!) nicht vom Modul behandelt wird halt mqtt ^^
gen 1      gen 2
toggle = follow
momentary = momentary
edge = flip
detached = detached

und toggle / follow mein bei shelly;
"Follow - Set Shelly device to be "Toggle" switch. Act as a flip switch with one state for "ON" and one state for "OFF"."


ich will aber einfach nur zwischen den von mir verwendeten modi edge|flip und detached "toggeln" können :D


Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 03 März 2022, 23:41:44
Zitat
in eine DOIF bekomm ich meinen toggle auch nicht gescheit rein oder? bzw. ists vermutlich dann egal ob ichs im DOIF oder im setList baue  :o

ich will aber einfach nur zwischen den von mir verwendeten modi edge|flip und detached "toggeln" können :D

Verstehe nicht genau was für ein Problem du mit deiner if/else-Variante in setList hast ? Das klappt doch ?

Die könnte man noch etwas optimieren für setList, das wars aber auch schon.

Hoffe hab keinen Denkfehler, ungetestet:

modeToggle:noArg {ReadingsVal($NAME, 'in_mode', 'flip' ) eq 'flip' ? fhem("set $NAME in_mode detached") : fhem("set $NAME in_mode flip")}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 00:01:58
ja, das ist die frage, also, ob ich ein problem damit haben sollte oder nicht xD
jedenfalls sieht deine if schonmal "hübscher"  aus als meine Urversion von heute früh um 2 ^^

jetzt ist nur noch die sache, das ich echt zu blöde  bin das "get in_mode" auszulösen, nachdem ich diesen umgestellt habe ^^

zu qq finde ich in der ref gar nicht.

denke die idee von beta wäre auch das "get in_mode" kurze zeit nach dem "set in_mode" auszuführen, damit nach dem umschalten auch der richtige wert in fhem steht.

dachte ich könnte mit , oder ; einfach sleep 1 get in_mode anhängen, aber ... falsch gedacht ^^

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 04 März 2022, 00:19:28
Zitatdenke die idee von beta wäre auch das "get in_mode" kurze zeit nach dem "set in_mode" auszuführen, damit nach dem umschalten auch der richtige wert in fhem steht.

Wenn du umschaltest sollte in dem Reading doch auch gleich wieder was zurückkommen, so hab ich es oben zumindest verstanden, da ist kein anschliessendes get nötig. Ist das nicht so ?

Der (periodische) getter ist wie gesagt nur dafür da wenn ausserhalb von FHEM die Kindersicherung eingeschaltet wurde.

Ich hab ehrlich gesagt nicht verstanden wie das mit dem qq und sleep gemeint war.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 00:31:20
genau da ist das Problem ^^

natürlich kommt etwas zurück nach dem set, allerdings ist dies zu nix zu gebrauchen ^^


shellyplus1-441793a3b110/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "flip"}}}
fhem2shelly/rpc {"id":1,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"restart_required":false}}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyEvent","params":{"ts":1646350074.25,"events":[{"component":"switch:0","id":0,"event":"config_changed","restart_required":false,"ts":1646350074.25,"cfg_rev":31}]}}


oben ist das aabsetzen des set in_mode - dann kommt die antwort, die sagt "hier wurde was geändert" aber eben nicht mitteilt was geändert wird, darum ja der ganze käse mit dem extra getter ;)

aktuell funzt der toggle natürlich auch erst, nachdem der periodische gelaufen ist, oder ich manuel den getter getriggert habe ^^

denke mit qq und|oder sleep wäre es irgendwie möglich das set mit dem get zu verknüpfen, aber sag ja, ich blicks nicht xD
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 04 März 2022, 00:35:31
Zeig mal ein (Raw-) List von deiner jetzigen Definition bitte.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 00:38:11
klar

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 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');; my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Temp: $temp °C</div>)}
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"request2shelly", "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplus1_441793a3b110 icon message_socket
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 req_result_in_mode:in_mode
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 periodicCmd in_mode:5
attr MQTT2_shellyplus1_441793a3b110 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) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* {}\
  fhem2shelly/rpc:.* {}\
  request2shelly/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode') }
attr MQTT2_shellyplus1_441793a3b110 room MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
  in_mode:flip,detached $DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}\
  modeToggle:noArg {ReadingsVal($NAME, 'in_mode', 'flip' ) eq 'flip' ? fhem("set $NAME in_mode detached") : fhem("set $NAME in_mode flip")}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :

setstate MQTT2_shellyplus1_441793a3b110 off
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:08:19 IODev m2s
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:01 attrTemplateVersion 20220118
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 dst shellyplus1-441793a3b110/events
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 17:16:41 id 1
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:37:25 in_mode flip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 ip 192.168.177.47
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 method NotifyEvent
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 online true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 params_events_1_cfg_rev 31
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 params_events_1_component switch:0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 params_events_1_event config_changed
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 params_events_1_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 params_events_1_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 params_events_1_ts 1646350074.25
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 18:46:41 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 18:46:41 params_switch_0_output false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 18:46:41 params_switch_0_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_switch_0_temperature_tC 48.84
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_switch_0_temperature_tF 119.91
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 params_ts 1646350074.25
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_wifi_rssi -53
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:40 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 17:16:41 result_auto_off false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 17:16:41 result_auto_off_delay 60.00
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 17:16:41 result_auto_on false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 17:16:41 result_auto_on_delay 60.00
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 17:16:41 result_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 17:16:41 result_in_mode flip
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 17:16:41 result_initial_state restore_last
setstate MQTT2_shellyplus1_441793a3b110 2022-03-04 00:27:53 src shellyplus1-441793a3b110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 18:46:41 state off
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 18:46:41 switch_id 0
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 18:46:41 switch_source MQTT
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_cfg_rev 5
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_fs_free 237568
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_fs_size 458752
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_mac 441793A3B110
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_ram_free 178940
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_ram_size 249488
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_restart_required false
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_time 15:46
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_unixtime 1646318812
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:46:51 sys_uptime 11
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 18:46:41 temperature 48.6
setstate MQTT2_shellyplus1_441793a3b110 2022-03-03 15:11:01 x_reboot set
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 04 März 2022, 01:03:33
Ok, hab was durcheinander gebracht.

Wie es mit meiner kurzen Variante von if geht komm ich jetzt auch gerade nicht drauf, aber bei der if/else-Variante müsstest eigentlich dem set-Befehl einfach nur das sleep und get Kommando mit Semikolon getrennt anhängen.

Ich mach mir jetzt weiter keinen Kopf mehr heute, weil spätestens um 8 Uhr morgen Früh wird eh wieder alles verworfen und anders gelöst  :P
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 01:10:43
sag sowas doch nicht :D

nein, denke halt wenn müsste das get mit an den set in_mode dran (den grund befehl so zu sagen)

aber vll. gibt beta mir ja noch nen tipp wies geht, ein herz für Anfänger so zusagen  :-* ;D

aber die von dir verschönerte if else fürs toggle wird wohl bleiben und der periodische  auch:D
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 04 März 2022, 01:59:55
Eigentlich sollte es so klappen, einfach nur anhängen:

modeToggle:noArg {ReadingsVal($NAME, 'in_mode', 'flip' ) eq 'flip' ? fhem("set $NAME in_mode detached;sleep 0.5;get $NAME in_mode") : fhem("set $NAME in_mode flip;sleep 0.5;get $NAME in_mode")}
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 08:16:34
moin,

also das klappt wohl, ja. nur die frage warum ich es nicht schaffe das an den eigentlichen in_mode Befehl zu fummeln xD
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 März 2022, 09:59:57
Zumindest das mit dem "sleep" hattet ihr ja (in etwas anderer Form wie gedacht) gefunden, "qq" ist einfach eine perl-Funktion, mit der man "einfacher" formatierten Text mit Quotes erzeugen kann - wenn man in mqtt2.template qq im Zusammenhang mit readingList sucht, gibt es nicht allzuviele Treffer. Es geht einfach darum, "am Ende" einer Perl-Anweisung in setList "topic payload" (vereinfacht) zurückzugeben, und vorher irgendwas anderes zu tun.

Hier mal ein (ungetesteter) Vorschlag, wie man das ohne periodicCmd lösen können sollte (mir gefällt das Pollen überhaupt nicht!), aber trotzdem alles mitbekommt, wenn ein potentiell "unklarer Status" gemeldet wird.

Das ganze ist "attrTemplate-Sprache" (man muss also die "escape"-backslashes für "DEVICE" entfernen), Klammern habe ich nicht gezählt, und wegen der Strichpunkte muss man aufpassen, an welcher Stelle/auf welchem Weg man wie viele setzt:
attr 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}}\
  off-for-timer $\DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
  in_mode:toggle,flip,detached {my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') eq 'flip' ? 'detached':'flip'; qq($\DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$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"}\
  x_eco:true,false $\DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr DEVICE 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) }\
  $\DEVICETOPIC/status/cloud:.* {}\
  $\DEVICETOPIC/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode')\
  fhem2shelly/rpc:.* {}
attr DEVICE getList in_mode:noArg in_mode $\DEVICETOPIC/rpc {"id": 1,"src":"$\DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr DEVICE userReadings get_in_mode:params_events_1_event:.config_changed {fhem("get $NAME in_mode")}


Hier noch ein ungetesteter Versuch, das automatische get mit einem fhem-sleep auch noch in der Zeile unterzubringen:
in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode"); my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') ne 'flip' ? 'flip':'detached'; qq($\DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$EVTPART1"}}}}\


Ergänzender Hinweis: das "get" unter einem "Einheitstopic" abzusetzen war vermutlich keine gute Idee, das hätte bei mehreren zu heilloser Verwirrung geführt. Daher das "Aufbohren" der "Erdleitung"...

Nachtrag noch:
Das mit webCmd war eigentlich als Aufforderung gedacht, das für alle bereitzustellen. Das ganze ist eine Spezialfunktion, die vermutlich einige Leute interessiert, aber nicht alle. Daher hätte ich das gerne aus devStateIcon draußen und "separat abschaltbar". Wäre nett, wenn du den Aufwand treiben würdest, ist glaube ich nicht soooo schwer.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 10:21:51
moin,

ja sleep war mir auch durchaus ein begriff, auch die notwendigkeit war mir soweit klar (das schalten braucht ja nen mement, wenn man dann sofort abfragt kann es passieren noch den alten wert zu bekommen...) zu qq habe ich halt nichts gefunden was mich schlauer / durchblicken lässt ^^

werde mir das ganze anschauen, und auch versuchen deinem wunsch für die allgemeinheit gerecht zu werden, und irgendwie ein webCmd zu basteln dafür ;)

kontaktieren sie uns nicht, wir kontaktieren sie! :P
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 11:53:32
Frage

attr DEVICE getList in_mode:noArg in_mode $\DEVICETOPIC/rpc {"id": 1,"src":"$\DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}

hast du bewusst "src" wieder auf DEVICETOPIC geändert und nicht mehr request2shelly? (habe das erstmal nicht geändert)

setList - kleinere fehler korregiert (eine klammer, und am ende muss auf $var nicht auf $EVTPART1 gesetzt werden, weil er sonst versucht "in_mode" auf toggle zu setzen, was aber follow heissen würde und nicht das ist was wir wollen xD.

in_mode:toggle,flip,detached {my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') eq 'flip' ? 'detached':'flip'; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}


userReadings Funkioniert auch, auch dann wenn z.B: über WebUI vom Shelly umgestellt wird. demnach, sorry tomlee, ist periodic doch geflogen und auch das SetList mit dem auslösen des get habe ich n icht getestet, weil userreading seinen job macht.

webCmd
muss ich mir noch anschauen - werd die ganze zeit vom telefon gestört  ;D



Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 März 2022, 12:15:31
Zitat von: draddy am 04 März 2022, 11:53:32
Frage [...] hast du bewusst "src" wieder auf DEVICETOPIC geändert und nicht mehr request2shelly? (habe das erstmal nicht geändert)
Ja, Begründung s.o.. Die rL muss dazu auch an zwei weiteren Stellen angepaßt werden!

Zitat(eine klammer, und am ende
8) Das mit den kleinen Fehlerchen hat sich als gute Methode bewährt, um "Kunden" zum mitdenken zu animieren... ::)

Zitat
userReadings Funkioniert auch,
Wenn möglich bitte trotzdem die "Verzögerungsvariante" ausprobieren. Hintergrund:
Wer nur von FHEM aus arbeitet, braucht dann das userReading nicht, und es gibt v.a. bei den Modellen mit Energiemessung den Bedarf für weitere userReadings-Einträge => für diese wird alles sehr viel komplizierter...

Ergo: Sowas sollte dann (wie das mit webCmd ggf. auch) im Wiki dokumentiert werden (whodunnit?!? => Freiwillige gesucht!), im attrTemplate selbst würde ich den "inhibit"- setter (so heißt die vergleichbare Funktion im CUL_HM-Sprech) zwar drin lassen, aber eben nicht als besonders hervorgehobes oder wünchenswertes "Standard-Kommando".

Auch das mit dem periodicCmd kann man dokumentieren, allerdings würde ich dazu noch "timestamp-on-change-reading" (und die dafür notwendigen Vorbedingungen) mit aufnehmen.

Alles klar soweit...?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 13:30:41
also readingList und getList habe ich umgebaut auf $DEVICETOPIC ... wenn ich den get manuel ausführe - klappt das auch

was nicht geht, ist der get call beim toggle bzw. flip|detached (was am ende ja das gleiche ist) - also der set wird wohl ausgeführt, aber der get nicht, kommt auch in m_sub nix was darauf hindeuten würde, dass der get ausgeführt wurde)

hier nochmal der in_mode teil der setList

in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode"); my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') ne 'flip' ? 'flip':'detached'; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}




MaaAAHHNN
übertreibs doch nicht mit deinen "fehlerchen" einbauen :P ... nachdem ich den 2. ; hinter sleep 0.2 entfernt habe, wird get getriggert ...   ;)

aber (natürlich?!) bekommt fhem es nicht mit, wenn ich im shelly direkt den in_mode ändere

axo, das userReadings habe ich natürlich rausgeworfen!

hier ein raw dieser version: (und JA, da ist mein devStateIcon ... halt einfach ignorieren :P, aber um dieses gehts ja aktuell nicht^^)

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 alias Jens Ceilinglight
attr MQTT2_shellyplus1_441793a3b110 devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot':'10px-kreis-gruen';; $onl = FW_makeImage($onl);; \
my $light = ReadingsVal($name,'state','off') eq 'off'?'light_ceiling_off':'light_ceiling@yellow';; $light = FW_makeImage($light);; \
my $lock = ReadingsVal($name,'in_mode','flip') eq 'flip'?'secur_open@green':'secur_locked@red';; $lock = FW_makeImage($lock);;\
my $ip = ReadingsVal($name,'ip','none');; \
my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq\
(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>\
<a href="/fhem?cmd.dummy=set $name in_mode toggle&XHR=1">${lock}</a>)}
attr MQTT2_shellyplus1_441793a3b110 devStateStyle style="text-align:right;;;;"
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplus1_441793a3b110 icon light_ceiling_light@green
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 req_result_in_mode:in_mode
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 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) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode') }\
  fhem2shelly/rpc:.* {}\

attr MQTT2_shellyplus1_441793a3b110 room Favs,Jens,MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode");; my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') ne 'flip' ? 'flip':'detached';; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}\
  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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :
den setState part am ende habe ich mal weg gelassen ...


BUG: ist mir gerade aufgefallen:
wenn ich im detached mode bin, und am echten Schalter welcher am Shelly ist, schalte, passiert der lampe nichts, wohl aber ändert sich "state" auf "true" und damit spring die das devStateIcon auf "AN" (weil der state nicht mehr off ist) und bleibt solange, bis ich über FHEM ein / ausschalte ... hier wird also irgendein reading "falsch" an state weiter geleitet

dieses event erhalte ich in m_sub (EIN und AUS schalten)


shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyStatus","params":{"ts":1646396730.00,"input:0":{"id":0,"state":true}}}
shellyplus1-441793a3b110/status/input:0 {"id":0,"state":true}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyStatus","params":{"ts":1646396735.85,"input:0":{"id":0,"state":false}}}
shellyplus1-441793a3b110/status/input:0 {"id":0,"state":false}


denke, das ist bis her nicht aufgefallen, da im "normal" mode ja beim betätigen des schalters, auch irgendwas am Licht passiert und es vermutlich dann sofort wieder überschrieben wird durch den status der lampe ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 13:42:56
quick&dirty


webCmd  in_mode


setzt einfach ein Dropdown Menü mit flip detached toggle und funzt auch - Anzeige (wenn nicht ausgeklappt) war beim kurztest auch immer sauber der Aktuelle Status (also, flip oder detached)

Optik etc. möge bitte jemand machen, welcher webCmd nutzen mag aktuell keinen kopf und lust mich in WidgetOverride etc. rein zu arbeiten, da ich für mich persönlich überall wo ich kann auf webCmd verzichte ^^

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 13:47:37
von mir aus auch mit webCmdLabel

Button Mode

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 März 2022, 13:48:42
Zitat von: draddy am 04 März 2022, 13:42:56
Optik etc. möge bitte jemand machen,
Och komm, lass den monk vollends raus :P ...

Was die Zahl der Strichpunkte angeht: hatte extra geschrieben, dass ich nicht sicher bin ;) .

Zum "bug": Da müßte eigentlich was zusätzliches in der rL aufgetaucht sein. Da bitte die Langform von j2nv() einbauen und einen "input_"-Präfix setzen. Dann sollte Tastendruck und Relay getrennt als Reading zu erkennen sein.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 14:42:46
AACHHTUNG AM BAHNSTEIG xD

ok 1 nachm anderen
tatsache, neuer rL Eintrag (hab wohl vorhin kein F5 gedrückt und hatte das gar nicht gesehen als mir der bug aufgefallen ist ...

shellyplus1_441793a3b110:shellyplus1-441793a3b110/status/input_0:.* { json2nameValue($EVENT) }

aber was ich da jetzt wie wo zu ändern habe? .. shellyplus1..... gegen $$DEVICETOPIC tauschen vermutlich - aber j2n lang form? - den ausdruck von status/switch_0 rein kopieren ?

also sowas?

$DEVICETOPIC/status/input_0:.* { $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT, 'switch_', $JSONMAP) }


von wegen strichpunkte ... ja, aber trotzdem musst ja nicht übertreiben mit deinen fehlerchen :P :P : P

webCmd ... job done! ganz einfach, wer mehr will, feel free - works as designed hat gestern mal jemand gesagt xD
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 14:58:45
andere frage ... kann man die zeile der setList irgendwo "brechen"? ich brauch fast beide Monitore damit ich nicht immer nach links und rechts schieben muss  :o
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 15:03:40

$DEVICETOPIC/status/input_0:.* { $EVENT =~ s/"output":true/"state":"on"/g; $EVENT =~ s/"output":false/"state":"off"/g; json2nameValue($EVENT, 'input_', $JSONMAP) }


also, kein neuer eintrag in rL mehr, wenn detached und schalter wird geschaltet bleibt state icon unverändert.
im flip modus wirds licht an und aus geschaltet und auch das state icon schaltet um.

sollte, so hoffe ich, also passen.

alkutelles raw

defmod MQTT2_shellyplus1_441793a3b110 MQTT2_DEVICE shellyplus1_441793a3b110
attr MQTT2_shellyplus1_441793a3b110 alias Jens Ceilinglight
attr MQTT2_shellyplus1_441793a3b110 devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot':'10px-kreis-gruen';; $onl = FW_makeImage($onl);; \
my $light = ReadingsVal($name,'state','off') eq 'off'?'light_ceiling_off':'light_ceiling@yellow';; $light = FW_makeImage($light);; \
my $lock = ReadingsVal($name,'in_mode','flip') eq 'flip'?'secur_open@green':'secur_locked@red';; $lock = FW_makeImage($lock);;\
my $ip = ReadingsVal($name,'ip','none');; \
my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq\
(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>\
<a href="/fhem?cmd.dummy=set $name in_mode toggle&XHR=1">${lock}</a>)}
attr MQTT2_shellyplus1_441793a3b110 devStateStyle style="text-align:right;;;;"
attr MQTT2_shellyplus1_441793a3b110 devicetopic shellyplus1-441793a3b110
attr MQTT2_shellyplus1_441793a3b110 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplus1_441793a3b110 icon light_ceiling_light@green
attr MQTT2_shellyplus1_441793a3b110 jsonMap switch_state:state switch_temperature_tC:temperature switch_temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 req_result_in_mode:in_mode
attr MQTT2_shellyplus1_441793a3b110 model shellyPlus_1
attr MQTT2_shellyplus1_441793a3b110 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) }\
  $DEVICETOPIC/status/input_0:.* { $EVENT =~ s/"output":true/"state":"on"/g;; $EVENT =~ s/"output":false/"state":"off"/g;; json2nameValue($EVENT, 'input_', $JSONMAP) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode') }\
  fhem2shelly/rpc:.* {}\
\

attr MQTT2_shellyplus1_441793a3b110 room Favs,Jens,MQTT2_DEVICE
attr MQTT2_shellyplus1_441793a3b110 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
  in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode");; my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') ne 'flip' ? 'flip':'detached';; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}\
  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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr MQTT2_shellyplus1_441793a3b110 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplus1_441793a3b110 webCmd :

devStateIcon müsstest halt dein Original wieder rein fummeln :P
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 März 2022, 15:06:02
Zitat von: draddy am 04 März 2022, 14:42:46
webCmd ... job done! ganz einfach, wer mehr will, feel free - works as designed hat gestern mal jemand gesagt xD
..so wird kein echter monk aus dir...

Etwas mehr Ehrgeiz bitte! Du wolltest doch was lernen, oder? (und ich auch, hab das nämlich auch noch nie in der Form genutzt ;) )

Betr. das status-Ding war es gar nicht so kompliziert gemeint:

$DEVICETOPIC/status/input_0:.* { json2nameValue($EVENT, 'input_', $JSONMAP) }

Da es ggf. ja "nur" darum geht, Tastendrücke gesondert auswerten zu können, ist es nicht ganz so wichtig, ob der Event "vollendet" ist, on/off sind v.a. bei schaltbaren Zuständen wichtig. "Blöd" war da ohne den "prefix" nur, dass ausgerechnet "state" als Keyword in dem JSON-Blob enthalten war...
Vermutlich geht deine Version auch "irgendwie", ich habe aber nicht geprüft, ob dann überhaupt ein Taster-Event kommt. Der wäre schon wünschenswert ;) .

Zitat von: draddy am 04 März 2022, 14:58:45
andere frage ... kann man die zeile der setList irgendwo "brechen"?
No. Beste Technik ist rauskopieren, einen "richtigen" Editor benutzen und nach Bearbeitung wieder reinkopieren...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 15:35:20
Zitat von: Beta-User am 04 März 2022, 15:06:02
..so wird kein echter monk aus dir...

Etwas mehr Ehrgeiz bitte! Du wolltest doch was lernen, oder? (und ich auch, hab das nämlich auch noch nie in der Form genutzt ;) )
wer sagt das ich ein Fliesenfugen überspringender, alles berührender aber vor Menschen angsthabender Monk werden will? :P
und über meine Lernkurve der letzten 2 Wochen kann ich mich nicht beklagen, danke für deine Fürsorge  :-*
Zitat
Betr. das status-Ding war es gar nicht so kompliziert gemeint:

$DEVICETOPIC/status/input_0:.* { json2nameValue($EVENT, 'input_', $JSONMAP) }

Da es ggf. ja "nur" darum geht, Tastendrücke gesondert auswerten zu können, ist es nicht ganz so wichtig, ob der Event "vollendet" ist, on/off sind v.a. bei schaltbaren Zuständen wichtig. "Blöd" war da ohne den "prefix" nur, dass ausgerechnet "state" als Keyword in dem JSON-Blob enthalten war...
Vermutlich geht deine Version auch "irgendwie", ich habe aber nicht geprüft, ob dann überhaupt ein Taster-Event kommt. Der wäre schon wünschenswert ;) .
denke das sollte reichen, das wird gesetzt bei tasten druck
input_state  false  2022-03-04 15:18:15
werde aber auf deine version umbauen, wenn da kein Kommentar mehr dazu kommt, passt es ;)
Zitat
No. Beste Technik ist rauskopieren, einen "richtigen" Editor benutzen und nach Bearbeitung wieder reinkopieren...
gibt es ernsthaft leute, die ohne externen editor arbeiten? also für kleinigkeiten, ok, aber allein sowas wie besagte zeile ... im notepad++ z.B. seh ich zumindest schnell ob alle klammern beendet werden etc. pp ... ^^



Template:
d.h. du übernimmst das so ins Template, dass der in_mode schaltbar ist und den aktuellen status kurz checkt mit dem get? (muss ja nicht aktiv raus getragen werden mit schaltern, ist eco mode oder sowas ja auch nicht)

brauchst du in dem zuge noch was von meiner seite?

Wiki Doku:
ehm, öhh? ich muss weg xD ... nein, kann nicht ganz folgen was du da wo genau dokumentieren wolltest? das webCmd ist ja quasi pillepalle, indem moment wo webCmd auf einen multischalter gesetzt wird, bekommst ja diese auswahl, wenn du jetzt ins webCmd einfach x_eco einträgst, sollte auch ein dropdown mit true und false kommen.

jedenfalls nochmal danke, auch an tomlee, auch wenn seine "befürchtung" wohl doch wahr geworden ist.
aber besonders die Zusammenarbeit mit dir beta hat gut geklappt und spass gemacht ;)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 März 2022, 16:25:28
Zitat von: draddy am 04 März 2022, 15:35:20
wer sagt das ich ein Fliesenfugen überspringender, alles berührender aber vor Menschen angsthabender Monk werden will? :P
...für Risiken und Nebenwirkungen von FHEM fragen Sie eine beliebige Person ihres Vertrauens :-* ...

Zitat
gibt es ernsthaft leute, die ohne externen editor arbeiten? also für kleinigkeiten, ok, aber allein sowas wie besagte zeile ... im notepad++ z.B. seh ich zumindest schnell ob alle klammern beendet werden etc. pp ... ^^
Dein Suchwort ist "codemirror" ;) .

Zitat
d.h. du übernimmst das so ins Template, dass der in_mode schaltbar ist und den aktuellen status kurz checkt mit dem get?
Das wäre der Plan.

ZitatWiki Doku:
Na ja, das mit dem automatischen get ist eine Lösung von mehreren, und ich will das auch nicht "überall" einbauen. Prinzipiell ist einiges an den 2. Gen.-Geräten "speziell", und von daher wäre es wahrscheinlich sinnvoll, für u.A. eben sowas in separaten Wiki-Artikel betr. Shelly-2.Gen-@MQTT2 zu packen, damit man künftig nicht gefühlte 10000 Seiten Forumsbeiträge (mit Fehlversuchen usw.) durchforsten muss...

(Ich warte jetzt nur noch darauf, dass hier spätestens morgen jemand mit einem 4-er Shelly 2. Gen. aufschlägt, der wissen will, wie man das im Doppel-Rollladenmodus hinbekommt ::) ...)

Zitat
hat gut geklappt und spass gemacht ;)
Dank zurück!

(Auch der Stil ist hoffentlich so, dass eventuelle Nachleser etwas "Spaß" dabei haben, sich diese m.E. insgesamt nicht ganz trivialen Sachen zu erlesen...)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 16:59:05
Zitat von: Beta-User am 04 März 2022, 16:25:28
...für Risiken und Nebenwirkungen von FHEM fragen Sie eine beliebige Person ihres Vertrauens :-* ...
ich hab doch schon die Packungsbeilage gefuttert  :o
Zitat
Dein Suchwort ist "codemirror" ;) .
muss ich mir, irgendwann, mal anschauen, für meine zwecke reicht seit jahren der notepad++ ... mit dem hab ich seinerzeit schon java gelernt (bin ich froh das ich damit nix mehr am hut hab) für das bissl hoppy coden / scripten reicht der notepad++ mir  ;)


Zitat
Na ja, das mit dem automatischen get ist eine Lösung von mehreren, und ich will das auch nicht "überall" einbauen. Prinzipiell ist einiges an den 2. Gen.-Geräten "speziell", und von daher wäre es wahrscheinlich sinnvoll, für u.A. eben sowas in separaten Wiki-Artikel betr. Shelly-2.Gen-@MQTT2 zu packen, damit man künftig nicht gefühlte 10000 Seiten Forumsbeiträge (mit Fehlversuchen usw.) durchforsten muss...
nun, das get bleibt ja und das periodic ist ja jetzt raus, dies ist ja scheinbar eh mqtt "typisches" Boardmittel in fhem oder?  oder wolltest du das automatische abfragen nach dem setzen von set in_mode wieder rauskanten? das würde ich, aufgrund fehlender  verwertbarer Rückmeldung, halt drin lassen. (meine Meinung)
Gibt es das Gen2 Wiki schon? PM einfach wenn du entschieden hast was drin bleibt und was nicht, dann schauen wir das wir WIKI entsprechend sinnig befüllen mit tipps ;)
Zitat
(Ich warte jetzt nur noch darauf, dass hier spätestens morgen jemand mit einem 4-er Shelly 2. Gen. aufschlägt, der wissen will, wie man das im Doppel-Rollladenmodus hinbekommt ::)
ja, für normales 2er oder 4 relay denke ich ehr problemlos. man muss eben sinnvoll ergänzen alla in_mode_1 ... id:2 .. aber Rollladenmodus bin ich raus, meine Rollos haben noch Seilzug :P
habe halt ausser dem Plus 1 aktuell nur nen 2.5 hier (und eben plugs / bulbs) - und der ist (gsd) Gen1 xD also, Tester vor treten :P


Zitat
(Auch der Stil ist hoffentlich so, dass eventuelle Nachleser etwas "Spaß" dabei haben, sich diese m.E. insgesamt nicht ganz trivialen Sachen zu erlesen...)
ja, bissl show haben wir schon gemacht  :P
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 04 März 2022, 17:18:36
Zitat von: draddy am 04 März 2022, 16:59:05
muss ich mir, irgendwann, mal anschauen, für meine zwecke
Es verbirgt sich kein übermäßig großes Geheimnis hinter dem Schlagwort, aber die Zielrichtung ist eine andere ;) .

Zitat
Gibt es das Gen2 Wiki schon?
Nein. Es gibt einen "Sammel-Wiki"-Artikel für "Praxisbeispiele", in den ich ursprünglich mal "alles mögliche" reingepackt hatte. Da war z.B. auch mal zigbee2mqtt drin, was zwischenzeitlich ausgelagert ist. So ähnlich würde ich das auch vorschlagen, habe aber noch keine konkreteren Vorstellungen, wie das im Detail aussehen kann. Kann vorläufig auch gerne einfach ein separater Abschnitt in den "Praxisbeispielen" werden, analog zu dem "on-for-timer"-Thema bei Tasmota (das ist auch so ein "Großthema", bei dem der Hauptartikel irgendwann vor der MQTT2-Zeit entstanden ist).

Das Format ist etwas speziell, am einfachsten den Quelltext der Wiki-Seite anzeigen lassen und in dem Stil. (Wer notepad++ bedienen kann bekommt das hin... :P )
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 04 März 2022, 17:23:00
Zitat
Das Format ist etwas speziell, am einfachsten den Quelltext der Wiki-Seite anzeigen lassen und in dem Stil. (Wer notepad++ bedienen kann bekommt das hin... :P )
ich kann mich im wiki nicht mal anmelden! so schauts aus, NÜX KANNA  ;D ;D ;D

fahr jetzt essen, bis später mal ;)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 05 März 2022, 00:58:33
Azubi Monk an Monk ...
soo, @Beta-User, mach was draus ^^ (pm)

Grundidee wäre Implementierung mit ON / OFF Erweiterung auf toggle mit automatischem Reading habe ich beschrieben ^^

gn8  :P
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 März 2022, 07:43:04
Hi zurück,

Danke für den Input.

Erste Fassung ist in https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Shelly_Gen2 (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Shelly_Gen2). Muss das noch nacharbeiten und das mit dem "normalen" list ist m.E. auch im 1rst Gen (wo das "abgeschrieben" wurde) nicht optimal, da sollte eigentlich überall RAW stehen.
Es ist nach meinem Geschmack noch etwas sehr "frei" geschrieben, und der "toggle" ist bereits (update heute) im attrTemplate drin, also per default vorhanden.

Wenn möglich bitte auch (am einfachsten mit einer Kopie per RAW) das überarbeitete attrTemplate testen :) .

Im Zweifel einfach einen neuen Thread in https://forum.fhem.de/index.php/board,80.0.html (https://forum.fhem.de/index.php/board,80.0.html) dazu starten, und ich bin auch nicht böse, wenn einer der anderen "Wissenden" zum Thema Wiki und Shelly 2nd Gen. das direkt passend einpflegt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 05 März 2022, 11:34:35
Zitat von: Beta-User am 05 März 2022, 07:43:04
Im Zweifel einfach einen neuen Thread in https://forum.fhem.de/index.php/board,80.0.html (https://forum.fhem.de/index.php/board,80.0.html) dazu starten, und ich bin auch nicht böse, wenn einer der anderen "Wissenden" zum Thema Wiki und Shelly 2nd Gen. das direkt passend einpflegt.

moin,
Diskussion zum Wiki Beitrag hab ich mal hier gestartet:
https://forum.fhem.de/index.php/topic,126581.0.html (https://forum.fhem.de/index.php/topic,126581.0.html)

aktuell will mein System das neue Template halt nicht ziehen wie es scheint.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 13 März 2022, 09:02:00
moin beta ;)

hab da glaub noch ein Problemchen gefunden, kanns aber nur bei meinem Shelly Plus 1 sagen da ich keine anderen Shellys per Mqtt drin hab ...

sowohl das Internal STATE als auch das Reading state hängen sich manchmal auf "set on|off" auf - passiert immer dann, wenn das device einen status hat, und diesen nochmal bekommt.

nach einem umschalten ist wieder alles OK.

Lg
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 März 2022, 07:17:07
Hmm, ohne den MQTT-Verkehr dazu zu kennen, sehe ich dazu grade keinen "Anpack".
Wenn "state" (das Reading) auf "set xy" stehen bleibt, kommt keine passende Antwort zurück, oder sie wird nicht korrekt verarbeitet. Evtl. hat sich da auch wieder eine Kleinigkeit an der fw geändert? (der 1-er "tickt " ab der Stelle etwas anders als der 4-er, und es wäre naheliegend, dass man das seitens der Fa. auf einen einheitlichen Stand gebracht hat).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 14 März 2022, 07:55:56
moin

1. Toggle off --> on
2. Toggle on --> off
3. set off

hoffe hilft ;)


shellyplus1-441793a3b110/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}
fhem2shelly/rpc {"id":0,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"was_on":false}}
shellyplus1-441793a3b110/status/switch:0 {"id":0, "source":"MQTT", "output":true,"temperature":{"tC":49.6, "tF":121.3}}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyStatus","params":{"ts":1647240737.32,"switch:0":{"id":0,"output":true,"source":"MQTT"}}}

shellyplus1-441793a3b110/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}
fhem2shelly/rpc {"id":0,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"was_on":true}}
shellyplus1-441793a3b110/status/switch:0 {"id":0, "source":"MQTT", "output":false,"temperature":{"tC":49.5, "tF":121.1}}
shellyplus1-441793a3b110/events/rpc {"src":"shellyplus1-441793a3b110","dst":"shellyplus1-441793a3b110/events","method":"NotifyStatus","params":{"ts":1647240739.34,"switch:0":{"id":0,"output":false,"source":"MQTT"}}}

shellyplus1-441793a3b110/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}
fhem2shelly/rpc {"id":0,"src":"shellyplus1-441793a3b110","dst":"fhem2shelly","result":{"was_on":false}}
[code]
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 März 2022, 09:54:49
Zitat von: draddy am 14 März 2022, 07:55:56
hoffe hilft ;)
...in Teilen...

Das liegt nicht (nur) an FHEM: Das Rückmeldeverhalten des Shelly scheint nicht konsistent zu sein.
Mögliche Ansätze:
- FHEM sendet was "falsches", wobei hier m.E. nur eine Änderung der "id" in Frage kommen könnte => wir müßten die setList ändern und die id variabel gestalten;
- die firmware ist buggy => an den Hersteller wenden.

Würde empfehlen, mal dort nachzufragen, ob das so gedacht ist, dass die status und event-Topics nur manchmal "beliefert" werden...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 14 März 2022, 10:59:28
Ich bin mir nicht sicher, ob ich etwas übersehen habe ...

Der Shelly antwortet stets mit dem "momentanen" Zustand; sollte jetzt durch den Schaltwunsch eine Änderung erfolgen, wird auch der neue Zustand mitgeteilt.

Im letzten Fall ist der Shelly aber schon aus und ändert dementsprechend nichts ... schickt also auch keine "Änderungsmitteilung".
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 März 2022, 11:21:34
...auch wieder wahr...

Hmm, im Moment habe ich noch keine zündende Idee, wie man mit "doppelt genähten" Anweisungen sinnvoll umgehen kann und sollte.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 14 März 2022, 13:15:51
ja genau!
solange tatsächlich geschaltet wird, alles OK!

also, wenigstens ist mir noch nichts aufgefallen bei echter Schaltung.
tritt wirklich immer dann auf, wenn man einen Befehl sendet, der nicht ausgeführt wird, weil der shelly diesen status schon hat.

halt die frage, ob man nicht ins Modul "einfach" nen check baut.

wiegesagt, das ist alles kein Weltuntergang, in dem fall ist nach einem doppel toggle alles ok, ist mir halt aufgefallen als ich bissl mit readingsgroup und proxy gefummelt habe, das manchmal statt dem icon eben ein "set on|off" da gestanden ist.

habe auch noch nicht ganz festgestellt, wann das bei mir genau passiert (also, das ein "off" gesendet wird obwohl off ist)

wenn es hilft ... mit unserem neuen "in_mode" passiert das nicht, wenn dieser auf z.b. flip steht, und ich erneut flip sende, ist das reading ganz ganz kurz "set flip" wird dann aber sofort auf "flip" geändert.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 März 2022, 13:24:16
Zitat von: draddy am 14 März 2022, 13:15:51
halt die frage, ob man nicht ins Modul "einfach" nen check baut.
...stellte sich die Frage, was "das Modul" sein soll...
MQTT2_DEVICE liefert schon "das richtige", wenn man "setStateList" _nicht_ setzt - nur eben um den Preis, dass dann der state ggf. "optimistic" ist und Fehler in der Übermittlung nicht mehr transparent wären.

Man könnte auch den "eigenen" Topic "fhem2shelly/rpc" auswerten und dann auf die "war schon so"-Rückmeldungen so reagieren, dass man das state-Reading passend setzt... Bin für konstruktive Vorschläge offen und übernehme das ggf. gerne in die attrTemplate :P .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 14 März 2022, 14:09:08
mea culpa! natürlich Template nicht Modul :P


korrigier mich, aber: es kommt doch gar keine antwort vom shelly wenn ich "off" an den ausgeschalteten shelly sende oder?

wenn der shelly off ist, und ich nochmal off sende kommt nur von "fhem2shelly" result "was_on":false" und in dem moment schickt fhem2shelly doch nichts mehr an das device selbst, oder verstehe ich das falsch?






Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 März 2022, 14:13:34
Zitat von: draddy am 14 März 2022, 14:09:08
korrigier mich, aber: es kommt doch gar keine antwort vom shelly wenn ich "off" an den ausgeschalteten shelly sende oder?
Doch, es kommt eine Antwort, nur haben wir die bisher verworfen, nämlich

Zitat
kommt nur von "fhem2shelly" result "was_on":false"
Das müßte man auswerten und prüfen, ob es ein "set on" war oder ein "set off"; beide Fälle unterscheiden sich nämlich, und nur im (jeweils) einen düfte dann ein "off" (bzw. "on") in state geschrieben werden (siehe deine MQTT-Messages von vorhin).

Zitat
in dem moment schickt fhem2shelly doch nichts mehr an das device selbst, oder verstehe ich das falsch?
Es muss auch nichts mehr an den ESP gesendet werden, es muss nur der state in FHEM (korrekt) aktualisiert werden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 14 März 2022, 14:20:05
hmhm ... also ... ich wiss vom "in_mode" noch, das neue readings erstellt wurden ...

hab "fhem2shelly/rpc:.* {}" mal aus der readingslist rausgeworfen ... aber da wurden keine neuen erstellt (dachte mir wäre ein versuch wert)

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 März 2022, 14:23:06
...das Browserfenster hast du danach und nach mind. einem Schaltvorgang per refresh aktualisiert...?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 14 März 2022, 14:24:21
mehrfach, das spiel kannte ich ja vom "in_mode" noch zugenüge ^^
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 März 2022, 14:29:46
Hmm, ist dieser Topic in ignoreRegexp am IO zu finden?
Es gibt mind eine weitere M2D-Instanz, die diesen Topic abonniert :-[ .

Da müßte man also auch noch was bauen, was individuell pro Shelly ist, M...!! Unschön. Muss vermutlich mal drüber nachdenken, was da die beste Lösung sein könnte, aber vielleicht fällt noch jemand anderem was ein?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 14 März 2022, 14:38:48
da hab ich wieder was ausgelöst ...

wenn du was von meiner seite brauchst, meld dich, wenn mir noch was ein oder auffällt meld ich mich - sonst hoffen wir mal auf die anderen klugen köpfe ^^

irgendwie mit nem mapping können wir das nicht fixen oder?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 14 März 2022, 15:15:14
Zitat von: draddy am 14 März 2022, 14:38:48
da hab ich wieder was ausgelöst ...
Es ist nicht soooo dramatisch, eher eine Fleiß-Aufgabe...

Zitat
irgendwie mit nem mapping können wir das nicht fixen oder?
Nein, jedenfalls nicht direkt.

Das "Problem": Wir können angeben, wohin wir eine Antwort haben wollen, wenn eine Anweisung per MQTT an so einen 2nd gen. Shelly rausgeht. Siehe auch die Beispiele in https://shelly-api-docs.shelly.cloud/gen2/HOWTO/MQTTSetup.
Bisher verwenden wir dafür einen "Einheits-Kenner", weil wir die Antwort an sich nicht brauchen - jedenfalls dann nicht, wenn wirklich geschaltet wird. Dann bekommen wir nämlich die Info über einen anderen Topic.

Jetzt stellt sich raus, dass wir in einigen sehr begrenzten Fällen die Infos doch brauchen könnten.
Ergo müßte man
- einen "unique"-Topic festlegen, auf dem die Antwort jeweils kommen soll, und
- die Auswertung für die sehr eng begrenzten Fälle machen, in denen man diese Infos eben doch braucht.

Fleißaufgabe eben... Just do it ;) .
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 19 März 2022, 10:09:20
Guten Morgen

Ich wollte mir den neuen Shelly plus 2pm bestellen und frage deshalb hier erstmal nach, ob es dazu schon ein template gibt oder ob ich einfach das vom 2.5 nutzen kann.

Vielen dank schonmal.

Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 19 März 2022, 11:03:19
moin,

für den plus 1 pm gibts wohl eins, auf dem könnte man dann vermutlich aufbauen.

das für den 2.5 wird nicht klappen, da zwischen gen1 und gen2 Geräten größere Änderungen vom Hersteller erfolgt sind.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 19 März 2022, 12:02:07
Vermutlich eher auf das 4-er. Sollte jedenfalls zu machen sein...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 20 März 2022, 16:07:13
Was bedeutet es das template anzupassen? Die setlist und readingslist anpassen oder ist das sehr aufwendig?

Meine Kenntnisse bei sowas sind nicht sonderlich ausgeprägt. Sollte ich evtl doch lieber den 2,5 nehmen? Ich tendiere zu dem neuen Plus 2 pm, weil der angeblich nicht so warm wird. Oder ist evtl schon jemand an einem passenden template dran?

Viele Grüße

Christian
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 20 März 2022, 20:22:16
also, meine Erfahrung ist, das hier sehr gut geholfen wird.
das es noch kein Template gibt, liegt vermutlich daran, dass den plus 2 noch keiner hat, hilft also am ende auch anderen wenn man den Entwicklern zum testen und Infos liefern zur Verfügung steht ;)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: seule3008 am 20 März 2022, 20:26:03
Ich bestelle erstmal einen und versuche es mal. Bei den 6 die ich brauche ist mir das Investment zu hoch falls ich das doch nicht hinbekomme.

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: draddy am 20 März 2022, 20:29:36
DAS klingt doch wie ein plan  ;D
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: fredje am 07 April 2022, 10:05:55
Hallo,
bin gerade dabei ein Shelly Plug S einzurichten. Nach Umstellen des Shelly auf MQTT wird dies im Fhem angezeigt.
Wenn ich nun das Template "shelly1_w_energy_measuring" auswähle bekomme ich folgenden Fehler:

ERROR executing perl-code { my $old =  AttrVal("MQTT2_shellyplug_s_C554B8","userReadings",undef);; !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old.', relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}' } for param NEWUSERREADINGS: Bad name after relay_0_energy' at (eval 30714) line 1.

Kann mir jemand weiterhelfen?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 07 April 2022, 10:32:20
Zitat von: fredje am 07 April 2022, 10:05:55
Kann mir jemand weiterhelfen?
Kann sein, dass mir beim Überarbeiten des attrTemplate-Satzes zu Shelly ein Fehler unterlaufen ist. Kannst du bitte sagen, wann du das letzte Update von FHEM gemacht hattest (bzw. welche template-Version in der setreading-Anweisung am Ende des Info-Textes angezeigt wird, wenn du das attrTemplate aus der Dropdown-List auswählst) und hier ein RAW-List einstellen, damit ich das kurz selbst durchspielen kann?

EDIT: Fehler vermutlich gefunden, update folgt bei Gelegenheit...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: fredje am 07 April 2022, 17:12:23
Hallo Beta_User,
vielen Dank für deine Hilfe. Einen fhem update habe ich gerade gemacht, hat nicht geholfen.
Anbei die Infos ..

###########################################
# $Id: mqtt2.template 25920 2022-04-05 05:38:54Z Beta-User $
#
# Comments start with #. Empty lines are ignored.
# Syntax of one entry: name: line, one optional filter: line, zero or more par: lines,  FHEM-Commands
# filter:INTERNAL=VALUE (optional)
# par: name of the parameter; comment; perl_code (optional)
# perl_code returns a value for the parameter, or undef.
# If undef, the user has to specify them (the comment is shown to the user)


Applies to single relay Shelly devices offering energy measuring like Shelly 1PM or Shelly Plug S
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  toggle:noArg shellies/DEVNAME/relay/0/command toggle\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* {{ state => $EVENT, relay0 => $EVENT}}\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? 'off':'on'; ReadingsVal($NAME,'loadState','off') ne $compare ? { loadState => $compare } : return }\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/temperature_f:.* {}\
  shellies/DEVNAME/input_event/0:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* { relay_0_energy => $EVENT, relay_0_kWh => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/DEVNAME/longpush/0:.* longpush_0
attr DEVICE 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'); my $cons = ReadingsVal($name,'relay_0_power','unknown'); my $total = ReadingsVal($name,'relay_0_kWh','unknown'); my $temp = ReadingsVal($name,'temperature','-100'); "".FW_makeImage($onl)." ".FW_makeImage($light)."
Verbrauch: $cons / Total: $total/ Temp: $temp °C
"}
attr DEVICE comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr DEVICE webCmd :
attr DEVICE setStateList on off toggle
deletereading -q DEVICE (?!associatedWith|IODev).*
set DEVICE x_mqttcom announce
attr DEVICE model shelly1_w_energy_measuring
setreading DEVICE attrTemplateVersion 20220404
option:{ CALLSPEECHRECOGN } 
set DEVICE attrTemplate speechcontrol_type_switch
option:{ RADIO_SETUSERREADING }
attr DEVICE userReadings NEWUSERREADINGS
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 07 April 2022, 17:17:50
Zitat von: Beta-User am 07 April 2022, 10:32:20
EDIT: Fehler vermutlich gefunden, update folgt bei Gelegenheit...

#2688 in der Datei sollte wohl eher so aussehen (nach Änderung reicht ein {AttrTemplate_Initialize()} aus):
par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old = AttrVal('DEVICE','userReadings',undef); !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old . q(, relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}) }
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: fredje am 08 April 2022, 10:10:21
Hallo Beta-User,
habe die Änderung getestet Fehler bleibt. Habe zusätzlichfhem neu gestartet

Hier der geänderte Bereich:
#contributed by 87insane, https://forum.fhem.de/index.php/topic,94060.msg934614.html#msg934614
# shelly1pm using original firmware.
name:shelly1_w_energy_measuring
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
order:A_10b
desc:Applies to single relay Shelly devices offering energy measuring like Shelly 1PM or Shelly Plug S
par:DEVNAME;Shelly device name in the topic;{ AttrVal('DEVICE','readingList','') =~ m,shellies/([^/]*)/, ? $1 : undef }
par:RADIO_SETUSERREADING;Set userreading for total energy consumption;{ undef }
par:RADIO_DONOTSETUSERREADING;Do not set userreading for total energy consumption;{ undef }
par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old = AttrVal('DEVICE','userReadings',undef); !defined $old ? 'relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}' : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old . q(, relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}) }
par:CALLSPEECHRECOGN;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
attr DEVICE setList\
  relay0:on,off,toggle shellies/DEVNAME/relay/0/command $EVTPART1\
  toggle:noArg shellies/DEVNAME/relay/0/command toggle\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/relay/0:.* {{ state => $EVENT, relay0 => $EVENT}}\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : return }\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/relay/0/power:.* relay_0_power\
  shellies/DEVNAME/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? 'off':'on'; ReadingsVal($NAME,'loadState','off') ne $compare ? { loadState => $compare } : return }\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/temperature_f:.* {}\
  shellies/DEVNAME/input_event/0:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/overtemperature:.* overtemperature\
  shellies/DEVNAME/relay/0/energy:.* { relay_0_energy => $EVENT, relay_0_kWh => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/DEVNAME/longpush/0:.* longpush_0
attr DEVICE 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'); 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 / Total: $total/ Temp: $temp °C</div>"}
attr DEVICE comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr DEVICE webCmd :
attr DEVICE setStateList on off toggle
deletereading -q DEVICE (?!associatedWith|IODev).*
set DEVICE x_mqttcom announce
attr DEVICE model shelly1_w_energy_measuring
setreading DEVICE attrTemplateVersion 20220404
option:{ CALLSPEECHRECOGN } 
set DEVICE attrTemplate speechcontrol_type_switch
option:{ RADIO_SETUSERREADING }
attr DEVICE userReadings NEWUSERREADINGS
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 08 April 2022, 10:36:46
OK, hab' grad eh' eine RAW-def zur Hand gehabt zum Testen. So sollte es gehen:
par:NEWUSERREADINGS;NEWUSERREADINGS as set if relay_0_energy_total is included, otherwise it will be added;{ my $old = AttrVal('DEVICE','userReadings',undef); !defined $old ? q(relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}) : $old =~ m,relay_0_energy_total:relay_0_energy.*, ? $old : $old . q(, relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}) }
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: fredje am 08 April 2022, 13:26:19
Danke für die Hilfe, es funktioniert jetzt.  :)
Gibt es ein wiki wo die template Erstellung beschrieben ist. Mir erschließt sich z.B. der par: Befehl nicht ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 08 April 2022, 13:53:02
 :) und sorry für das Problem...

https://wiki.fhem.de/wiki/AttrTemplate
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Helmi55 am 27 April 2022, 12:53:50
Hallo Mahlzeit
ich dachte unter opt/fhem/FHEM/lib/AttrTemplate
Finde ich alle verfügbaren Template? Dem ist nicht so.....

Ich wollte ein Shelly Templ öffnen und bearbeiten und unter anderem Namen wieder abspeichern.
shellyPlus_1pm würde mich interessieren da ich es für Energiemessung (PV) verwende
und wollte Verbrauch gegen Ertrag ändern - ja Jammern auf hohem Niveau :P

Danke und Gruß
Helmut
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 27 April 2022, 13:06:14
Das fragliche attrTemplate sollte in der Datei mqtt2.template zu finden sein, es startet (derzeit) in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L3482
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Helmi55 am 27 April 2022, 14:40:45
Uups ok Danke
Laienhafte Frage von mir:
Kann ich den Teil "unten" wieder unter anderem Namen anhängen?
Wahrscheinlich nicht da dann immer ü beschrieben bzw. gelöscht wird.
Rauskopieren und unter eigenem templ abspeichern - oder?

Gruß
Helmut
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 27 April 2022, 14:59:25
Zitat von: Helmi55 am 27 April 2022, 14:40:45
Uups ok Danke
Laienhafte Frage von mir:
:) Du bist ganz sicher nicht der einzige, dem die Mechanismen nicht klar sind, und die Frage ist daher völlig legitim!

Zitat
Kann ich den Teil "unten" wieder unter anderem Namen anhängen?
Wahrscheinlich nicht da dann immer ü beschrieben bzw. gelöscht wird.
Rauskopieren und unter eigenem templ abspeichern - oder?
Ja, "anhängen" ginge prinzipiell auch, das wäre aber nicht update-fest.

Komplett neues template in eigener Datei wäre besser, aber nachdem du den Mechanismus ja bereits durchschaut hast, würde ich noch eine weitere Variante ins Spiel bringen wollen:

Nimm aus deinem "Klon" die "doppelten Teile" raus, und rufe einfach _zuerst_ das (ggf. upgedatete) allgemeine attrTemplate auf, und ergänze dann danach nur noch das, was du abweichend haben willst. Also (da vermutlich u.A. die jsonMap etwas anders aussieht?, diesen Teil als "Muster"):
set DEVICE attrTemplate shellyPlus_1pm
attr DEVICE jsonMap <deine Angaben>


Das hat den Vorteil, dass bei einem update (weil die Shelly-Jungs sich wieder irgendeine Verschwurbelung überlegt haben...), dann dieser Teil einfach aus dem allgemeinen (zentral aktualisierten) attrTemplate-Satz kommt - das sollte die künftige Pflege einfacher machen (bzw. überflüssig).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Helmi55 am 27 April 2022, 17:13:18
Danke für deine rasche Antwort
Werde mir das in Ruhe überlegen.
Besonders gut finde ich den Ausdruck "Verschwurbelung". Kommt gut an die "schwurbler" hin
Sorry für OT

Helmut
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: casoe am 28 September 2022, 21:55:09
Hallo zusammen,

hat zufällig jemand einen Shelly TRV Thermostat im Einsatz? Ich hab meinen ersten in Betrieb genommen und es gibt kein Template für das Device. Einbindung in FHEM als MQTT2-Device hat direkt geklappt und viele Readings werden auch schon angezeigt. Ich kann das Thermostat über FHEM aber ohne AttrTemplate nicht steuern.

Auf dieser Seite gibt es eine Doku zu den Kommandos: https://shelly-api-docs.shelly.cloud/gen1/#shelly-trv-overview

Diese lauten: Command topics
Shelly TRV supports a set of commands published on shellies/thermostat/0/command/ to address all TRVs or shellies/shellytrv-<id>/thermostat/0/command/ to address an individual device:
settings will trigger piblishing the content of http /settings endpoint
schedule accepts 1 or 0 to enable/disable schedule
schedule_profile accepts number from 1 to 5 to choose active schedule profile with the provided id
target_t accepts number from 4 to 31 set target temperature.
ext_t accepts number to send external sensor temperature, in deg C
valve_pos accepts number from 0 to 100 to set manually the valve position, in %
boost_minutes accepts number to start boost mode for the given minutes, in minutes
set_boost_minutes accepts number to set the default boost time, in minutes
valve_min_percent accepts number from 0 to 10 to set the valve clse postion percent, in %
accelerated_heating accepts 1 or 0 to enable/disable accelerated heating

Kann jemand helfen, ggf. eines der vorhanden Templates so anzupassen, dass man alles steuern kann?

Beste Grüße
Carsten
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 28 September 2022, 22:08:36
Sollte nicht allzu schwierig sein.

Kannst du dazu bitte einen separaten Thread aufmachen und zumindest mal eine RAW-Definition von deinem Gerät zeigen? Ich bräuchte die automatisch erzeugten Reading-Namen, damit wir einen "runden" (jsonMap-?) Kreis hinbekommen (und optimalerweise den jeweiligen Topic, über den ggf. die Infos reinkommen, falls es JSON-verpackt ist).

Wenn du dich eindenken willst, nimmst du am besten einen Shelly-Dimmer als Basis und schaust dir dazu dann noch eines der anderen 3 (?) thermostat-attrTemplates an (wegen der Reading-und setter-Namen).
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: casoe am 28 September 2022, 22:38:24
Super, danke dir! Ist erledigt. Der neue Thread ist hier: https://forum.fhem.de/index.php/topic,129394.0.html
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Crawler am 23 November 2022, 08:14:58
Ich habe hier ein Shellyplug-S eingebunden und wollte fragen worin die Absicht besteht das manche Readings doppelt sind.

zeigen alle false
Zitathas_update
new_fw
update_has_update

zeigen die aktuelle fw
Zitatfw_ver
update_old_version
update_new_version

zeigen die temp
Zitattemperature
tmp_tC
tmp_tF
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: rudolfkoenig am 23 November 2022, 10:00:57
ZitatIch habe hier ein Shellyplug-S eingebunden und wollte fragen worin die Absicht besteht das manche Readings doppelt sind.
Diese Readings werden aus (vom Shelly gesendeten) JSON-Strukturen automatisch generiert, d.h. die Shelly-Firmware ist der Ansicht, dass man den gleichen Wert an verschiedenen Stellen hinterlegen muss. Warum das so ist, muss man die Autoren bei Shelly fragen.

Das MQTT2_DEVICE Modul bietet diverse Mechanismen Readings zu filtern oder umzubennen, z.Bsp. mit dem jsonMap Attribut, oder den prefix und filter Parameter im json2nameValue Aufruf im readingsList Attribut.

Falls jemand sowas fuer ein Geraet erstellt hat, dann sollte man es veroeffentlichen oder gleich ein AttrTemplate erstellen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 23 November 2022, 10:04:38
Zitat von: Crawler am 23 November 2022, 08:14:58
Ich habe hier ein Shellyplug-S eingebunden und wollte fragen worin die Absicht besteht das manche Readings doppelt sind.

zeigen alle false
zeigen die aktuelle fw
zeigen die temp
Rudi war schneller, aber (teilweise) doppelt genäht hält vielleicht besser...

Na ja, "Absicht" würde ich mal nicht unterstellen, ist eher "so na wora" und eine Kombination von "altem" attrTemplate (also zu einem frühen Zeitpunkt entwickelt, auf Basis der damaligen firmware) und diversen Änderungen, die der Hersteller zwischenzeitlich vorgenommen hat. Könnte man sicher mal aufräumen und ich bin auf konkrete Vorschläge gespannt ;) . (Wie üblich habe ich die Hardware nicht, zum einen, weil ich WLAN im allgemeinen nicht in der Automatisierung für sowas einsetzen will, und zum anderen, weil ich diese firmwares grausam finde...).

Ob überhaupt aktuell noch alles befüllt wird, ergibt sich aus dem screenshot nicht (bitte künftig einfach den Text (per raw-list) kopieren und hier in Code-Tags einfügen). Es gibt ein paar aktualisierte attrTemplate, die z.B. die Fahrenheit-temp direkt beerdigen. Sowas wie eine generalisierte Anleitung wäre im Wiki unter "Schritt für Schritt" zu finden.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 23 November 2022, 13:58:28
Zitat von: Crawler am 23 November 2022, 08:14:58
Ich habe hier ein Shellyplug-S eingebunden und wollte fragen worin die Absicht besteht das manche Readings doppelt sind.

Sicherlich könnte man die Lage besser einschätzen, wenn Du die neue "Copy for forum.fhem.de"-Funktion auf der Detailseite verwendest und Deinen Zustand anonymisiert hier einstellst.

Die meisten der doppelten Readings hast Du dir vermutlich durch die "vollumfängliche" announce-Antwort eingehandelt ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Crawler am 24 November 2022, 22:53:22
Die Funktion hatte ich noch gar nicht wahrgenommen  ::)
hier dann nochmal der Raw.
wodurch habe ich das "vollumfängliche" announce erzeugt?
Ich hatte ein MQTT erzeugt und den Shellyplug bei attrtemplate ausgewählt.

define Schalter_Kueche MQTT2_DEVICE shellyplug_s_4022D882***
attr Schalter_Kueche devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false' ? 'rot' : ReadingsVal($name,'new_fw','false') eq 'true' ? 'gelb' : 'gruen';; my $light = ReadingsVal($name,'state','off');; my $show = '<a href="';;$show .= $onl eq 'gelb' ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : 'http://'.ReadingsVal($name,'ip','none').' "target="_blank">';; $show .= FW_makeImage("10px-kreis-$onl").'</a>';; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light).'</a></div>' }
attr Schalter_Kueche event-min-interval .*:900
attr Schalter_Kueche getList power:noArg shellies/shellyplug-s-kueche/relay/power power
attr Schalter_Kueche model shellyplug
attr Schalter_Kueche readingList shellies/shellyplug-s-kueche/relay/0:.* {{ state => $EVENT, relay0 => $EVENT}}\
  shellies/shellyplug-s-kueche/input/0:.* input0\
  shellies/shellyplug-s-kueche/online:.* online\
  shellies/shellyplug-s-kueche/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-kueche...mac.*, ? json2nameValue($EVENT) : return }\
shellyplug_s_4022D882EB8D:shellies/shellyplug-s-kueche/info:.* { json2nameValue($EVENT) }\
shellyplug_s_4022D882EB8D:shellies/shellyplug-s-kueche/temperature:.* temperature\
shellyplug_s_4022D882EB8D:shellies/shellyplug-s-kueche/overtemperature:.* overtemperature\
shellyplug_s_4022D882EB8D:shellies/shellyplug-s-kueche/relay/0/energy:.* relay_0_energy\
shellyplug_s_4022D882EB8D:shellies/shellyplug-s-kueche/relay/0/power:.* relay_0_power\
shellyplug_s_4022D882EB8D:shellies/shellyplug-s-kueche/temperature_f:.* temperature_f
attr Schalter_Kueche room MQTT2_DEVICE
attr Schalter_Kueche setList off:noArg shellies/shellyplug-s-kueche/relay/0/command off\
  on:noArg shellies/shellyplug-s-kueche/relay/0/command on\
  x_update:noArg shellies/shellyplug-s-kueche/command update_fw\
  x_mqttcom shellies/shellyplug-s-kueche/command $EVTPART1
#   CID        shellyplug_s_4022D882EB8D
#   DEF        shellyplug_s_4022D882EB8D
#   FUUID      636fea05-f33f-6071-30bb-027a2e705f06a6e2
#   IODev      mqttBroker
#   LASTInputDev mqttBroker
#   MSGCNT     295737
#   NAME       Schalter_Kueche
#   NR         245
#   STATE      on
#   TYPE       MQTT2_DEVICE
#   eventCount 6988
#   mqttBroker_CONN mqttBroker_192.168.178.97_7237
#   mqttBroker_MSGCNT 295737
#   mqttBroker_TIME 2022-11-24 22:51:01
#   OLDREADINGS:
#   READINGS:
#     2022-11-23 08:06:09   actions_stats_skipped 0
#     2022-11-23 08:06:09   attrTemplateVersion 20211030
#     2022-11-23 08:06:09   cfg_changed_cnt 1
#     2022-11-23 08:06:09   cloud_connected false
#     2022-11-23 08:06:09   cloud_enabled   false
#     2022-11-23 08:06:09   fs_free         166664
#     2022-11-23 08:06:09   fs_size         233681
#     2022-11-23 08:06:09   fw_ver          20221027-101131/v1.12.1-ga9117d3
#     2022-11-23 08:06:09   has_update      false
#     2022-11-23 08:06:09   id              shellyplug-s-kueche
#     2022-11-23 08:06:09   ip              192.168.178.97
#     2022-11-23 08:06:09   mac             4022D882EB8D
#     2022-11-23 08:06:09   meters_1_counters_1 77.119
#     2022-11-23 08:06:09   meters_1_counters_2 77.144
#     2022-11-23 08:06:09   meters_1_counters_3 81.060
#     2022-11-23 08:06:09   meters_1_is_valid true
#     2022-11-23 08:06:09   meters_1_overpower 0.00
#     2022-11-23 08:06:09   meters_1_power  77.45
#     2022-11-23 08:06:09   meters_1_timestamp 1669190769
#     2022-11-23 08:06:09   meters_1_total  764635
#     2022-11-23 08:06:09   model           SHPLG-S
#     2022-11-23 08:06:09   mqtt_connected  true
#     2022-11-23 08:06:09   new_fw          false
#     2022-11-23 08:06:09   online          true
#     2022-11-24 22:51:01   overtemperature 0
#     2022-11-23 08:06:09   ram_free        40120
#     2022-11-23 08:06:09   ram_total       52072
#     2022-11-24 22:51:01   relay0          on
#     2022-11-24 22:51:01   relay_0_energy  886853
#     2022-11-24 22:51:01   relay_0_power   23.93
#     2022-11-23 08:06:09   relays_1_has_timer false
#     2022-11-23 08:06:09   relays_1_ison   true
#     2022-11-23 08:06:09   relays_1_overpower false
#     2022-11-23 08:06:09   relays_1_source mqtt
#     2022-11-23 08:06:09   relays_1_timer_duration 0
#     2022-11-23 08:06:09   relays_1_timer_remaining 0
#     2022-11-23 08:06:09   relays_1_timer_started 0
#     2022-11-23 08:06:09   serial          32129
#     2022-11-24 22:51:01   state           on
#     2022-11-24 22:51:01   temperature     25.04
#     2022-11-24 22:51:01   temperature_f   77.08
#     2022-11-23 08:06:09   time            08:06
#     2022-11-23 08:06:09   tmp_is_valid    true
#     2022-11-23 08:06:09   tmp_tC          29.86
#     2022-11-23 08:06:09   tmp_tF          85.75
#     2022-11-23 08:06:09   unixtime        1669187169
#     2022-11-23 08:06:09   update_has_update false
#     2022-11-23 08:06:09   update_new_version 20221027-101131/v1.12.1-ga9117d3
#     2022-11-23 08:06:09   update_old_version 20221027-101131/v1.12.1-ga9117d3
#     2022-11-23 08:06:09   update_status   idle
#     2022-11-23 08:06:09   uptime          908382
#     2022-11-23 08:06:09   wifi_sta_connected true
#     2022-11-23 08:06:09   wifi_sta_ip     192.168.178.97
#     2022-11-23 08:06:09   wifi_sta_rssi   -62
#     2022-11-23 08:06:09   wifi_sta_ssid   the New Generation Crawler
#
setstate Schalter_Kueche on
setstate Schalter_Kueche 2022-11-23 08:06:09 actions_stats_skipped 0
setstate Schalter_Kueche 2022-11-23 08:06:09 attrTemplateVersion 20211030
setstate Schalter_Kueche 2022-11-23 08:06:09 cfg_changed_cnt 1
setstate Schalter_Kueche 2022-11-23 08:06:09 cloud_connected false
setstate Schalter_Kueche 2022-11-23 08:06:09 cloud_enabled false
setstate Schalter_Kueche 2022-11-23 08:06:09 fs_free 166664
setstate Schalter_Kueche 2022-11-23 08:06:09 fs_size 233681
setstate Schalter_Kueche 2022-11-23 08:06:09 fw_ver 20221027-101131/v1.12.1-ga9117d3
setstate Schalter_Kueche 2022-11-23 08:06:09 has_update false
setstate Schalter_Kueche 2022-11-23 08:06:09 id shellyplug-s-kueche
setstate Schalter_Kueche 2022-11-23 08:06:09 ip 192.168.178.97
setstate Schalter_Kueche 2022-11-23 08:06:09 mac 4022D882EB8D
setstate Schalter_Kueche 2022-11-23 08:06:09 meters_1_counters_1 77.119
setstate Schalter_Kueche 2022-11-23 08:06:09 meters_1_counters_2 77.144
setstate Schalter_Kueche 2022-11-23 08:06:09 meters_1_counters_3 81.060
setstate Schalter_Kueche 2022-11-23 08:06:09 meters_1_is_valid true
setstate Schalter_Kueche 2022-11-23 08:06:09 meters_1_overpower 0.00
setstate Schalter_Kueche 2022-11-23 08:06:09 meters_1_power 77.45
setstate Schalter_Kueche 2022-11-23 08:06:09 meters_1_timestamp 1669190769
setstate Schalter_Kueche 2022-11-23 08:06:09 meters_1_total 764635
setstate Schalter_Kueche 2022-11-23 08:06:09 model SHPLG-S
setstate Schalter_Kueche 2022-11-23 08:06:09 mqtt_connected true
setstate Schalter_Kueche 2022-11-23 08:06:09 new_fw false
setstate Schalter_Kueche 2022-11-23 08:06:09 online true
setstate Schalter_Kueche 2022-11-24 22:51:01 overtemperature 0
setstate Schalter_Kueche 2022-11-23 08:06:09 ram_free 40120
setstate Schalter_Kueche 2022-11-23 08:06:09 ram_total 52072
setstate Schalter_Kueche 2022-11-24 22:51:01 relay0 on
setstate Schalter_Kueche 2022-11-24 22:51:01 relay_0_energy 886853
setstate Schalter_Kueche 2022-11-24 22:51:01 relay_0_power 23.93
setstate Schalter_Kueche 2022-11-23 08:06:09 relays_1_has_timer false
setstate Schalter_Kueche 2022-11-23 08:06:09 relays_1_ison true
setstate Schalter_Kueche 2022-11-23 08:06:09 relays_1_overpower false
setstate Schalter_Kueche 2022-11-23 08:06:09 relays_1_source mqtt
setstate Schalter_Kueche 2022-11-23 08:06:09 relays_1_timer_duration 0
setstate Schalter_Kueche 2022-11-23 08:06:09 relays_1_timer_remaining 0
setstate Schalter_Kueche 2022-11-23 08:06:09 relays_1_timer_started 0
setstate Schalter_Kueche 2022-11-23 08:06:09 serial 32129
setstate Schalter_Kueche 2022-11-24 22:51:01 state on
setstate Schalter_Kueche 2022-11-24 22:51:01 temperature 25.04
setstate Schalter_Kueche 2022-11-24 22:51:01 temperature_f 77.08
setstate Schalter_Kueche 2022-11-23 08:06:09 time 08:06
setstate Schalter_Kueche 2022-11-23 08:06:09 tmp_is_valid true
setstate Schalter_Kueche 2022-11-23 08:06:09 tmp_tC 29.86
setstate Schalter_Kueche 2022-11-23 08:06:09 tmp_tF 85.75
setstate Schalter_Kueche 2022-11-23 08:06:09 unixtime 1669187169
setstate Schalter_Kueche 2022-11-23 08:06:09 update_has_update false
setstate Schalter_Kueche 2022-11-23 08:06:09 update_new_version 20221027-101131/v1.12.1-ga9117d3
setstate Schalter_Kueche 2022-11-23 08:06:09 update_old_version 20221027-101131/v1.12.1-ga9117d3
setstate Schalter_Kueche 2022-11-23 08:06:09 update_status idle
setstate Schalter_Kueche 2022-11-23 08:06:09 uptime 908382
setstate Schalter_Kueche 2022-11-23 08:06:09 wifi_sta_connected true
setstate Schalter_Kueche 2022-11-23 08:06:09 wifi_sta_ip 192.168.178.97
setstate Schalter_Kueche 2022-11-23 08:06:09 wifi_sta_rssi -62
setstate Schalter_Kueche 2022-11-23 08:06:09 wifi_sta_ssid the New Generation Crawler

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 25 November 2022, 06:46:27
Zitat von: Crawler am 24 November 2022, 22:53:22
Ich hatte ein MQTT erzeugt und den Shellyplug bei attrtemplate ausgewählt.

Du hast Dich scheinbar nicht für das richtige Template entschieden, da u.a. temperature_f nicht "geerdet" wird. Normalerweise steht im Template diesbezüglich folgende Zeile in der readingList:

shellies/DEVNAME/temperature_f:.* {}\

Besser für einen "Neuanfang" wäre vermutlich das Template shelly1_w_energy_measuring.

Zitat von: Crawler am 24 November 2022, 22:53:22
wodurch habe ich das "vollumfängliche" announce erzeugt?
Wodurch announce ausgelöst wurde, ist schwer zu beantworten. Wann, ist da schon einfacher ... tritt auf jeden Fall eher selten auf.

Um die doppelten, nicht ständig aktualisierten Readings abzugrenzen, nutze ich folgende Zeile in der readingList:

shellies/DEVNAME/info:.* { json2nameValue($EVENT,'info_') }


***

Die obige Verwendung von DEVNAME macht nur fürs Template Sinn, am Ende steht dort der tatsächliche FHEM-Device-Name ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Crawler am 25 November 2022, 23:31:59
durch das ändern des templates und löschen aller readings hat sich jetzt nicht soviel getan
define Schalter_Kueche MQTT2_DEVICE shellyplug_s_4022D882EB8D
attr Schalter_Kueche comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
attr Schalter_Kueche 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');; 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 / Total: $total/ Temp: $temp °C</div>"}
attr Schalter_Kueche event-min-interval .*:900
attr Schalter_Kueche getList power:noArg shellies/shellyplug-s-kueche/relay/power power
attr Schalter_Kueche model shelly1_w_energy_measuring
attr Schalter_Kueche readingList shellies/shellyplug-s-kueche/relay/0:.* {{ state => $EVENT, relay0 => $EVENT}}\
  shellies/shellyplug-s-kueche/input/0:.* input0\
  shellies/shellyplug-s-kueche/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-kueche...mac.*, ? json2nameValue($EVENT) : return }\
  shellies/shellyplug-s-kueche/announce:.* { json2nameValue($EVENT) }\
  shellies/shellyplug-s-kueche/relay/0/power:.* relay_0_power\
  shellies/shellyplug-s-kueche/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? 'off':'on';; ReadingsVal($NAME,'loadState','off') ne $compare ? { loadState => $compare } : return }\
  shellies/shellyplug-s-kueche/temperature:.* temperature\
  shellies/shellyplug-s-kueche/temperature_f:.* {}\
  shellies/shellyplug-s-kueche/input_event/0:.* { json2nameValue($EVENT) }\
  shellies/shellyplug-s-kueche/overtemperature:.* overtemperature\
  shellies/shellyplug-s-kueche/relay/0/energy:.* { relay_0_energy => $EVENT, relay_0_kWh => sprintf("%.2f",$EVENT/60/1000)}\
  shellies/shellyplug-s-kueche/longpush/0:.* longpush_0\
shellyplug_s_4022D882EB8D:shellies/shellyplug-s-kueche/info:.* { json2nameValue($EVENT) }
attr Schalter_Kueche room MQTT2_DEVICE
attr Schalter_Kueche setList relay0:on,off,toggle shellies/shellyplug-s-kueche/relay/0/command $EVTPART1\
  toggle:noArg shellies/shellyplug-s-kueche/relay/0/command toggle\
  off:noArg shellies/shellyplug-s-kueche/relay/0/command off\
  on:noArg shellies/shellyplug-s-kueche/relay/0/command on\
  x_update:noArg shellies/shellyplug-s-kueche/command update_fw\
  x_mqttcom shellies/shellyplug-s-kueche/command $EVTPART1
attr Schalter_Kueche setStateList on off toggle
attr Schalter_Kueche userReadings relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum($name,'relay_0_energy',0)}
attr Schalter_Kueche webCmd :
#   CID        shellyplug_s_4022D882EB8D
#   DEF        shellyplug_s_4022D882EB8D
#   FUUID      636fea05-f33f-6071-30bb-027a2e705f06a6e2
#   IODev      mqttBroker
#   LASTInputDev mqttBroker
#   MSGCNT     321462
#   NAME       Schalter_Kueche
#   NR         245
#   STATE      on
#   TYPE       MQTT2_DEVICE
#   eventCount 7584
#   mqttBroker_CONN mqttBroker_192.168.178.97_7237
#   mqttBroker_MSGCNT 321462
#   mqttBroker_TIME 2022-11-25 23:30:49
#   OLDREADINGS:
#   READINGS:
#     2022-11-25 23:30:31   actions_stats_skipped 0
#     2022-11-25 23:30:30   attrTemplateVersion 20220408
#     2022-11-25 23:30:31   cfg_changed_cnt 1
#     2022-11-25 23:30:31   cloud_connected false
#     2022-11-25 23:30:31   cloud_enabled   false
#     2022-11-25 23:30:31   fs_free         166664
#     2022-11-25 23:30:31   fs_size         233681
#     2022-11-25 23:30:31   fw_ver          20221027-101131/v1.12.1-ga9117d3
#     2022-11-25 23:30:31   has_update      false
#     2022-11-25 23:30:31   id              shellyplug-s-kueche
#     2022-11-25 23:30:31   ip              192.168.178.97
#     2022-11-25 23:30:31   mac             4022D882EB8D
#     2022-11-25 23:30:31   meters_1_counters_1 23.730
#     2022-11-25 23:30:31   meters_1_counters_2 23.840
#     2022-11-25 23:30:31   meters_1_counters_3 24.602
#     2022-11-25 23:30:31   meters_1_is_valid true
#     2022-11-25 23:30:31   meters_1_overpower 0.00
#     2022-11-25 23:30:31   meters_1_power  25.07
#     2022-11-25 23:30:31   meters_1_timestamp 1669419031
#     2022-11-25 23:30:31   meters_1_total  963295
#     2022-11-25 23:30:31   model           SHPLG-S
#     2022-11-25 23:30:31   mqtt_connected  true
#     2022-11-25 23:30:31   new_fw          false
#     2022-11-25 23:30:31   online          true
#     2022-11-25 23:30:46   overtemperature 0
#     2022-11-25 23:30:31   ram_free        40160
#     2022-11-25 23:30:31   ram_total       52072
#     2022-11-25 23:30:46   relay0          on
#     2022-11-25 23:30:49   relay_0_energy  963295
#     2022-11-25 23:30:49   relay_0_kWh     16.05
#     2022-11-25 23:30:49   relay_0_power   37.85
#     2022-11-25 23:30:31   relays_1_has_timer false
#     2022-11-25 23:30:31   relays_1_ison   true
#     2022-11-25 23:30:31   relays_1_overpower false
#     2022-11-25 23:30:31   relays_1_source mqtt
#     2022-11-25 23:30:31   relays_1_timer_duration 0
#     2022-11-25 23:30:31   relays_1_timer_remaining 0
#     2022-11-25 23:30:31   relays_1_timer_started 0
#     2022-11-25 23:30:31   serial          38589
#     2022-11-25 23:30:46   state           on
#     2022-11-25 23:30:46   temperature     24.73
#     2022-11-25 23:30:31   time            23:30
#     2022-11-25 23:30:31   tmp_is_valid    true
#     2022-11-25 23:30:31   tmp_tC          24.62
#     2022-11-25 23:30:31   tmp_tF          76.32
#     2022-11-25 23:30:31   unixtime        1669415431
#     2022-11-25 23:30:31   update_has_update false
#     2022-11-25 23:30:31   update_new_version 20221027-101131/v1.12.1-ga9117d3
#     2022-11-25 23:30:31   update_old_version 20221027-101131/v1.12.1-ga9117d3
#     2022-11-25 23:30:31   update_status   idle
#     2022-11-25 23:30:31   uptime          1136644
#     2022-11-25 23:30:31   wifi_sta_connected true
#     2022-11-25 23:30:31   wifi_sta_ip     192.168.178.97
#     2022-11-25 23:30:31   wifi_sta_rssi   -65
#     2022-11-25 23:30:31   wifi_sta_ssid   the New Generation Crawler
#     2022-11-25 23:30:30   x_mqttcom       set announce
#
setstate Schalter_Kueche on
setstate Schalter_Kueche 2022-11-25 23:30:31 actions_stats_skipped 0
setstate Schalter_Kueche 2022-11-25 23:30:30 attrTemplateVersion 20220408
setstate Schalter_Kueche 2022-11-25 23:30:31 cfg_changed_cnt 1
setstate Schalter_Kueche 2022-11-25 23:30:31 cloud_connected false
setstate Schalter_Kueche 2022-11-25 23:30:31 cloud_enabled false
setstate Schalter_Kueche 2022-11-25 23:30:31 fs_free 166664
setstate Schalter_Kueche 2022-11-25 23:30:31 fs_size 233681
setstate Schalter_Kueche 2022-11-25 23:30:31 fw_ver 20221027-101131/v1.12.1-ga9117d3
setstate Schalter_Kueche 2022-11-25 23:30:31 has_update false
setstate Schalter_Kueche 2022-11-25 23:30:31 id shellyplug-s-kueche
setstate Schalter_Kueche 2022-11-25 23:30:31 ip 192.168.178.97
setstate Schalter_Kueche 2022-11-25 23:30:31 mac 4022D882EB8D
setstate Schalter_Kueche 2022-11-25 23:30:31 meters_1_counters_1 23.730
setstate Schalter_Kueche 2022-11-25 23:30:31 meters_1_counters_2 23.840
setstate Schalter_Kueche 2022-11-25 23:30:31 meters_1_counters_3 24.602
setstate Schalter_Kueche 2022-11-25 23:30:31 meters_1_is_valid true
setstate Schalter_Kueche 2022-11-25 23:30:31 meters_1_overpower 0.00
setstate Schalter_Kueche 2022-11-25 23:30:31 meters_1_power 25.07
setstate Schalter_Kueche 2022-11-25 23:30:31 meters_1_timestamp 1669419031
setstate Schalter_Kueche 2022-11-25 23:30:31 meters_1_total 963295
setstate Schalter_Kueche 2022-11-25 23:30:31 model SHPLG-S
setstate Schalter_Kueche 2022-11-25 23:30:31 mqtt_connected true
setstate Schalter_Kueche 2022-11-25 23:30:31 new_fw false
setstate Schalter_Kueche 2022-11-25 23:30:31 online true
setstate Schalter_Kueche 2022-11-25 23:30:46 overtemperature 0
setstate Schalter_Kueche 2022-11-25 23:30:31 ram_free 40160
setstate Schalter_Kueche 2022-11-25 23:30:31 ram_total 52072
setstate Schalter_Kueche 2022-11-25 23:30:46 relay0 on
setstate Schalter_Kueche 2022-11-25 23:30:49 relay_0_energy 963295
setstate Schalter_Kueche 2022-11-25 23:30:49 relay_0_kWh 16.05
setstate Schalter_Kueche 2022-11-25 23:30:49 relay_0_power 37.85
setstate Schalter_Kueche 2022-11-25 23:30:31 relays_1_has_timer false
setstate Schalter_Kueche 2022-11-25 23:30:31 relays_1_ison true
setstate Schalter_Kueche 2022-11-25 23:30:31 relays_1_overpower false
setstate Schalter_Kueche 2022-11-25 23:30:31 relays_1_source mqtt
setstate Schalter_Kueche 2022-11-25 23:30:31 relays_1_timer_duration 0
setstate Schalter_Kueche 2022-11-25 23:30:31 relays_1_timer_remaining 0
setstate Schalter_Kueche 2022-11-25 23:30:31 relays_1_timer_started 0
setstate Schalter_Kueche 2022-11-25 23:30:31 serial 38589
setstate Schalter_Kueche 2022-11-25 23:30:46 state on
setstate Schalter_Kueche 2022-11-25 23:30:46 temperature 24.73
setstate Schalter_Kueche 2022-11-25 23:30:31 time 23:30
setstate Schalter_Kueche 2022-11-25 23:30:31 tmp_is_valid true
setstate Schalter_Kueche 2022-11-25 23:30:31 tmp_tC 24.62
setstate Schalter_Kueche 2022-11-25 23:30:31 tmp_tF 76.32
setstate Schalter_Kueche 2022-11-25 23:30:31 unixtime 1669415431
setstate Schalter_Kueche 2022-11-25 23:30:31 update_has_update false
setstate Schalter_Kueche 2022-11-25 23:30:31 update_new_version 20221027-101131/v1.12.1-ga9117d3
setstate Schalter_Kueche 2022-11-25 23:30:31 update_old_version 20221027-101131/v1.12.1-ga9117d3
setstate Schalter_Kueche 2022-11-25 23:30:31 update_status idle
setstate Schalter_Kueche 2022-11-25 23:30:31 uptime 1136644
setstate Schalter_Kueche 2022-11-25 23:30:31 wifi_sta_connected true
setstate Schalter_Kueche 2022-11-25 23:30:31 wifi_sta_ip 192.168.178.97
setstate Schalter_Kueche 2022-11-25 23:30:31 wifi_sta_rssi -65
setstate Schalter_Kueche 2022-11-25 23:30:31 wifi_sta_ssid the New Generation Crawler
setstate Schalter_Kueche 2022-11-25 23:30:30 x_mqttcom set announce

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: OdfFhem am 26 November 2022, 07:44:35
Zitat von: Crawler am 25 November 2022, 23:31:59
durch das ändern des templates und löschen aller readings hat sich jetzt nicht soviel getan
- temperature_f ist jetzt "geerdet"
- ein Reading namens relay_0_energy_total wird gefüllt - beim (zu frühen) "Copy"-Ergebnis noch nicht sichtbar
- devStateIcon zeigt jetzt auch Momentan/Gesamt-Verbrauch an
- ...
- Template stellt eine Grundeinrichtung bereit, die man im Zweifel selbst verfeinern muss


Die folgende - "u.a. doppelte Readings erzeugende" - Zeile ist offensichtlich nicht Bestandteil vom Template; wird also beim ersten Auftreten der MQTT-message info autom. ergänzt. Muss somit im Zweifel/bei Nichtgefallen noch verfeinert werden. CID (shellyplug_s_4022D882EB8D) entfernen ... zu generierende Readings beeinflussen ...
shellyplug_s_4022D882EB8D:shellies/shellyplug-s-kueche/info:.* { json2nameValue($EVENT) }

Ich würde - wie schon in einem Beitrag weiter oben angedeutet - folgende Anpassung vornehmen ... (zusätzliche) Readings sollen mit info_ beginnen ...
shellies/shellyplug-s-kueche/info:.* { json2nameValue($EVENT,'info_') }
Alternativ könnte man info aber auch erden - ähnlich zu temperature_f ... es werden keine (zusätzlichen) Readings angelegt ...
shellies/shellyplug-s-kueche/info:.* {}
Eine weitere der vielen Möglichkeiten wäre, dass man nur bestimmte Readings (zusätzlich) anlegen möchte:
... u.a. durch Übergabe weiterer Parameter an json2nameValue ... z.B. https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt#json2nameValue.28.29 (https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt#json2nameValue.28.29)

Bis man das gewünschte Ergebnis erhält, muss man im Zweifel mehrfach anpassen und testen ...
Bzgl. info könnte/sollte man abschließend auch noch einen Vorschlag zur Template-Anpassung machen ...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Joesky am 27 November 2022, 11:12:15
Hat jemand schon den Shelly Plus 2pm als Schaltaktor eingebunden? In den Templates hab ich nur "Shelly Plus 2 PM in Roller-Mode" gefunden. Ich schaffe es nicht ihn vernünftig anzubinden. Das Shelly FHEM-Modul kann leider auch nur einen Schalter bedienen.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: thetornado76 am 10 Januar 2023, 13:38:20
Zitat von: Joesky am 27 November 2022, 11:12:15
Hat jemand schon den Shelly Plus 2pm als Schaltaktor eingebunden? In den Templates hab ich nur "Shelly Plus 2 PM in Roller-Mode" gefunden. Ich schaffe es nicht ihn vernünftig anzubinden. Das Shelly FHEM-Modul kann leider auch nur einen Schalter bedienen.
Hallo Joesky,
falls Du es noch nicht gesehen hast. Es gibt ein neues Template für den Shellyplus 2PM "shellyPlus_2pm_split"
Damit kann ich meinen Shelly schalten und bekomme von beiden Kanälen den Verbrauch gemeldet.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Motivierte linke Hände am 31 Januar 2023, 11:58:59
Tach. Ich hab einen neuen Freund der Gattung Plus 2PM. Soll ein Fenster öffnen und schließen. Kann er auch im WebIf von Shelly und per angeschlossenem Taster. Nun würde ich das Fenster gerne auch über FHEM steuern können. Die Kalibrierung im Shelly geht nicht, weil die Lasten des Öffners zu gering sind. Also ist der Shelly über Zeiten zum Öffnen und Schließen kalibriert.

Ich habe auch "Generic status update over MQTT" im Shelly aktiviert. Daraufhin fand ich 2 neue Devices im Raum MQTT2_DEVICE: MQTT2_events und MQTT2_status. Testweise habe ich mal beiden das Template shellyPlus_2pm_roller_invert_0 zugewiesen (ich bräucht vmtl. ein invert_1, aber mit den Details befasse ich mich später).

MQTT2_status:

Internals:
   CID        status
   DEF        status
   FUUID      63d8eb3c-f33f-e1ef-91fe-0c71d9a971fe60f4
   IODev      myBroker
   LASTInputDev myBroker
   MSGCNT     80
   NAME       MQTT2_status
   NR         1164
   STATE      online
pct
   TYPE       MQTT2_DEVICE
   eventCount 92
   myBroker_MSGCNT 80
   myBroker_TIME 2023-01-31 11:48:59
   JSONMAP:
     status_current_pos pct
     status_state state
     status_temperature_tC temperature
   OLDREADINGS:
   READINGS:
     2023-01-31 11:25:11   IODev           myBroker
     2023-01-31 11:44:29   associatedWith  MQTT2_myBroker
     2023-01-31 11:26:30   attrTemplateVersion 20220623
     2023-01-31 11:48:59   cover_0_aenergy_by_minute_1 0.000
     2023-01-31 11:48:59   cover_0_aenergy_by_minute_2 0.000
     2023-01-31 11:48:59   cover_0_aenergy_by_minute_3 0.000
     2023-01-31 11:48:59   cover_0_aenergy_minute_ts 1675162139
     2023-01-31 11:48:59   cover_0_aenergy_total 0.188
     2023-01-31 11:48:59   cover_0_apower  0.0
     2023-01-31 11:48:59   cover_0_current 0.000
     2023-01-31 11:48:59   cover_0_id      0
     2023-01-31 11:45:30   cover_0_move_started_at 1675161918.37
     2023-01-31 11:45:30   cover_0_move_timeout 13.00
     2023-01-31 11:48:59   cover_0_pf      0.00
     2023-01-31 11:48:59   cover_0_pos_control false
     2023-01-31 11:48:59   cover_0_source  timeout
     2023-01-31 11:48:59   cover_0_state   closed
     2023-01-31 11:48:59   cover_0_temperature_tC 39.8
     2023-01-31 11:48:59   cover_0_temperature_tF 103.7
     2023-01-31 11:48:59   cover_0_voltage 236.5
     2023-01-31 11:44:29   input_0_id      0
     2023-01-31 11:34:42   input_0_state   false
     2023-01-31 11:44:30   input_1_id      1
     2023-01-31 11:34:30   input_1_state   false
     2023-01-31 11:45:56   rpc_id          0
     2023-01-31 11:45:56   rpc_method      Cover.Open
     2023-01-31 11:45:56   rpc_params_id   0
     2023-01-31 11:45:56   rpc_src         fhem2shelly
     2023-01-31 11:45:56   state           set_open
     2023-01-31 11:44:30   sys_cfg_rev     20
     2023-01-31 11:44:30   sys_fs_free     110592
     2023-01-31 11:44:30   sys_fs_size     458752
     2023-01-31 11:44:30   sys_kvs_rev     0
     2023-01-31 11:44:30   sys_mac         C049EF8584DC
     2023-01-31 11:44:30   sys_ram_free    151492
     2023-01-31 11:44:30   sys_ram_size    233268
     2023-01-31 11:44:30   sys_restart_required false
     2023-01-31 11:44:30   sys_schedule_rev 0
     2023-01-31 11:44:30   sys_time        11:44
     2023-01-31 11:44:30   sys_unixtime    1675161870
     2023-01-31 11:44:30   sys_uptime      1486
     2023-01-31 11:44:30   sys_webhook_rev 0
Attributes:
   cmdIcon    open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
   comment    Shelly Plus 2 PM in Roller-Mode. 100=opened / 0=closed
   devStateIcon opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0:fts_shutter_100 100:fts_shutter_10 9\d:fts_shutter_10 8\d:fts_shutter_20 7\d:fts_shutter_30 6\d:fts_shutter_40 5\d:fts_shutter_50 4\d:fts_shutter_60 3\d:fts_shutter_70 2\d:fts_shutter_80 1\d:fts_shutter_90 0\d:fts_shutter_100 set_.*:fts_shutter_updown
   devicetopic shellies/status
   genericDeviceType blind
   icon       fts_shutter
   jsonMap    status_state:state status_current_pos:pct status_temperature_tC:temperature
   model      shellyPlus_2pm_roller_invert_0
   readingList $DEVICETOPIC/online:.* online
  $DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }
  $DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }
  $DEVICETOPIC/status/cover_0:.* { json2nameValue($EVENT, 'status_', $JSONMAP) }
  fhem2shelly/rpc:.* {}
shellies/status/cover_0:.* { json2nameValue($EVENT, 'cover_0_', $JSONMAP) }
shellies/status/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
shellies/status/input_1:.* { json2nameValue($EVENT, 'input_1_', $JSONMAP) }
shellies/status/input_0:.* { json2nameValue($EVENT, 'input_0_', $JSONMAP) }
shellies/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }
   room       MQTT2_DEVICE
   setList    open:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.Open","params": {"id":0}}
  close:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.Close","params": {"id":0}}
  half:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.GoToPosition","params": {"id":0,"pos":50}}
  stop:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.Stop","params": {"id":0}}
  pct:slider,0,1,100 $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.GoToPosition","params": {"id":0,"pos":$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"}
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
   setStateList open close half stop pct
   stateFormat online
pct
   webCmd     :open:close:half:stop:pct


MQTT2_events:


Internals:
   CID        events
   DEF        events
   FUUID      63d8eb8b-f33f-e1ef-f301-74ee489e2c2000f2
   IODev      myBroker
   LASTInputDev myBroker
   MSGCNT     89
   NAME       MQTT2_events
   NR         1166
   STATE      online
pct
   TYPE       MQTT2_DEVICE
   eventCount 94
   myBroker_MSGCNT 89
   myBroker_TIME 2023-01-31 11:53:00
   JSONMAP:
     status_current_pos pct
     status_state state
     status_temperature_tC temperature
   OLDREADINGS:
   READINGS:
     2023-01-31 11:25:11   IODev           myBroker
     2023-01-31 11:52:54   associatedWith  MQTT2_myBroker
     2023-01-31 11:52:22   attrTemplateVersion 20220623
     2023-01-31 11:52:59   rpc_dst         shellies/events
     2023-01-31 11:53:00   rpc_id          0
     2023-01-31 11:53:00   rpc_method      Cover.Open
     2023-01-31 11:52:59   rpc_params_cover_0_aenergy_by_minute_1 0.000
     2023-01-31 11:52:59   rpc_params_cover_0_aenergy_by_minute_2 0.000
     2023-01-31 11:52:59   rpc_params_cover_0_aenergy_by_minute_3 0.000
     2023-01-31 11:52:59   rpc_params_cover_0_aenergy_minute_ts 1675162379
     2023-01-31 11:52:59   rpc_params_cover_0_aenergy_total 0.188
     2023-01-31 11:52:59   rpc_params_cover_0_id 0
     2023-01-31 11:53:00   rpc_params_id   0
     2023-01-31 11:52:59   rpc_params_ts   1675162380.02
     2023-01-31 11:53:00   rpc_src         fhem2shelly
     2023-01-31 11:53:00   state           set_open
Attributes:
   cmdIcon    open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
   comment    Shelly Plus 2 PM in Roller-Mode. 100=opened / 0=closed
   devStateIcon opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 0:fts_shutter_100 100:fts_shutter_10 9\d:fts_shutter_10 8\d:fts_shutter_20 7\d:fts_shutter_30 6\d:fts_shutter_40 5\d:fts_shutter_50 4\d:fts_shutter_60 3\d:fts_shutter_70 2\d:fts_shutter_80 1\d:fts_shutter_90 0\d:fts_shutter_100 set_.*:fts_shutter_updown
   devicetopic shellies/events
   genericDeviceType blind
   icon       fts_shutter
   jsonMap    status_state:state status_current_pos:pct status_temperature_tC:temperature
   model      shellyPlus_2pm_roller_invert_0
   readingList $DEVICETOPIC/online:.* online
  $DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }
  $DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }
  $DEVICETOPIC/status/cover_0:.* { json2nameValue($EVENT, 'status_', $JSONMAP) }
  fhem2shelly/rpc:.* {}
shellies/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
   room       MQTT2_DEVICE
   setList    open:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.Open","params": {"id":0}}
  close:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.Close","params": {"id":0}}
  half:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.GoToPosition","params": {"id":0,"pos":50}}
  stop:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.Stop","params": {"id":0}}
  pct:slider,0,1,100 $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Cover.GoToPosition","params": {"id":0,"pos":$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"}
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
   setStateList open close half stop pct
   stateFormat online
pct
   webCmd     :open:close:half:stop:pct


Mein Problem ist nun: set open und set close funktionieren nicht - sie bewirken gar nichts. Es ist auch kein Relaisschalten zu hören.

Hat jemand einen Plus 2PM an Rollo, Jalousie, Fenster erfolgreich laufen und könnte einen Tipp geben, wo ich mal schrauben sollte?

Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Icke am 10 Februar 2023, 23:41:54
Guten Tag liebe Gemeinschaft.

Ich habe mir soeben voller elan einen ShellyplusH&T zugelegt und durfte feststellen das dieser quasi null für den einfachen User implementiert ist 🙈.
Ich habe es nicht einmal geschafft die abgesetzten nachrichten abzugreifen...

Ist an dieser stelle ggf. Schon jemand soweit das er zumindest die Temp. im MQTT2_DEVICE ausspuckt?

Sorry und Danke
Icke ;-)
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gameshacker am 06 März 2023, 12:47:16
Hallo,

Leider habe ich dasselbe Problem wie mein Vorredner.
Für den  Shelly Plus HT gibt es leider noch kein Template zum auswählen.

Leider kann man den einfachen HT auch nicht auswählen, da nur noch Shelly Plus Geräte angezeigt werden.

Grüße
Gameshacker
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 06 März 2023, 13:14:19
Hallo ihr zwei.

Ohne Info (v.a.: was kam denn in FHEM an, wie sieht das ggf. angelegte MQTT2_DEVICE denn aus (raw-list)?!?) kann vermutlich nur weiterhelfen, wer das Gerät hat und mit dem (vermutlich) sonderbaren Datenformat was anfangen kann, in dem das Teil sendet.

Kurz - siehe angepinnten Thread: was liefern?...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gameshacker am 06 März 2023, 16:21:08
Hallo zusammen, gerne kann ich die Infos zur Verfügung stellen.

Das Problem ist, wie ich schon geschrieben habe Das Gerät wird erkannt, aber es gibt noch kein Template. Ich denke es müsste eigentlich dem Shelly HT entsprechen.
Vermutlich durch das Plus werden nur Shelly Plus Geräte zur Auswahl angeboten. 

Es handelt sich hier um ein Shelly PlusHT  https://www.shelly.cloud/de/products/product-overview/shelly-plus-h-t (https://www.shelly.cloud/de/products/product-overview/shelly-plus-h-t)
Ich habe MQTT direkt an Fhem mit MQTT2_SERVER konfiguriert und läuft auch hervorragend mit mehreren Shelly und Tasmota Devices.

Erkannt und eingebunden wurde es als MQTT2_DEVICE
Autocreate ist konfiguriert und funktioniert ja auch.




list -r MQTT2_thermometer


define MQTT2_thermometer MQTT2_DEVICE thermometer
attr MQTT2_thermometer readingList thermometer:shelly/online:.* online\
thermometer:shelly/status/ble:.* ble\
thermometer:shelly/status/cloud:.* { json2nameValue($EVENT, 'cloud_', $JSONMAP) }\
thermometer:shelly/status/devicepower_0:.* { json2nameValue($EVENT, 'devicepower_0_', $JSONMAP) }\
thermometer:shelly/status/ht_ui:.* ht_ui\
thermometer:shelly/status/humidity_0:.* { json2nameValue($EVENT, 'humidity_0_', $JSONMAP) }\
thermometer:shelly/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }\
thermometer:shelly/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }\
thermometer:shelly/status/temperature_0:.* { json2nameValue($EVENT, 'temperature_0_', $JSONMAP) }\
thermometer:shelly/status/wifi:.* { json2nameValue($EVENT, 'wifi_', $JSONMAP) }\
thermometer:shelly/status/ws:.* { json2nameValue($EVENT, 'ws_', $JSONMAP) }\
thermometer:shelly/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
attr MQTT2_thermometer room MQTT2_DEVICE



Ich hoffe das reicht als Infos, bei Fragen stehe ich gerne zur Verfügung.

Vielen Dank und Viele Grüße
Gameshacker

Achso Updates werden bei mir Wöchentlich durchgeführt.
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 06 März 2023, 18:07:54
Zitat von: gameshacker am 06 März 2023, 16:21:08
Ich denke es müsste eigentlich dem Shelly HT entsprechen.
Um was wollen wir wetten, dass du falsch liegst?!?

"Plus" meint in der Regel, dass es "gen2"-Geräte sind, und die ticken komplett anders, Einstieg über https://shelly-api-docs.shelly.cloud/, da landet man in etwa dann da:
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Temperature/

In dem Fall ist es gut, dass du "complex" als autocreate-Einstellung gewählt zu haben scheinst, interessiert hätten mich noch die "rpc_"-Readings, oder du fängst mal den JSON-Blob ein, der darüber kommen müßte (sollte im Wiki unter "Schritt für Schritt" zu finden sein, wie das geht).

OT: Die werden immer komischer, diese Shelly...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gameshacker am 07 März 2023, 09:15:30
Hallo
ok, das mit dem Json-Blob muss ich mich nocheinmal anschauen,
aber die Readings kann ich dir gerne schonmal geben


....
setstate MQTT2_thermometer 2023-03-07 08:21:04 rpc_dst shelly/events
setstate MQTT2_thermometer 2023-03-07 08:21:04 rpc_method NotifyEvent
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_cloud_connected false
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_devicepower_0_battery_V 5.84
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_devicepower_0_battery_percent 92
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_devicepower_0_external_present false
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_devicepower_0_id 0
setstate MQTT2_thermometer 2023-03-07 08:21:04 rpc_params_events_1_component sys
setstate MQTT2_thermometer 2023-03-07 08:21:04 rpc_params_events_1_event sleep
setstate MQTT2_thermometer 2023-03-07 08:21:04 rpc_params_events_1_ts 1678173664.99
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_humidity_0_id 0
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_humidity_0_rh 44.7
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_mqtt_connected true
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_cfg_rev 14
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_fs_free 114688
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_fs_size 458752
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_kvs_rev 0
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_mac XXXXXXXXXXXX
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_ram_free 146940
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_ram_size 249692
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_restart_required false
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_uptime 1
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_wakeup_period 7200
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_wakeup_reason_boot deepsleep_wake
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_wakeup_reason_cause periodic
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_sys_webhook_rev 0
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_temperature_0_id 0
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_temperature_0_tC 20.3
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_temperature_0_tF 68.6
setstate MQTT2_thermometer 2023-03-07 08:21:04 rpc_params_ts 1678173664.99
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_wifi_rssi -57
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_wifi_ssid xxxxxxxxx
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_wifi_sta_ip x.x.x.x
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_wifi_status got ip
setstate MQTT2_thermometer 2023-03-07 08:21:03 rpc_params_ws_connected false
setstate MQTT2_thermometer 2023-03-07 08:21:04 rpc_src shellyplusht-XXXXXXXXXXXX
setstate MQTT2_thermometer 2023-03-01 14:40:42 subscriptions shelly/rpc
....


Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 07 März 2023, 11:12:34
Zitat von: Icke am 10 Februar 2023, 23:41:54
Ist an dieser stelle ggf. Schon jemand soweit das er zumindest die Temp. im MQTT2_DEVICE ausspuckt?
In den Readings von gameshacker sind jedenfalls sowohl die Temperatur wie auch die Humidity drin, nur eben unter anderen Namen...

Diese Zeile bitte ändern:
thermometer:shelly/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
inshelly/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }Bzw.: Es ist komisch, dass da nicht ein "shellyplus-irgendwas" auftaucht im topic. Falls da was dran geändert wurde: UNBEDINGT wieder zurück auf den default stellen!

Und dann mal einlesen in das jsonMap-Attribut ;) .

Dann warte ich mal auf einen Vorschlag für ein attrTemplate...
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: gameshacker am 07 März 2023, 13:43:49
So also,

Ich habe auch das Gerät komplett resettet, denn hier hatte ich den Namen schon geändert.
auch die Zeile habe ich entsprechend geändert.

Allerdings stehe ich ein bisschen auf dem Schlauch, wie das mit dem einlesen funktioniert.
Ich habe nun auch das JsonMap Attribut gesetzt, ich dhabe die Beispiele in der Href so verstanden.
attr MQTT2_shellyplusht_XXXXXXXXX jsonMap devicepower_0_battery_percent:battery humidity_0_rh:humidity temperature_0_tC:temperature

Wo wird aber nun was angezeigt?

Das list sieht nun so aus:

define MQTT2_shellyplusht_XXXXXXXXX MQTT2_DEVICE shellyplusht_c049ef8b7a8c
attr MQTT2_shellyplusht_XXXXXXXXX jsonMap devicepower_0_battery_percent:battery humidity_0_rh:humidity temperature_0_tC:temperature
attr MQTT2_shellyplusht_XXXXXXXXX readingList shellyplusht_c049ef8b7a8c:shellyplusht-c049ef8b7a8c/online:.* online\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/ble:.* ble\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/cloud:.* { json2nameValue($EVENT, 'cloud_', $JSONMAP) }\shellyplusht_XXXXXXXXX
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/devicepower_0:.* { json2nameValue($EVENT, 'devicepower_0_', $JSONMAP) }\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/ht_ui:.* ht_ui\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/humidity_0:.* { json2nameValue($EVENT, 'humidity_0_', $JSONMAP) }\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/temperature_0:.* { json2nameValue($EVENT, 'temperature_0_', $JSONMAP) }\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/wifi:.* { json2nameValue($EVENT, 'wifi_', $JSONMAP) }\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/status/ws:.* { json2nameValue($EVENT, 'ws_', $JSONMAP) }\
shellyplusht_XXXXXXXXX:shellyplusht-XXXXXXXXX/events/rpc:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr MQTT2_shellyplusht_XXXXXXXXX room MQTT2_DEVICE
.....
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:32 rpc_dst shellyplusht-XXXXXXXXX/events
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:32 rpc_method NotifyEvent
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_cloud_connected false
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_devicepower_0_battery_V 5.71
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_devicepower_0_battery_percent 85
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_devicepower_0_external_present false
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_devicepower_0_id 0
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:32 rpc_params_events_1_component sys
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:32 rpc_params_events_1_event sleep
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:32 rpc_params_events_1_ts 1678185452.96
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_humidity_0_id 0
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_humidity_0_rh 42.6
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_mqtt_connected true
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_cfg_rev 5
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_fs_free 114688
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_fs_size 458752
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_kvs_rev 0
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_mac XXXXXXXXX
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_ram_free 146828
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_ram_size 249712
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_restart_required false
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_uptime 1
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_wakeup_period 7200
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_wakeup_reason_boot software_restart
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_wakeup_reason_cause undefined
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_sys_webhook_rev 0
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_temperature_0_id 0
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_temperature_0_tC 27.8
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_temperature_0_tF 82.0
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:32 rpc_params_ts 1678185452.96
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_wifi_rssi -46
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_wifi_ssid XXXXXXXXX
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_wifi_sta_ip x.x.x.x
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_wifi_status got ip
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:30 rpc_params_ws_connected false
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 11:37:32 rpc_src shellyplusht-XXXXXXXXX
setstate MQTT2_shellyplusht_XXXXXXXXX 2023-03-07 12:18:21 src shellyplusht-XXXXXXXXX
......


Grüße Gameshacker
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 07 März 2023, 13:50:19
Na ja, wenn du jsonMap verwendest, solltest du auch in "old:new" auf "old" setzen und nicht nur Teile davon. Sonst sieht das schon besser aus...
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: buennerbernd am 30 Mai 2023, 13:25:30
Ich habe einen Shelly PlusPlugS.
Mit dem Template shelly1_w_energy_measuring kommen Werte rein.

Mir ist es allerdings noch nicht gelungen, Werte (speziell den output) per MQTT zu setzen.

Ist das schon jemandem gelungen? Gibt es ein Template, das besser passt?

Danke schon mal im Voraus.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 30 Mai 2023, 14:32:37
Die "plus"-Modelle sind 2nd gen.. Dafür gibt es eine andere attrTemplate-"Linie", die 1er passen nicht!
(Nächster Abschnitt der template-file)
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: buennerbernd am 30 Mai 2023, 15:14:39
Ich habe das Template shellyPlus_1pm ausprobiert.

Die Setter bleiben leider erfolglos.
Die jsonMap scheint leider auch nicht richtig zum Shelly PlusPlugS zu passen.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: buennerbernd am 05 Juni 2023, 14:43:39
Ich nehme an, dass nichts an dem Template so richtig funktioniert, weil bei mir $DEVICETOPIC nicht gesetzt ist.
Müsste ich das nicht in den Internals sehen?

define MQTT2_shellyplusplugs_80646fd60bf4 MQTT2_DEVICE shellyplusplugs_80646fd60bf4
attr MQTT2_shellyplusplugs_80646fd60bf4 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 $cons = ReadingsNum($name,'apower',0);; my $total = round(ReadingsNum($name,'aenergy_total',0)/1000,3);; my $temp = ReadingsVal($name,'temperature','-100');; my $ip = ReadingsVal($name,'ip','none');; my $reb = ReadingsVal($name,'sys_restart_required','false') eq 'true'?'<a href="/fhem?cmd.dummy=set '.$name.' x_reboot&XHR=1"> ... Notwendigen Reboot durchführen</a>':'';; qq(<a href="http://$ip" target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a>$reb<div>Verbrauch: $cons W / Total: $total kwh / Temp: $temp °C</div>)}
attr MQTT2_shellyplusplugs_80646fd60bf4 devicetopic shellyplusplugs
attr MQTT2_shellyplusplugs_80646fd60bf4 getList in_mode:noArg in_mode $DEVICETOPIC/rpc {"id": 1,"src":"$DEVICETOPIC", "method": "Switch.GetConfig", "params": {"id": 0}}
attr MQTT2_shellyplusplugs_80646fd60bf4 icon message_socket
attr MQTT2_shellyplusplugs_80646fd60bf4 jsonMap switch_state:state switch_aenergy_total:aenergy_total switch_apower:apower temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip params_switch_0_temperature_tC:temperature params_switch_0_temperature_tF:0 result_in_mode:in_mode
attr MQTT2_shellyplusplugs_80646fd60bf4 model shellyPlus_1pm
attr MQTT2_shellyplusplugs_80646fd60bf4 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) }\
  $DEVICETOPIC/status/cloud:.* {}\
  $DEVICETOPIC/rpc:.* { json2nameValue($EVENT, 'req_', $JSONMAP, 'in_mode')}\
  $DEVICETOPIC/status/input_0:.* { json2nameValue($EVENT, 'input_', $JSONMAP) }\
  fhem2shelly/rpc:.* {}\
shellyplusplugs_80646fd60bf4:shellyplusplugs-80646fd60bf4/events/rpc:.* { json2nameValue($EVENT) }\
shellyplusplugs_80646fd60bf4:shellyplusplugs-80646fd60bf4/status/switch_0:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplusplugs_80646fd60bf4 room MQTT2_DEVICE
attr MQTT2_shellyplusplugs_80646fd60bf4 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}}\
  off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\
  in_mode:toggle,flip,detached {fhem("sleep 0.2;; get $NAME in_mode");; my $val = $EVTPART1 ne 'toggle' ? $EVTPART1 : ReadingsVal($NAME,'in_mode','flip') eq 'flip' ? 'detached':'flip';; qq($DEVICETOPIC/rpc {"id":1,"src":"fhem2shelly","method":"Switch.SetConfig","params": {"id":0, "config": {"in_mode": "$val"}}})}\
  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"}\
  x_eco:true,false $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
attr MQTT2_shellyplusplugs_80646fd60bf4 setStateList on off toggle on-for-timer off-for-timer
attr MQTT2_shellyplusplugs_80646fd60bf4 webCmd :

setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:25:37 IODev MQTTBroker
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 aenergy_by_minute_1 0.000
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 aenergy_by_minute_2 0.000
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 aenergy_by_minute_3 0.000
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 aenergy_minute_ts 1685969159
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 aenergy_total 406.372
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 apower 0.0
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:26:25 attrTemplateVersion 20220303
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 current 0.000
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 dst shellyplusplugs-80646fd60bf4/events
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 id 0
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 method NotifyStatus
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 output true
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 params_switch_0_aenergy_by_minute_1 0.000
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 params_switch_0_aenergy_by_minute_2 0.000
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 params_switch_0_aenergy_by_minute_3 0.000
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 params_switch_0_aenergy_minute_ts 1685969159
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 params_switch_0_aenergy_total 406.372
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 params_switch_0_id 0
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 params_ts 1685969160.97
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 source http
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 src shellyplusplugs-80646fd60bf4
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 temperature_tC 30.1
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 temperature_tF 86.1
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:46:00 voltage 235.6
setstate MQTT2_shellyplusplugs_80646fd60bf4 2023-06-05 14:26:25 x_reboot set

Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 05 Juni 2023, 17:32:25
Es ist gesetzt, aber der Bindestrich und die darauf folgende chip-id fehlen m.E.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: buennerbernd am 06 Juni 2023, 10:10:41
Danke, ich nähere mich an.
Ich habe das Attribut devicetopic entdeckt und auf shellyplusplugs-80646fd60bf4 gesetzt.
Die Setter on, off, toggle über rpc/ gehen jetzt.
Das Reading state geht jetzt auch. Ein großer Schritt nach vorn.

Alles was unter getList und jsonMap steht scheint aber weiterhin nicht zu funktionieren.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Motivierte linke Hände am 18 Juni 2023, 20:16:52
Ich habe hier einen Shelly pro 3EM, den ich gerade mal einzubinden versuche. Besonders weit bin ich nicht (oder vielleicht doch). Readings kommen grundsätzlich (außer "online", da kommt zwar per MQTT der Wert, aber der taucht als Reading nicht auf):

Internals:
  CFGFN     
  CID        Shelly-WPumpe
  DEF        Shelly-WPumpe
  FUUID      648f1b86-f33f-e1ef-97b1-c507d41cc2f594a9
  IODev      myBroker
  LASTInputDev myBroker
  MSGCNT    8148
  NAME      MQTT2_Shelly_WPumpe
  NR        12531
  STATE      P1: -0.0 W / Total P1: 0.1 kWh<br>P2: -0.0 W / Total P2: 0.0 kWh<br>P3: -0.1 W / Total P3: 0.1 kWh
  TYPE      MQTT2_DEVICE
  eventCount 8154
  myBroker_MSGCNT 8148
  myBroker_TIME 2023-06-18 20:14:43
  OLDREADINGS:
  READINGS:
    2023-06-18 16:58:14  IODev          myBroker
    2023-06-18 19:51:00  associatedWith  MQTT2_myBroker
    2023-06-18 20:14:43  em_0_a_act_power -0.0
    2023-06-18 20:14:43  em_0_a_aprt_power 0.0
    2023-06-18 20:14:43  em_0_a_current  0.028
    2023-06-18 20:14:43  em_0_a_pf      1.00
    2023-06-18 20:14:43  em_0_a_voltage  0.1
    2023-06-18 20:14:43  em_0_b_act_power -0.0
    2023-06-18 20:14:43  em_0_b_aprt_power 0.0
    2023-06-18 20:14:43  em_0_b_current  0.027
    2023-06-18 20:14:43  em_0_b_pf      1.00
    2023-06-18 20:14:43  em_0_b_voltage  0.1
    2023-06-18 20:14:43  em_0_c_act_power -0.1
    2023-06-18 20:14:43  em_0_c_aprt_power 6.4
    2023-06-18 20:14:43  em_0_c_current  0.027
    2023-06-18 20:14:43  em_0_c_pf      1.00
    2023-06-18 20:14:43  em_0_c_voltage  238.5
    2023-06-18 20:14:43  em_0_errors_1  no_load
    2023-06-18 20:14:43  em_0_id        0
    2023-06-18 20:14:43  em_0_total_act_power -0.151
    2023-06-18 20:14:43  em_0_total_aprt_power 6.359
    2023-06-18 20:14:43  em_0_total_current 0.081
    2023-06-18 20:14:00  emdata_0_a_total_act_energy 62.59
    2023-06-18 20:14:00  emdata_0_a_total_act_ret_energy 0.00
    2023-06-18 20:14:00  emdata_0_b_total_act_energy 20.55
    2023-06-18 20:14:00  emdata_0_b_total_act_ret_energy 0.00
    2023-06-18 20:14:00  emdata_0_c_total_act_energy 62.62
    2023-06-18 20:14:00  emdata_0_c_total_act_ret_energy 0.00
    2023-06-18 20:14:00  emdata_0_id    0
    2023-06-18 20:14:00  emdata_0_total_act 145.76
    2023-06-18 20:14:00  emdata_0_total_act_ret 0.00
    2023-06-18 20:14:43  rpc_dst        shellies/Shelly-WPumpe/events
    2023-06-18 20:14:43  rpc_method      NotifyStatus
    2023-06-18 20:14:43  rpc_params_em_0_a_act_power -0.0
    2023-06-18 20:14:43  rpc_params_em_0_a_aprt_power 0.0
    2023-06-18 20:14:43  rpc_params_em_0_a_current 0.028
    2023-06-18 20:14:43  rpc_params_em_0_a_pf 1.00
    2023-06-18 20:14:43  rpc_params_em_0_a_voltage 0.1
    2023-06-18 20:14:43  rpc_params_em_0_b_act_power -0.0
    2023-06-18 20:14:43  rpc_params_em_0_b_aprt_power 0.0
    2023-06-18 20:14:43  rpc_params_em_0_b_current 0.027
    2023-06-18 20:14:43  rpc_params_em_0_b_pf 1.00
    2023-06-18 20:14:43  rpc_params_em_0_b_voltage 0.1
    2023-06-18 20:14:43  rpc_params_em_0_c_act_power -0.1
    2023-06-18 20:14:43  rpc_params_em_0_c_aprt_power 6.4
    2023-06-18 20:14:43  rpc_params_em_0_c_current 0.027
    2023-06-18 20:14:43  rpc_params_em_0_c_pf 1.00
    2023-06-18 20:14:43  rpc_params_em_0_c_voltage 238.5
    2023-06-18 20:14:43  rpc_params_em_0_id 0
    2023-06-18 20:14:43  rpc_params_em_0_total_act_power -0.151
    2023-06-18 20:14:43  rpc_params_em_0_total_aprt_power 6.359
    2023-06-18 20:14:43  rpc_params_em_0_total_current 0.081
    2023-06-18 20:14:00  rpc_params_emdata_0_a_total_act_energy 62.59
    2023-06-18 20:14:00  rpc_params_emdata_0_a_total_act_ret_energy 0.00
    2023-06-18 20:14:00  rpc_params_emdata_0_b_total_act_energy 20.55
    2023-06-18 20:14:00  rpc_params_emdata_0_b_total_act_ret_energy 0.00
    2023-06-18 20:14:00  rpc_params_emdata_0_c_total_act_energy 62.62
    2023-06-18 20:14:00  rpc_params_emdata_0_c_total_act_ret_energy 0.00
    2023-06-18 20:14:00  rpc_params_emdata_0_id 0
    2023-06-18 20:14:00  rpc_params_emdata_0_total_act 145.76
    2023-06-18 20:14:00  rpc_params_emdata_0_total_act_ret 0.00
    2023-06-18 20:14:00  rpc_params_events_1_component emdata:0
    2023-06-18 20:14:00  rpc_params_events_1_data_period 60
    2023-06-18 20:14:00  rpc_params_events_1_data_ts 1687111980
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_1 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_10 0.0
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_11 0.076
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_12 0.071
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_13 0.073
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_14 0.029
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_15 0.027
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_16 0.028
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_17 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_18 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_19 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_2 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_20 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_21 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_22 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_23 0.0
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_24 -0.0
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_25 0.0
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_26 0.0
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_27 0.078
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_28 0.072
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_29 0.075
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_3 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_30 0.028
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_31 0.026
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_32 0.027
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_33 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_34 0.0001
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_35 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_36 0.0003
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_37 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_38 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_39 0.5
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_4 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_40 -0.3
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_41 6.7
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_42 6.3
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_43 238.645
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_44 236.979
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_45 238.289
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_46 0.028
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_47 0.027
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_48 0.027
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_49 0.028
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_5 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_50 0.026
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_51 0.028
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_6 0.0000
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_7 0.0
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_8 -0.0
    2023-06-18 20:14:00  rpc_params_events_1_data_values_1_9 0.0
    2023-06-18 20:14:00  rpc_params_events_1_event data
    2023-06-18 20:14:00  rpc_params_events_1_id 0
    2023-06-18 20:14:00  rpc_params_events_1_ts 1687111980.00
    2023-06-18 20:14:43  rpc_params_ts  1687112081.70
    2023-06-18 20:14:43  rpc_src        shellypro3em-0cb815fce6c0
Attributes:
  readingList $DEVICETOPIC/online:.* online
$DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
shellies/Shelly-WPumpe/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
shellies/Shelly-WPumpe/status/em_0:.* { json2nameValue($EVENT, 'em_0_', $JSONMAP) }
shellies/Shelly-WPumpe/status/emdata_0:.* { json2nameValue($EVENT, 'emdata_0_', $JSONMAP) }
  room      MQTT2_DEVICE
  stateFormat { my $cons1 = ReadingsVal($name,'em_0_a_act_power',0); my $cons2 = ReadingsVal($name,'em_0_b_act_power',0); my $cons3 = ReadingsVal($name,'em_0_c_act_power',0); my $total1 = round(ReadingsNum($name,'emdata_0_a_total_act_energy',0)/1000,1); my $total2 = round(ReadingsNum($name,'emdata_0_b_total_act_energy',0)/1000,1); my $total3 = round(ReadingsNum($name,'emdata_0_c_total_act_energy',0)/1000,1); return qq(P1: $cons1 W / Total P1: $total1 kWh<br>P2: $cons2 W / Total P2: $total2 kWh<br>P3: $cons3 W / Total P3: $total3 kWh) }

Schalten kann der pro 3EM nicht. Die/eine Frage ist, ob man die Readings so belassen oder vielleicht umbenennen sollte, damit es besser zu den 3EMs passt...?

Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Alcamar am 02 Juli 2023, 23:43:30
Hallo,

bin auch gerade etwas verloren.
Ich habe auch einen Shelly pro 3EM, der über LAN fleißig seine Messdaten an fhem sendet.
Leider kommen die readings in fhem anders an, als ich sie erwarten würde. Die Namen haben einen "Präfix" Params_em_...
Die Messwerte lassen sich zwar inhaltlich den einzelnen Phasen (a,b,c) zuordnen, und die Totals stimmen auf dem ersten Blick. Aber die Bezeichner sind völlig andere als ich in Postings im Forum finde. Wenn ich als attrTemplate shelly3em wähle, passt natürlich die Zuordnung dann gar nicht mehr.

Hat jemand einen Hinweis für mich? Wo lassen sich die ankommenden Readings-Beichner steuern?

Liegt das Problem am Settings des Shellys oder an fhem?
Beim Setting des Shelly selbst habe ich einen Eintrag gemacht, der mir nicht verständlich ist:
MQTT PREFIX, den ich mit "ShellyPro" gefüllt habe.



Internals:
   CFGFN     
   CID        ShellyPro
   DEF        ShellyPro
   FUUID      64a1e25f-f33f-82e0-e42e-955e9ad1ef781b50
   IODev      mqtt2s
   LASTInputDev mqtt2s
   MSGCNT     627
   NAME       MQTT2_ShellyPro
   NR         1901
   STATE      Relay: off,<br>P1: 0 W / Total P1: 0 kWh<br>P2: 0 W / Total P2: 0 kWh<br>P3: 0 W / Total P3: 0 kWh
   TYPE       MQTT2_DEVICE
   eventCount 636
   mqtt2s_CONN mqtt2s_192.168.3.30_58439
   mqtt2s_MSGCNT 627
   mqtt2s_TIME 2023-07-02 23:03:23
   OLDREADINGS:
   READINGS:
     2023-07-02 22:47:27   IODev           mqtt2s
     2023-07-02 23:03:23   a_act_power     5.9
     2023-07-02 23:03:23   a_aprt_power    82.3
     2023-07-02 23:03:23   a_current       0.346
     2023-07-02 23:03:23   a_pf            -0.52
     2023-07-02 23:03:00   a_total_act_energy 3053.59
     2023-07-02 23:03:00   a_total_act_ret_energy 0.00
     2023-07-02 23:03:23   a_voltage       237.6
     2023-07-02 22:58:06   attrTemplateVersion 20220109
     2023-07-02 23:03:23   b_act_power     378.6
     2023-07-02 23:03:23   b_aprt_power    445.5
     2023-07-02 23:03:23   b_current       1.872
     2023-07-02 23:03:23   b_pf            -0.87
     2023-07-02 23:03:00   b_total_act_energy 39100.44
     2023-07-02 23:03:00   b_total_act_ret_energy 0.00
     2023-07-02 23:03:23   b_voltage       237.6
     2023-07-02 23:03:23   c_act_power     215.1
     2023-07-02 23:03:23   c_aprt_power    274.9
     2023-07-02 23:03:23   c_current       1.149
     2023-07-02 23:03:23   c_pf            -0.82
     2023-07-02 23:03:00   c_total_act_energy 21073.66
     2023-07-02 23:03:00   c_total_act_ret_energy 0.00
     2023-07-02 23:03:23   c_voltage       239.0
     2023-07-02 23:03:23   dst             ShellyPro/events
     2023-07-02 23:03:23   id              0
     2023-07-02 23:03:23   method          NotifyStatus
     2023-07-02 23:03:23   params_em_0_a_act_power 5.9
     2023-07-02 23:03:23   params_em_0_a_aprt_power 82.3
     2023-07-02 23:03:23   params_em_0_a_current 0.346
     2023-07-02 23:03:23   params_em_0_a_pf -0.52
     2023-07-02 23:03:23   params_em_0_a_voltage 237.6
     2023-07-02 23:03:23   params_em_0_b_act_power 378.6
     2023-07-02 23:03:23   params_em_0_b_aprt_power 445.5
     2023-07-02 23:03:23   params_em_0_b_current 1.872
     2023-07-02 23:03:23   params_em_0_b_pf -0.87
     2023-07-02 23:03:23   params_em_0_b_voltage 237.6
     2023-07-02 23:03:23   params_em_0_c_act_power 215.1
     2023-07-02 23:03:23   params_em_0_c_aprt_power 274.9
     2023-07-02 23:03:23   params_em_0_c_current 1.149
     2023-07-02 23:03:23   params_em_0_c_pf -0.82
     2023-07-02 23:03:23   params_em_0_c_voltage 239.0
     2023-07-02 23:03:23   params_em_0_id  0
     2023-07-02 23:03:23   params_em_0_total_act_power 599.591
     2023-07-02 23:03:23   params_em_0_total_aprt_power 802.707
     2023-07-02 23:03:23   params_em_0_total_current 3.368
     2023-07-02 23:03:00   params_emdata_0_a_total_act_energy 3053.59
     2023-07-02 23:03:00   params_emdata_0_a_total_act_ret_energy 0.00
     2023-07-02 23:03:00   params_emdata_0_b_total_act_energy 39100.44
     2023-07-02 23:03:00   params_emdata_0_b_total_act_ret_energy 0.00
     2023-07-02 23:03:00   params_emdata_0_c_total_act_energy 21073.66
     2023-07-02 23:03:00   params_emdata_0_c_total_act_ret_energy 0.00
     2023-07-02 23:03:00   params_emdata_0_id 0
     2023-07-02 23:03:00   params_emdata_0_total_act 63227.69
     2023-07-02 23:03:00   params_emdata_0_total_act_ret 0.00
     2023-07-02 23:03:00   params_events_1_component emdata:0
     2023-07-02 23:03:00   params_events_1_data_period 60
     2023-07-02 23:03:00   params_events_1_data_ts 1688331720
     2023-07-02 23:03:00   params_events_1_data_values_1_1 0.1002
     2023-07-02 23:03:00   params_events_1_data_values_1_10 81.3
     2023-07-02 23:03:00   params_events_1_data_values_1_11 237.749
     2023-07-02 23:03:00   params_events_1_data_values_1_12 237.121
     2023-07-02 23:03:00   params_events_1_data_values_1_13 237.464
     2023-07-02 23:03:00   params_events_1_data_values_1_14 0.347
     2023-07-02 23:03:00   params_events_1_data_values_1_15 0.342
     2023-07-02 23:03:00   params_events_1_data_values_1_16 0.345
     2023-07-02 23:03:00   params_events_1_data_values_1_17 6.2836
     2023-07-02 23:03:00   params_events_1_data_values_1_18 6.3008
     2023-07-02 23:03:00   params_events_1_data_values_1_19 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_2 0.0988
     2023-07-02 23:03:00   params_events_1_data_values_1_20 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_21 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_22 2.6393
     2023-07-02 23:03:00   params_events_1_data_values_1_23 386.3
     2023-07-02 23:03:00   params_events_1_data_values_1_24 371.5
     2023-07-02 23:03:00   params_events_1_data_values_1_25 456.6
     2023-07-02 23:03:00   params_events_1_data_values_1_26 439.1
     2023-07-02 23:03:00   params_events_1_data_values_1_27 237.572
     2023-07-02 23:03:00   params_events_1_data_values_1_28 236.670
     2023-07-02 23:03:00   params_events_1_data_values_1_29 237.062
     2023-07-02 23:03:00   params_events_1_data_values_1_3 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_30 1.922
     2023-07-02 23:03:00   params_events_1_data_values_1_31 1.850
     2023-07-02 23:03:00   params_events_1_data_values_1_32 1.871
     2023-07-02 23:03:00   params_events_1_data_values_1_33 3.6366
     2023-07-02 23:03:00   params_events_1_data_values_1_34 3.6413
     2023-07-02 23:03:00   params_events_1_data_values_1_35 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_36 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_37 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_38 1.9814
     2023-07-02 23:03:00   params_events_1_data_values_1_39 223.6
     2023-07-02 23:03:00   params_events_1_data_values_1_4 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_40 212.1
     2023-07-02 23:03:00   params_events_1_data_values_1_41 282.6
     2023-07-02 23:03:00   params_events_1_data_values_1_42 271.8
     2023-07-02 23:03:00   params_events_1_data_values_1_43 239.363
     2023-07-02 23:03:00   params_events_1_data_values_1_44 238.844
     2023-07-02 23:03:00   params_events_1_data_values_1_45 239.152
     2023-07-02 23:03:00   params_events_1_data_values_1_46 1.180
     2023-07-02 23:03:00   params_events_1_data_values_1_47 1.135
     2023-07-02 23:03:00   params_events_1_data_values_1_48 1.159
     2023-07-02 23:03:00   params_events_1_data_values_1_49 0.029
     2023-07-02 23:03:00   params_events_1_data_values_1_5 0.0000
     2023-07-02 23:03:00   params_events_1_data_values_1_50 0.027
     2023-07-02 23:03:00   params_events_1_data_values_1_51 0.027
     2023-07-02 23:03:00   params_events_1_data_values_1_6 1.3113
     2023-07-02 23:03:00   params_events_1_data_values_1_7 6.5
     2023-07-02 23:03:00   params_events_1_data_values_1_8 5.7
     2023-07-02 23:03:00   params_events_1_data_values_1_9 82.5
     2023-07-02 23:03:00   params_events_1_event data
     2023-07-02 23:03:00   params_events_1_id 0
     2023-07-02 23:03:00   params_events_1_ts 1688331720.00
     2023-07-02 23:03:23   params_ts       1688331801.84
     2023-07-02 23:03:23   src             shellypro3em-0cb815fcbbec
     2023-07-02 23:03:00   total_act       63227.69
     2023-07-02 23:03:23   total_act_power 599.591
     2023-07-02 23:03:00   total_act_ret   0.00
     2023-07-02 23:03:23   total_aprt_power 802.707
     2023-07-02 23:03:23   total_current   3.368
Attributes:
   devStateIcon {my $onl = FW_makeImage(ReadingsVal($name,'online','false') eq 'true'?'10px-kreis-gruen':'10px-kreis-rot'); my $light = FW_makeImage(ReadingsVal($name,'state','off')); my $cons1 = ReadingsVal($name,'emeter_0_power',0); my $cons2 = ReadingsVal($name,'emeter_1_power',0); my $cons3 = ReadingsVal($name,'emeter_2_power',0); my $total1 = ReadingsVal($name,'emeter_0_kWh',0); my $total2 = ReadingsVal($name,'emeter_1_kWh',0); my $total3 = ReadingsVal($name,'emeter_2_kWh',0); my $total_sum = $total1+$total2+$total3; my $total_w =$cons1+$cons2+$cons3; my $ip = ReadingsVal($name,'ip','unknown'); qq(<a href="http://$ip"target="_blank">$onl</a> <a href="/fhem?cmd.dummy=set $name toggle&XHR=1">$light</a><div>P1: $cons1 W / Total P1: $total1 kWh<br>P2: $cons2 W / Total P2: $total2 kWh<br>P3: $cons3 W / Total P3: $total3 kWh<br>3 Phases total: $total_w W / $total_sum kWh</div>)}
   model      shelly3em
   readingList shellies/ShellyPro3EM/online:.* online
  shellies/ShellyPro3EM/announce:.* { json2nameValue($EVENT) }
  shellies/announce:.* { $EVENT =~ m,..id...ShellyPro3EM...mac.*, ? json2nameValue($EVENT) : return }
  shellies/ShellyPro3EM/relay/0:.* state
  shellies/ShellyPro3EM/input_event/0:.* { json2nameValue($EVENT) }
  shellies/ShellyPro3EM/input/0:.* input0
  shellies/ShellyPro3EM/online:.* online
  shellies/ShellyPro3EM/emeter/0/power:.* emeter_0_power
  shellies/ShellyPro3EM/emeter/0/pf:.* emeter_0_pf
  shellies/ShellyPro3EM/emeter/0/current:.* emeter_0_current
  shellies/ShellyPro3EM/emeter/0/voltage:.* emeter_0_voltage
  shellies/ShellyPro3EM/emeter/1/power:.* emeter_1_power
  shellies/ShellyPro3EM/emeter/1/pf:.* emeter_1_pf
  shellies/ShellyPro3EM/emeter/1/current:.* emeter_1_current
  shellies/ShellyPro3EM/emeter/1/voltage:.* emeter_1_voltage
  shellies/ShellyPro3EM/emeter/2/power:.* emeter_2_power
  shellies/ShellyPro3EM/emeter/2/pf:.* emeter_2_pf
  shellies/ShellyPro3EM/emeter/2/current:.* emeter_2_current
  shellies/ShellyPro3EM/emeter/2/voltage:.* emeter_2_voltage
  shellies/ShellyPro3EM/emeter/0/energy:.* emeter_0_energy
  shellies/ShellyPro3EM/emeter/0/returned_energy:.* emeter_0_returned_energy
  shellies/ShellyPro3EM/emeter/0/total:.* emeter_0_total
  shellies/ShellyPro3EM/emeter/0/total:.* {'emeter_0_kWh' => sprintf("%.2f",$EVENT/1000)}
  shellies/ShellyPro3EM/emeter/0/total_returned:.* emeter_0_total_returned
  shellies/ShellyPro3EM/emeter/1/energy:.* emeter_1_energy
  shellies/ShellyPro3EM/emeter/1/returned_energy:.* emeter_1_returned_energy
  shellies/ShellyPro3EM/emeter/1/total:.* emeter_1_total
  shellies/ShellyPro3EM/emeter/1/total:.* {'emeter_1_kWh' => sprintf("%.2f",$EVENT/1000)}
  shellies/ShellyPro3EM/emeter/1/total_returned:.* emeter_1_total_returned
  shellies/ShellyPro3EM/emeter/2/energy:.* emeter_2_energy
  shellies/ShellyPro3EM/emeter/2/returned_energy:.* emeter_2_returned_energy
  shellies/ShellyPro3EM/emeter/2/total:.* emeter_2_total
  shellies/ShellyPro3EM/emeter/2/total:.* {'emeter_2_kWh' => sprintf("%.2f",$EVENT/1000)}
  shellies/ShellyPro3EM/emeter/2/total_returned:.* emeter_2_total_returned
ShellyPro:ShellyPro/events/rpc:.* { json2nameValue($EVENT) }
ShellyPro:ShellyPro/status/em_0:.* { json2nameValue($EVENT) }
ShellyPro:ShellyPro/status/emdata_0:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   stateFormat { my $light = ReadingsVal($name,'state','off'); my $cons1 = ReadingsVal($name,'emeter_0_power',0); my $cons2 = ReadingsVal($name,'emeter_1_power',0); my $cons3 = ReadingsVal($name,'emeter_2_power',0); my $total1 = ReadingsVal($name,'emeter_0_kWh',0); my $total2 = ReadingsVal($name,'emeter_1_kWh',0); my $total3 = ReadingsVal($name,'emeter_2_kWh',0); return qq(Relay: $light,<br>P1: $cons1 W / Total P1: $total1 kWh<br>P2: $cons2 W / Total P2: $total2 kWh<br>P3: $cons3 W / Total P3: $total3 kWh) }
   userReadings emeter_0_energy_total:emeter_0_energy:.* monotonic {ReadingsNum("$name","emeter_0_energy",0)}, emeter_1_energy_total:emeter_1_energy:.* monotonic {ReadingsNum("$name","emeter_1_energy",0)}, emeter_2_energy_total:emeter_2_energy:.* monotonic {ReadingsNum("$name","emeter_2_energy",0)}
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Juli 2023, 07:05:44
jsonMap und die 3-Argument-Variante von json2nameValue() in readingList wären der Ansatz.

Solche Umbenennungen führen u.U. dazu, dass nicht alle attrTemplate angezeigt werden...
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Motivierte linke Hände am 03 Juli 2023, 07:37:16
@Beta-User: Ein Template für den 3empro gibt es aber nicht, oder?

@Alcamar: Mein Prefix ist "shellies/Shelly-WPumpe". Damit habe ich den Präfix bei den Readings nicht. "/shellies" für Shellies als Präfix beizubehalten, hilft. Mit den übrigen Readingnamen kann man dann m.E. leben.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Juli 2023, 10:00:52
Zitat von: Motivierte linke Hände am 03 Juli 2023, 07:37:16@Beta-User: Ein Template für den 3empro gibt es aber nicht, oder?
Hab's nicht geprüft, kann schon sein, dass es (noch?) keines gibt.
Jedenfalls ist es (meistens) kontraproduktiv, die topic-defaults zu ändern....
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Alcamar am 03 Juli 2023, 14:34:53
ich komme auch mit jsonMap und json2nameValue nicht klar, auch wenn ich versuche die "Doku" zu verstehen.

Zitatattr m2d jsonMap SENSOR_AM2301_Humidity:Humidity
attr m2d readingList tele/sonoff/SENSOR:.* { json2nameValue($EVENT, 'SENSOR_', $JSONMAP) }

Wenn ich die unzähligen Readings auf die wesentlichen reduzieren und dann auch noch loggen könnte, wäre ich für meine Begriffe durch.
Als Neuling in diesem Thema ist es nicht so einfach die ganzen Beiträge hier für sich zu sortieren.

Den Shelly Pro 3em in die Stromverteilung zu montieren und dafür zu sorgen, dass es Daten an fhem sendet, war eine einfache Übung.
Jetzt wo die Daten dort allerdings einprasseln, sehe ich nicht, wie ich sie verarbeiten kann. die attrTemplate hat mir nicht geholfen.

Gibt es eine grundsätzliche Dokumentationsquelle, die man zielführend heranziehen kann?



Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Motivierte linke Hände am 03 Juli 2023, 15:03:58
Ändere den MQTT-Prefix im Shelly (nicht in fhem) auf den Standard zurück, alternativ auf "shellies/irgendwas". Damit solltest Du den Präfix "params" bei den Readings loswerden. Mit dem Rest kann man m.E. im Standard gut leben, ohne dass es dann (in dem vmtl. danach dann neu angelegten Gerät in fhem) weiterer Änderungen bedarf. Du kannst für a, b und c die Messwerte erkennen und auslesen.

Wenn Du die Messwerte noch einfacher lesbar haben möchtest, kannst Du diese in den Status des Geräts schreiben. Bei mir sieht das so aus:

attr EM_WPumpe stateFormat { my $cons1 = ReadingsVal($name,'em_0_a_act_power',0); my $cons2 = ReadingsVal($name,'em_0_b_act_power',0); my $cons3 = ReadingsVal($name,'em_0_c_act_power',0); my $total1 = round(ReadingsNum($name,'emdata_0_a_total_act_energy',0)/1000,1); my $total2 = round(ReadingsNum($name,'emdata_0_b_total_act_energy',0)/1000,1); my $total3 = round(ReadingsNum($name,'emdata_0_c_total_act_energy',0)/1000,1); my $gesamtP = round(ReadingsNum($name, 'em_0_total_act_power',0),0); my $gesamtE = round(ReadingsNum($name, 'emdata_0_total_act',0)/1000,1);return qq(Frischwasser: $cons1 W / Total: $total1 kWh<br>Außeneinheit: $cons2 W / Total: $total2 kWh<br>Zentrale: $cons3 W / Total P3: $total3 kWh<br>Gesamt: $gesamtP W, $gesamtE kWh) }
(Ggf. möchtest Du dann die Bezeichnungen "Frischwasser", "Außeneinheit" und "Zentrale" gegen was anderes austauschen. Das stammt halt von der Nutzung hier für eine Wärmepumpe...
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 03 Juli 2023, 16:13:29
Zitat von: Alcamar am 03 Juli 2023, 14:34:53ich komme auch mit jsonMap und json2nameValue nicht klar, auch wenn ich versuche die "Doku" zu verstehen.

Zitatattr m2d jsonMap SENSOR_AM2301_Humidity:Humidity
attr m2d readingList tele/sonoff/SENSOR:.* { json2nameValue($EVENT, 'SENSOR_', $JSONMAP) }

Wenn ich die unzähligen Readings auf die wesentlichen reduzieren und dann auch noch loggen könnte, wäre ich für meine Begriffe durch.
Als Neuling in diesem Thema ist es nicht so einfach die ganzen Beiträge hier für sich zu sortieren.

Den Shelly Pro 3em in die Stromverteilung zu montieren und dafür zu sorgen, dass es Daten an fhem sendet, war eine einfache Übung.
Jetzt wo die Daten dort allerdings einprasseln, sehe ich nicht, wie ich sie verarbeiten kann. die attrTemplate hat mir nicht geholfen.

Gibt es eine grundsätzliche Dokumentationsquelle, die man zielführend heranziehen kann?
....den Quelltext...

Oder "Schritt für Schritt" im Wiki, da sind die Parameter kurz erklärt, afaik.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Alcamar am 03 Juli 2023, 19:07:36
Den MQTT-PREFIX habe ich im Shelly geändert. Das hat auch Änderungen in den Namen bewirkt, aber mit "params" fangen die Readings trotzdem an.

Mit dem Hinweis von Beta-User, denke ich das "params" gelöst werden kann. Muss aber erst kapieren, wie das Tandem von jsonMap und json2nameValue zusammenspielt.   
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 03 Juli 2023, 19:23:41
ZitatMuss aber erst kapieren, wie das Tandem von jsonMap und json2nameValue zusammenspielt.

Nur bspw:

ZitatjsonMap und ...

a_total_act_energy:L1_energy a_total_act_ret_energy:0
a_total_act_energy wird umbennannt in L1_energy.
a_total_act_ret_energy wird mit 0 beerdigt, das bisher angelegte Reading musst du anschliessend mit deletereading löschen.

Zitat... die 3-Argument-Variante von json2nameValue() in readingList wären der Ansatz.

{ json2nameValue($EVENT) }in der readingList durch 
{ json2nameValue($EVENT,'',$JSONMAP) } ersetzen.

Gruß

aus der Nähe
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Alcamar am 03 Juli 2023, 19:36:08
@TomLee: Warum finde ich eine solche Erläuterung nicht in wiki?  :)
Danke! Du hast mir gerade neuen Schwung gegeben.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: TomLee am 03 Juli 2023, 21:39:19
ZitatWarum finde ich eine solche Erläuterung nicht in wiki?

Primär (meiner Auffassung nach), hat sich mehr oder weniger (!) nur eine Person bisher dazu bemüht die gegebenen Bausteine im Wiki festzuhalten, es steht jedem frei sich an der "Übersetzung" zu beteiligen (meine Welt ist das nicht, versuchs aber ab und zu, eher sehr selten).

Ich denke, mit den zuvor gegebenen Hinweisen iVm. der Suche im Forum wärst du auch selbst auf die Lösung gekommen.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: bene80 am 04 September 2023, 13:55:53
Hallo,

ich habe einen ShellyMotion 2 im Einsatz bei dem ich den Lux-Wert zum Steuern meiner Rollläden nutze. Leider wird dieser Wert nur einmal in der Stunde aktualisiert.
Gibt es eine Möglichkeit den Wert in regelmäßigen Abständen abzufragen?
Leider sind meine FHEM Kenntnisse eher Bescheiden um es vorsichtig auszudrücken  ::)

Für einen Vorschlag wäre ich dankbar
Grüße Bernhard
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: bene80 am 06 September 2023, 23:29:49
Hat den wirklich keiner eine Idee wie man das elegant lösen kann?
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: 87insane am 07 September 2023, 15:44:15
https://shelly-api-docs.shelly.cloud/gen1/#shelly-motion-2-settings

Schau da mal ...
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: bene80 am 08 September 2023, 09:57:44
Danke, mit announce funktioniert es. Keine Ahnung ob das elegant ist :-)
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Invers am 07 Oktober 2023, 10:24:34
define MQTT2_shellyrgbw2_8150CC MQTT2_DEVICE shellyrgbw2_8150CC
attr MQTT2_shellyrgbw2_8150CC alexaName Spiegel
attr MQTT2_shellyrgbw2_8150CC autocreate 0
attr MQTT2_shellyrgbw2_8150CC comment Channel 1 for MQTT2_shellyrgbw2_8150CC, see also MQTT2_shellyrgbw2_8150CC_CH2, MQTT2_shellyrgbw2_8150CC_CH3 and MQTT2_shellyrgbw2_8150CC_CH4
attr MQTT2_shellyrgbw2_8150CC genericDeviceType light
attr MQTT2_shellyrgbw2_8150CC icon light_control
attr MQTT2_shellyrgbw2_8150CC model shelly2rgbw_4w_split
attr MQTT2_shellyrgbw2_8150CC readingList shellies/shellyrgbw2-8150CC/white/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
  shellies/shellyrgbw2-8150CC/white/0:.* state\
  shellies/shellyrgbw2-8150CC/white/0/set:.* { json2nameValue($EVENT) }\
  shellies/shellyrgbw2-8150CC/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-8150CC...mac.*, ? json2nameValue($EVENT) : return }
attr MQTT2_shellyrgbw2_8150CC room MQTT2_DEVICE
attr MQTT2_shellyrgbw2_8150CC setList off:noArg shellies/shellyrgbw2-8150CC/white/0/command off\
  on:noArg shellies/shellyrgbw2-8150CC/white/0/command on\
  pct:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-8150CC/white/0/set {"mode":"white","brightness":"$EVTPART1"}\
  pct_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-8150CC/white/0/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}\
  x_update:noArg shellies/shellyrgbw2-8150CC/command update_fw\
  x_mqttcom shellies/shellyrgbw2-8150CC/command $EVTPART1
attr MQTT2_shellyrgbw2_8150CC setStateList on off
attr MQTT2_shellyrgbw2_8150CC webCmd on:off:pct
#   CID        shellyrgbw2_8150CC
#   DEF        shellyrgbw2_8150CC
#   FUUID      652020d3-f33f-8098-ced0-723e0904ded46cc6
#   IODev      MQTT2_Server
#   LASTInputDev MQTT2_Server
#   MQTT2_Server_CONN MQTT2_Server_192.168.178.64_7630
#   MQTT2_Server_MSGCNT 904
#   MQTT2_Server_TIME 2023-10-07 10:09:27
#   MSGCNT     904
#   NAME       MQTT2_shellyrgbw2_8150CC
#   NR         594
#   STATE      on
#   TYPE       MQTT2_DEVICE
#   eventCount 923
#   OLDREADINGS:
#   READINGS:
#     2023-10-07 06:41:12   IODev           MQTT2_Server
#     2023-10-07 10:00:24   associatedWith  MQTT2_shellyrgbw2_8150CC_CH2,MQTT2_shellyrgbw2_8150CC_CH3,MQTT2_shellyrgbw2_8150CC_CH4
#     2023-10-07 10:00:18   attrTemplateVersion 20210103
#     2023-10-07 10:09:27   brightness      88
#     2023-10-07 10:09:27   has_timer       false
#     2023-10-07 10:09:27   ison            true
#     2023-10-07 10:09:27   mode            white
#     2023-10-07 10:00:25   online          true
#     2023-10-07 10:09:27   overpower       false
#     2023-10-07 10:01:52   pct             set pct 88
#     2023-10-07 10:09:27   power           21.60
#     2023-10-07 10:09:27   source          mqtt
#     2023-10-07 10:09:27   state           on
#     2023-10-07 10:09:27   timer_duration  0
#     2023-10-07 10:09:27   timer_remaining 0
#     2023-10-07 10:09:27   timer_started   0
#     2023-10-07 10:09:27   transition      0
#     2023-10-07 10:00:24   x_mqttcom       set x_mqttcom announce
#
setstate MQTT2_shellyrgbw2_8150CC on
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 06:41:12 IODev MQTT2_Server
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:00:24 associatedWith MQTT2_shellyrgbw2_8150CC_CH2,MQTT2_shellyrgbw2_8150CC_CH3,MQTT2_shellyrgbw2_8150CC_CH4
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:00:18 attrTemplateVersion 20210103
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 brightness 88
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 has_timer false
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 ison true
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 mode white
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:00:25 online true
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 overpower false
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:01:52 pct set pct 88
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 power 21.60
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 source mqtt
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 state on
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 timer_duration 0
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 timer_remaining 0
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 timer_started 0
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:09:27 transition 0
setstate MQTT2_shellyrgbw2_8150CC 2023-10-07 10:00:24 x_mqttcom set x_mqttcom announce

define MQTT2_shellyrgbw2_8150CC_CH2 MQTT2_DEVICE shellyrgbw2_8150CC
attr MQTT2_shellyrgbw2_8150CC_CH2 alexaName Decke
attr MQTT2_shellyrgbw2_8150CC_CH2 autocreate 0
attr MQTT2_shellyrgbw2_8150CC_CH2 comment Channel 2 for MQTT2_shellyrgbw2_8150CC, see also MQTT2_shellyrgbw2_8150CC, MQTT2_shellyrgbw2_8150CC_CH3 and MQTT2_shellyrgbw2_8150CC_CH4
attr MQTT2_shellyrgbw2_8150CC_CH2 genericDeviceType light
attr MQTT2_shellyrgbw2_8150CC_CH2 icon light_control
attr MQTT2_shellyrgbw2_8150CC_CH2 model shelly2rgbw_4w_split
attr MQTT2_shellyrgbw2_8150CC_CH2 readingList shellies/shellyrgbw2-8150CC/white/1/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
  shellies/shellyrgbw2-8150CC/white/1:.* state\
  shellies/shellyrgbw2-8150CC/white/1/set:.* { json2nameValue($EVENT) }\
  shellies/shellyrgbw2-8150CC/online:.* online
attr MQTT2_shellyrgbw2_8150CC_CH2 room MQTT2_DEVICE
attr MQTT2_shellyrgbw2_8150CC_CH2 setList off:noArg shellies/shellyrgbw2-8150CC/white/1/command off\
  on:noArg shellies/shellyrgbw2-8150CC/white/1/command on\
  pct:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-8150CC/white/1/set {"mode":"white","brightness":"$EVTPART1"}\
  pct_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-8150CC/white/1/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
attr MQTT2_shellyrgbw2_8150CC_CH2 setStateList on off
attr MQTT2_shellyrgbw2_8150CC_CH2 webCmd on:off:pct
#   CID        shellyrgbw2_8150CC
#   DEF        shellyrgbw2_8150CC
#   FUUID      65211013-f33f-8098-c7ae-bd313ce11c666875
#   IODev      dyson_broker_mqtt2
#   LASTInputDev MQTT2_Server
#   MQTT2_Server_CONN MQTT2_Server_192.168.178.64_7630
#   MQTT2_Server_MSGCNT 77
#   MQTT2_Server_TIME 2023-10-07 10:17:57
#   MSGCNT     77
#   NAME       MQTT2_shellyrgbw2_8150CC_CH2
#   NR         7162
#   STATE      on
#   TYPE       MQTT2_DEVICE
#   eventCount 84
#   READINGS:
#     2023-10-07 10:00:19   IODev           dyson_broker_mqtt2
#     2023-10-07 10:00:24   associatedWith  MQTT2_shellyrgbw2_8150CC,MQTT2_shellyrgbw2_8150CC_CH3,MQTT2_shellyrgbw2_8150CC_CH4
#     2023-10-07 10:17:57   brightness      1
#     2023-10-07 10:17:57   has_timer       false
#     2023-10-07 10:17:57   ison            true
#     2023-10-07 10:17:57   mode            white
#     2023-10-07 10:00:25   online          true
#     2023-10-07 10:17:57   overpower       false
#     2023-10-07 10:02:17   pct             set pct 44
#     2023-10-07 10:17:57   power           0.25
#     2023-10-07 10:17:57   source          http
#     2023-10-07 10:17:57   state           on
#     2023-10-07 10:17:57   timer_duration  0
#     2023-10-07 10:17:57   timer_remaining 0
#     2023-10-07 10:17:57   timer_started   0
#     2023-10-07 10:17:57   transition      0
#
setstate MQTT2_shellyrgbw2_8150CC_CH2 on
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:00:19 IODev dyson_broker_mqtt2
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:00:24 associatedWith MQTT2_shellyrgbw2_8150CC,MQTT2_shellyrgbw2_8150CC_CH3,MQTT2_shellyrgbw2_8150CC_CH4
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 brightness 1
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 has_timer false
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 ison true
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 mode white
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:00:25 online true
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 overpower false
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:02:17 pct set pct 44
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 power 0.25
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 source http
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 state on
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 timer_duration 0
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 timer_remaining 0
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 timer_started 0
setstate MQTT2_shellyrgbw2_8150CC_CH2 2023-10-07 10:17:57 transition 0

Ich habe einen Shelly RGBW2 per MQTT2 unter Verwendung des Templates shelly2rgbw_4w_split in FHEM eingebunden.
Das funktioniert mit dem Kanal 1 prima. Kanäle 2-4 können aber nur anzeigen, was ich im Shelly selbst einstelle, aber nur an und aus.
Ein Schalten der Kanäle 2-4 aus FHEM ist nicht möglich, aber eine Anzeige schon. Fehler im FHEM-Log sehe ich nicht.

Kann mir bitte jemand sagen, warum die anderen Kanäle nicht gehen?
Leider konnte ich nachträglich den Fragetext nicht vor dem Code einsetzen.

EDIT: Falls ich im falschen Forum bin, bitte ich um einen Hinweis.

Vielen Dank im Voraus.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Invers am 09 Oktober 2023, 08:40:10
OK, dann antworte ich mir mal selbst.
Ich habe den Fehler gefunden. Es wurde vom Template der falsche Broker eingetragen.
Es wurde dyson_broker_mqtt2 statt des normalen MQTT2_Server  eingesetzt.
Keine Ahnung, warum.

Ist also gelöst.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Motivierte linke Hände am 09 Oktober 2023, 09:55:42
Danke fürs Teilen!
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: grappa24 am 08 November 2023, 16:43:20
Hallo,
ich war ganz glücklich mit meinen ShellyPlugS GEN1 mit MQTT und jetzt doch etwas überrascht, als ich mir die neuen ShellyPlusPlug GEN2 geholt habe  :o Gibts denn schon ein passendes Template dafür?
Grüße, Dieter
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Docter am 24 November 2023, 10:29:21
boah... selbes Problem hier...
Bekomme den ShellyPlugPlug GEN2 nicht ans laufen
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: grappa24 am 24 November 2023, 10:43:20
einfach das Template für den shellyPlus_1pm benutzen, funktioniert wunderbar.

Und in den Shelly Einstellungen müssen sich die GEN2 Shellies bereits im MQTT-Prefix unterscheiden ....
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Docter am 27 November 2023, 06:28:46
Zitat von: grappa24 am 24 November 2023, 10:43:20einfach das Template für den shellyPlus_1pm benutzen, funktioniert wunderbar.

Und in den Shelly Einstellungen müssen sich die GEN2 Shellies bereits im MQTT-Prefix unterscheiden ....

bei mir leider nicht...
Kann den Plug dann nichtmal an und aus schalten per FHEM
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: pattex am 01 Dezember 2023, 11:55:37
@Docter

SChau mal ob es folgendes Problem bei dir ist:
Das Attribut devicetopic muss gleich dem hinterlegten Topic des Shellies sein. Im Standard steht da z.B. nur shellyplusplugs drin. Da muss dann sowas wie shellyplusplus-xxxxxxxxxxx rein.
Den Wert von xxxxxxxxxxx kannste dir aus der readingsList kopieren.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: sam50 am 16 Dezember 2023, 15:46:52
Zitat von: Docter am 27 November 2023, 06:28:46
Zitat von: grappa24 am 24 November 2023, 10:43:20einfach das Template für den shellyPlus_1pm benutzen, funktioniert wunderbar.

Und in den Shelly Einstellungen müssen sich die GEN2 Shellies bereits im MQTT-Prefix unterscheiden ....

bei mir leider nicht...
Kann den Plug dann nichtmal an und aus schalten per FHEM
Hi Schalt mal das Debug in der Web Oberfläche des PLUG PLUS 1 ein . bei mir haben diese 'setList' Einstellungen funktioniert zum schalten.

off:noArg shellies/Gartenlicht/command/switch:0 off
  on:noArg shellies/Gartenlicht/command/switch:0 on
  toggle:noArg shellies/Gartenlicht/command/switch:0 toggle
  x_update:noArg shellies/Gartenlicht/command update_fw
  x_mqttcom shellies/Gartenlicht/command $EVTPART1
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: sam50 am 20 Dezember 2023, 11:12:40
Zitat von: Docter am 27 November 2023, 06:28:46
Zitat von: grappa24 am 24 November 2023, 10:43:20einfach das Template für den shellyPlus_1pm benutzen, funktioniert wunderbar.

Und in den Shelly Einstellungen müssen sich die GEN2 Shellies bereits im MQTT-Prefix unterscheiden ....

bei mir leider nicht...
Kann den Plug dann nichtmal an und aus schalten per FHEM

Hallo,das Template vom PLUS 1PM funktioniert wunderbar, ich hatte allerdings in dem MQTT Einstellungen vom Plus Plug S einige Fehler drin.

1. Ich habe das MQTT Prefix verändert --> sollte bleiben wie es ist zB(shellyplusplugs_80646fd6071)

2. die RPC Einstellungen sollten angewählt sein, da die Steuerung bei dem Template über RPC erfolgt
3. Die Client ID kann verändert werden.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: olwaldi am 23 Dezember 2023, 16:28:01
Zitat von: pattex am 01 Dezember 2023, 11:55:37@Docter

SChau mal ob es folgendes Problem bei dir ist:
Das Attribut devicetopic muss gleich dem hinterlegten Topic des Shellies sein. Im Standard steht da z.B. nur shellyplusplugs drin. Da muss dann sowas wie shellyplusplus-xxxxxxxxxxx rein.
Den Wert von xxxxxxxxxxx kannste dir aus der readingsList kopieren.

Das war auch genau mein Problem - hat geholfen.

Sollte es nicht eigentlich ein ShellyPlusPlugS template geben? Habe sicherheitshalber mal ein vollständiges fhem update gemacht, gab aber nix Neues bzgl. MQTT-templates.

Die hier im Thread diskutierten Lösungsvorschläge sind super, aber schwierig zum Nachvollziehen für Gelegenheits-MQTT-Nutzer (wie mich:-). Habe auch lange mit den vielen Optionen bzgl. MQTT im Shelly-Webinterface experimentiert. Falls noch jemand sucht, hier eine Zusammenfassung der notwendigen Einstellungen, um ein ShellyPlusPlugS via MQTT2 in fhem einzubinden:

1. Neuen ShellyPlusPlugS erstmalig am Stromnetz anschließen, LED leuchtet blau.
2. Mit Shelly-Accesspoint per wifi verbinden, WLAN-Netz heißt ShellyPlusPlugS-########.
3. Webgui öffnen im Browser der Wahl (siehe auch Shelly-Bedienungsanleitung) - 192.168.33.1
4. Eigenes WLAN unter Menüpunkt Wi-Fi konfigurieren (man kann 2 WLANs einstellen), nur 2.4GHz(?)
5. ShellyPlusPlugS rebooten, eigenes wifi am Rechner wieder aktivieren.
6. Z.B. mit Fritzbox IP des Shelly ermitteln und Webgui des Shelly über das eigene WLAN im Browser öffnen.
7. Dort unter Settings->MQTT aktivieren
  Connection type = No SSL
  Enable MQTT control = yes
  Enable RPC over MQTT = yes
  RPC status modification = yes
  Server = Name des fhem-Rechners:1883
  fhem-Username/Paßwort
  Save Settings und reboot des Shelly (wird automatisch angeboten, ansonsten im Settings Menü weiter unten)
8. Im Log des fhem-Rechners prüfen, ob MQTT-Login erfolgreich (d.h. keine Fehlermeldungen).
9. Durch MQTT2-autocreate sollte automatisch das neue MQTT-Device MQTT2_shellyplusplugs_####### erzeugt worden sein.
10. Das neue MQTT2-Device in fhem auswählen, dort oben mittels set ... attrTemplate shellyplus_1pm auswählen.
11. Unten im MQTT2-Device das Attribute devicetopic um die ID des ShellyPlusPlugS mit Bindestrich abgesetzt erweitern, also z.B. attr ... devicetopic shellyplusplugs-#########

Danach funktioniert der ShellyPlusPlugS bei mir - Schönheitsfehler: Im state wird eine Temperatur von -100°C angezeigt, vermutlich hat der ShellyPlusPlugS keinen Temperatursensor.

Hoffe, das hilft anderen mit demselben Problem weiter.


Grüßle, Michael

Nachtrag: Offenbar bleibt der Shelly-Accesspoint aktiv, auch wenn man das eigene WLAN konfiguriert hat. Daher den AP in der Shelly-GUI unter Settings->Access Point deaktivieren.
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: olwaldi am 24 Dezember 2023, 09:31:25
Mittlerweile habe ich das Modul Shelly entdeckt, d.h. man muß MQTT gar nicht nutzen. Das wird dann hier OT, nichtsdestotrotz liste ich hier mal die erforderlichen Schritte für google-Sucher:

1. Neuen ShellyPlusPlugS erstmalig am Stromnetz anschließen, LED leuchtet blau.
2. Mit Shelly-Accesspoint per wifi verbinden, WLAN-Netz heißt ShellyPlusPlugS-########.
3. Webgui öffnen im Browser der Wahl (siehe auch Shelly-Bedienungsanleitung) - 192.168.33.1
4. Eigenes WLAN unter Menüpunkt Wi-Fi konfigurieren (man kann 2 WLANs einstellen), nur 2.4GHz(?)
5. ShellyPlusPlugS rebooten, eigenes wifi am Rechner wieder aktivieren.
6. Z.B. mit Fritzbox IP des Shelly ermitteln und Webgui des Shelly über das eigene WLAN im Browser öffnen.
7. In der Shelly-Webgui den offenen Accesspoint schließen durch Settings->Access Point Haken bei Enable wegnehmen.
8. ShellyPlusPlugS in fhem bekannt machen durch die folgenden fhem-Kommandos
define ShellyPlug Shelly ###.###.###.###
attr ShellyPlug event-on-change-reading .*
attr ShellyPlug webCmd on:off
define ShellyPlugLog FileLog ./log/ShellyPlugLog-%Y-%m.log ShellyPlug:energy:.*|ShellyPlug:power:.*
Das erste Kommando legt das Shelly-Device namens ShellyPlug an mit IP-Adresse, den man an- oder ausschalten kann. Das Schalten übernimmt das nachfolgende notify. Und wenn man die Daten loggen möchte, benötigt man ein FileLog. Und das kann man dann auch ggf. plotten (CreateSVG in ShellyPlugLog).

Grüßle, Michael
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: MadMax-FHEM am 24 Dezember 2023, 10:42:19
Warum dummy und notify?
EDIT: model korrekt setzen oder/und devStateIcon anpassen und du kannst beim Shelly direkt schalten, oder?

Und das Define des Log sieht auch "eigenartig" aus...

ZitatShellyPlug ShellyPlug:energy:.*|ShellyPlug:power:.*

Eher so, oder:
ShellyPlug:energy:.*|ShellyPlug:power:.*

EDIT: und ja, gehört (beides: ja, sorry, mein Beitrag auch) nicht (wirklich) hierher...

Gruß, Joachim
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: olwaldi am 24 Dezember 2023, 12:33:01
Stimmt. Das dummy-Device ist überflüssig. Ich editiere meinen alten Eintrag entsprechend.

Grüßle, Michael
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2023, 12:58:19
Zitat von: olwaldi am 24 Dezember 2023, 09:31:25Das wird dann hier OT, nichtsdestotrotz liste ich hier mal die erforderlichen Schritte für google-Sucher:

Vielleicht einfach die Dokumentation lesen? Die Schritte sind in dem Buch "SmartHome mit FHEM" (und von dem sollte inzwischen jeder mindestens eine elektronische Kopie haben...) ausführlich beschrieben.

LG

pah
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: GeZi3560 am 01 März 2024, 11:38:47
Hallo zusammen,

ist es irgendwie möglich dem Shelly RGBW2 ( MQTT) den  dimup / dimdown Befehl beizubringen?

Das 36_Shelly Modul kann es, aber ich würde doch gerne durchgängig mit meinen Shellys bei MQTT bleiben.

Gruss Gerd
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 01 März 2024, 21:58:00
Zitat von: GeZi3560 am 01 März 2024, 11:38:47Hallo zusammen,

ist es irgendwie möglich dem Shelly RGBW2 ( MQTT) den  dimup / dimdown Befehl beizubringen?

Das 36_Shelly Modul kann es, aber ich würde doch gerne durchgängig mit meinen Shellys bei MQTT bleiben.

Gruss Gerd

Sollte funktionieren.

Bitte mal im attrTemplate "shellydimmer" nachsehen, was da drin ist. Sollte sich (mehr oder weniger einfach, je nachdem, ob der RGBW2 ein "plus"-Gerät ist oder nicht...) übertragen lassen. Ergebnis übernehme ich dann gerne in das attrTemplate (shelly2rgbw_color?)
Titel: Aw: MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: GeZi3560 am 03 März 2024, 11:45:44
Danke für dein Feedback.
Tatsächlich konnte ich im setList Attribut des Shelly Dimmer die Zeilen finden die ich dann in das setList des RGBW2 angepasst übernommen habe. Es ist für einen Channel in dem RGBW-W4_Split Attr Templates.
Beispiel hier für Channel 3

dimup:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+4)/10)*10+10; return qq {shellies/shellyrgbw2-98CDAC266DA2/white/3/set {"turn": "on", "brightness": $num}}; }
  dimdown:noArg { my $num=int((ReadingsNum($NAME,'pct',0)+7)/10)*10-10; return qq {shellies/shellyrgbw2-98CDAC266DA2/white/3/set {"turn": "on", "brightness": $num}}; }