MQTT2+Shelly: erste Konfiguration und template-Entwicklung

Begonnen von miggun, 03 Dezember 2018, 21:05:34

Vorheriges Thema - Nächstes Thema

rudolfkoenig

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

ripperle

Okeeeeeeeey sry für die harten Worte war vllt etwas genervt  ;D

Prinzipiell ist ja alles wunderbar und läuft auch sehr stabil und produktiv...

Ich habe bisher viele zigbee2mqtt Geräte im Einsatz und die habe ich nie über autocreate angelegt...

Diese lege ich immer mit define name MQTT2_DEVICE zigbee
Dann kann man das template auswählen und muss den Namen vergeben und prima...

Genauso wollte ich das auch machen... Anstelle des zigbee am Ende hatte ich dann auch versucht shellies oder shelly oder so einzutragen aber das template wurde net angezeigt.

Wäre für mich immernoch von Interesse wie man bzw ob man ein shelly2.5 device anlegen kann ohne Autocreate...

Gruß

P. S. : sobald mir da jemand helfen kann werde ich dass ins Wiki rein schreiben  :-*

87insane

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


ripperle

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

Beta-User

#589
Ein stürmisches Moin zusammen, hoffe, die Schäden halten sich bei euch in Grenzen...

@ripperle:
Nach dieser Beschreibung würde ich annehnen, dass du MQTT2_CLIENT als IO-Modul nutzt?
Zitat von: ripperle am 09 Februar 2020, 18:10:59
so auch gestern beim anlegen des shelly2.5.
Nachdem autocreate das device angelegt hatte habe ich noch ein shelly 1 eingebunden. Es wurde dann im shelly2.5 auf einemal die readings vom shelly1 eingetragen...
Dann wäre das die Erklärung dafür, dass ALLES in einem Device landet... Abhilfevorschlag findet man im Wiki: https://wiki.fhem.de/wiki/MQTT2_CLIENT (ist auch in den Praxisbeispielen verlinkt...)

Zitat von: ripperle am 10 Februar 2020, 06:35:30
Trotzdem würde ich gerne erfahren ob bzw wie es möglich ist den shelly2.5 ohne Auto create einzubinden...
Auch diese Frage war bereits beantwortet. Es geht! Und zwar sogar auf zwei Wegen:
Zitat von: Beta-User am 09 Februar 2020, 18:37:31
Und wenn du weißt, was du tust, geht auch alles ohne autocreate, auch die gefilterten attrTemplate kann man anwenden, muß dann aber halt wissen, wie der topictree aufgebaut ist bzw. aufgebaut werden muß, um dann die Rückfragen passend zu beantworten. Oder man erstellt ein "rudimentäres" Device, das für die attrTemplate-Erkennung ausreichend ist, in der Regel reicht ein bestimmter readingList-Eintrag (LWT@tasmota, IRGENDEINEN Eintrag, der mit "shellies/" beginnt für die shelly-Geräte). Ist auch nicht schwer, nur eben nicht separat dokumentiert...
Etwas "mundgerechter" formuliert:
- ein Device xyz anlegen und dann _via Kommandozeile_ "set xyz attrTemplate <gewünschtes template>" + Fragen korrekt beantworten, oder
- ein Device xyz anlegen, die Angaben manuell setzen, die für die Auswertung der Parameter genutzt werden (die par-Angaben in der attrTemplate-file, die du bitte selbst suchst..., Erläuterung hier: https://wiki.fhem.de/wiki/AttrTemplate#Warum_finde_ich_das_Template_xyz_nicht.3F)

Zitat von: ripperle am 09 Februar 2020, 18:10:59
Habe ich dann händisch wieder raus gelöscht und schnell Autocreate aus gemacht...
Die von attrTemplate ausgewerteten Angaben (readingList-Einträge...) hättest du u.A. dann auch in dem "Sammeldevice" gefunden und einfach in das händisch erstellte Device reinkopieren können...

Noch eine abschließende Bitte:
Versuche zukünftig auch die Teile von Beiträgen potentiell kompetenter Helfer zu verstehen, die sich dir nicht auf Anhieb erschließen und frage ggf. konkret nach, was mit bestimmten Sätzen gemeint ist, wenn (!) was tatsächlich nach etwas nachdenken/nachforschen (!) noch unklar sein sollte. Es macht nämlich immer noch keinen Spaß, Dinge mehrfach zu schreiben, ohne dass sich die Frage geändert hat...

(@Rudi, marvin78 & 87insane: Danke für die Rückmeldungen. Alles gut, auch jetzt noch ;) )
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

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
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

87insane

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:



Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ullulaki

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

rudolfkoenig

Mit MQTT2_SERVER als IODev kann man schummeln: subscriptions muss zu setList passen.

Ullulaki

Zitat von: rudolfkoenig am 21 Februar 2020, 19:47:47
Mit MQTT2_SERVER als IODev kann man schummeln: subscriptions muss zu setList passen.

danke, jetzt funktioniert es. :-)

Aber eine Problematik, komischerweise bei allen Tasmota-Devices:
Wenn ich über FHEM on/off schalte funktioniert alles.
Schalte ich allerdings das jeweilige Device über das Web-UI findet keine Statusänderung in FHEM statt.
Finde auch in der Doku nichts dazu, oder habe ich einfach einen Denkfehler?

Beta-User

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...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ullulaki

Zitat von: Beta-User am 22 Februar 2020, 15:10:48
Wärt ihr so freundlich, Tasmota-Themen bitte in einem der Tasmota-Threads zu beackern oder einen neuen anzufangen?

(Ich bin mir aber ziemlich sicher, dass wir genau das Thema bzw. Variationen davon schon mehrfach hatten - und dass die Lösung in den "Praxisbeispielen" zu finden ist - nur eben unter Tasmota!) (Und nein, ich werde dazu keine weiteren Auskünfte in diesem Thread erteilen, was genau gemeint sein könnte...).

okay, sorry  ::) :-[

Ich hoffe es ist als Schlusswort noch okay, wenn ich für Andere kurz die Lösung poste bzw. wo ich sie gefunden habe:
Unter folgendem Link bei MQTT2-Device angeschaut und adaptiert, jetzt geht es:
https://forum.fhem.de/index.php?topic=90220.0

Genauergesagt der Part ist notwendig:
attr DEVICE userReadings state {ReadingsVal($name,"POWER","")}

Beta-User

Zitat von: Ullulaki am 23 Februar 2020, 13:43:48
Ich hoffe es ist als Schlusswort noch okay, wenn ich für Andere kurz die Lösung poste bzw. wo ich sie gefunden habe:
Nein, ist nicht iok.
1. Ist es immer noch kein Shelly-template-Thema.2. geht der Link "irgendwohin" in einem vielseitigen Thread => nicht hilfreich, oder...?
3. Ist das mit einiger Sicherheit nur "erforderlich", weil du das "falsche" attrTemplate zuletzt angewendet hattest.

Also: Wenn du Fragen oder Anmerkungen zu attrTemplate zu TASMOTA hast, nutze bitte einfach den richtigen Thread dazu, da bekommst du ggf. Hilfe (auch von mir) und keine tendenziell kryptischen Zwischenrufe...
(Genau zwei (!) Beiträge vorher war schon jemand falsch... Muß doch nicht sein, oder?!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

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