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
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
Zitat
Der 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
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/

Zitat
shellies/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:.* stateWenn 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:onBrauchst 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
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
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
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
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.

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
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 toggleHinweise 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
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
Ä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
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
Zitat
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.
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
Zitat
Der 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:
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.
Zitat
Mir 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
@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.

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
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.

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.

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.

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.

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 PINGREQWenn 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
Moin, dann nehme ich mal die Mütze für den Shellybulb auf.
Danke für die schnelle Initiative!

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

Zitat
Ich 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).
Zitat
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}
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 :) .
Zitat
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?"
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
Zitat
Liegt das vielleicht daran, dass das Reading "status_brightness" heisst, und nicht "brightness"?
Ja.
Zitat
Kann 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
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 .*".

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.).

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
Zitat
Wohin 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
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
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.

Zitat
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.
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).

Zitat
Wo 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).

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
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)

So, hier mal das erste Lebenszeichen vom Shelly1.
Werde auf der Grundlage mal das Template fertigen.
:)

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) }

Zitat
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.
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
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
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
 
Zitat
Wä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.

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

Zitat
So, proudly presenting:
Hinzugefuegt.

Zitat
So 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
Zitat
Mit 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).

Zitat
Btw.: 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
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
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:
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

# 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

@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).

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
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?

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
Zitat
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.
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.

Zitat
Da 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
Zitat
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?
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
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
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
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
Zitat
Allerdings 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
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:
Lö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
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
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
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
Zitat
Wenn 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
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...

Zitat
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?
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
Zitat
shelly4pro_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
[...] 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:
Zitat
relay_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
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...).

Zitat
json2nameValue 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
@: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
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
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
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
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 ;)

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
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

Zitat
Common 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
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
@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
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) ;) .

Zitat
Nun 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
"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 :) .

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...)

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

Nee, das Device entspricht m.E. unverändert dem Template A_15_shellybulb wie ich es geschrieben hatte, und das funktioniert soweit auch unverändert in FHEMWEB. Welchen Änderungsbedarf gibt es?
Titel: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung
Beitrag von: Beta-User am 02 Mai 2019, 15:49:55
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
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
Zitat
da Beta-User sagte ich solle dir das mal erklären bzw. erzählen tue ich das mal.... Es geht hierum:
https://forum.fhem.de/index.php/topic,94060.msg935693.html#msg935693
Ich weiss immer noch nicht genau, was man will/was das Problem ist, ich habe das Gefuehl, dass die Listings der Beschreibung widersprechen.

Wenn folgender Fix:
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
Zitat
ABER in anderen Templates ohne on/off in setList geht genau das ohne Probleme....
Liegt an der Kombination von auf mehrere Zeilen verteiltes <a> (eigentlich nicht vorgesehen, da jede stateFormat Zeile als eine Einheit behandelt wird), und den Unsinn, was FHEM daraus in seiner Naivitaet zusammenbaut (siehe HTML Quelltext).

Wie gesagt: es richtig mit allen Features zu machen ist aufwendig, und jeder, der das unbedingt will, darf es mit der perl Version von devStateIcon selbst bauen.
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:
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
@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
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
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
(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
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
@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
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
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

Wie meinst du das mit dem Web-IF vom Shelly?!
Sorry, ich meine das Webinterface ;)

Bitte mit swap befassen...
Zitat
Whether 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)
Zitat
    shellies/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
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
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 }
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
Zitat
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?
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.

Zitat
set <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
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
@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
Zitat
A_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
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!
Zitat
Die 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

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?




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).

Zitat
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....
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
Zitat
Ohne 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

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
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
Zitat
Es 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
Zitat
Du 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
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.

- 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
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
Zitat
Die 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
... 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
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
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
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
@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
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
Zitat
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)...
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
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
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

Zitat
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).

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
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
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
[...] 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 ;) .


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 }\

[...] 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 .

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
Zitat
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 }\
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 :-\

Zitat
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 .
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
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.
Zitat
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).
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?

Zitat
Sorry, 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

Zitat
Du 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
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 :) .

Zitat
Hatte 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).

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 :)

Zitat
da 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 falseIst 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
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
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
Zitat
Ein paar Zeichen lassen sich noch einsparen, aber man kann zugegebenermaßen darüber streiten, ob das vollends lohnt ;D ::) ;D :
Aus Interesse....was denn? :)

Zitat
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 .
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.

Zitat
Bitte 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
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
Zitat
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!).
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).


Zitat
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?
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?

Zitat
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"?
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
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.

Zitat
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.
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
Zitat
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.
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....

Zitat
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?).
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:

Zitat
Das 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
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
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
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
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
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.
Zitat
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.
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!

Zitat
Vermutlich 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
[...]
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
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
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
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:.* stateZu 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
Hey auch hier nochmal. Bist heute ja richtig poetisch ;)
Dachte, dass bei manchen vielleicht Bilder eher Wirkung zeigen wie unfreundliches Anschnautzen ;D .

Zitat
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.
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
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
Zitat
aber 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
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
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),

Zitat
Zu 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:

https://shelly-api-docs.shelly.cloud/#mqtt-support (https://shelly-api-docs.shelly.cloud/#mqtt-support)
Zitat
Device 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 0Wä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
Zitat
Threads 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
@ 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_lightkonnte 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:
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

Zitat
Vielleicht 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

Zitat
Kann 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
Ich nehme an, du beziehest dich jetzt auf deinen Vorschlag
No. Auf diesen:
setStateList-Attribut (on off toggle)

Zitat
Aber 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 zigbeeDann 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?
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...)

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:
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))

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
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
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
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
Zitat
Ich 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:
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.

[...]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

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 k