Autor Thema: Folgende Frage zu Sonoff/Tasmota und MQTT2_Device  (Gelesen 14398 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8493
  • eigentlich eher user wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #15 am: 14 Dezember 2018, 21:04:19 »
Vorab erst mal Danke für die zahlreichen Beiträge und Anregungen!

Wird etwas dauern, bis ich das (und die Anmerkungen+Rudis neuen Code aus den anderen Threads) verarbeitet haben werde.

a) es wird wieder zwei effektiv unterschiedliche Tasmota-templates geben, wäre schön, es wäre (für einen bisherigen Nicht-Tasmotaer) nachvollziehbar, nach welcher Regel was auszusuchen ist. Btw: Rudi hat Kommentare ermöglich! Könnte man die Typen/Firmware-Varianten... reinschreiben, für was ein template denn nun ist. => Wer das einigermaßen strukturiert liefern kann: her damit...

b) Macht es Sinn, eine Standard-readingList für alle Tasmota-Varianten mit auszuliefern? (Die vom 4-fach, oder?)

c) vermutlich braucht es für manche Readings eine Art "get ...". Könnte man gleich am Ende publishen, ich würde dann nur den Befehl benötigen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8493
  • eigentlich eher user wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #16 am: 14 Dezember 2018, 22:31:15 »
Kurze Info:

das mit der Standard-readingList für alle Tasmotas habe ich eben eingecheckt, zusammen mit POWER/POWER1-Varianten.
Den von moonsorrox gemeldeten bug habe ich auch versucht zu fixen, bitte dazu um Rückmeldung.
Im Übrigen siehe hier: https://forum.fhem.de/index.php/topic,94060.msg872067.html#msg872067, auch den dortigen Hinweis zu "desc:".
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 3422
  • Online
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #17 am: 14 Dezember 2018, 23:32:47 »
ja es ist sicher viel Arbeit für soetwas fast komplett neues, aber lass dir Zeit es funktioniert ja erst einmal. Das es nicht perfekt ist nach dieser kurzen Zeit ist ja klar und kein Problem, aber da arbeiten wir dran  ;)
Ich denke genug Mithelfer hast du ja...!  ;)

weitere Frage am Rande zum 4-Kanl Schalter, hast du mal gesehen was dort im STATE drin steht, bei meinen anderen Geräten steht dort maximal ein ON oder OFF oder auch off drin.
Ich kann das gerne mal ganz unten ran hängen, evtl. hilft es dir bei der Suche/Erstellung oder sonst irgend etwas

a)Rudi hat Kommentare ermöglich! Könnte man die Typen/Firmware-Varianten... reinschreiben, für was ein template denn nun ist. => Wer das einigermaßen strukturiert liefern kann: her damit...

b) Macht es Sinn, eine Standard-readingList für alle Tasmota-Varianten mit auszuliefern? (Die vom 4-fach, oder?)

c) vermutlich braucht es für manche Readings eine Art "get ...". Könnte man gleich am Ende publishen, ich würde dann nur den Befehl benötigen...

zu a) meinst du die Tasmota Firmware..? die lese ich ja z.B. schon in meiner readinggroup aus. Wenn du aber die Geräte meinst z.B. Basic, S20 usw. denke ich wird es schwieriger, weil es schon von fast jedem Gerät eine oder mehrere Versionen gibt die sich unterscheiden.
Dazu ein Beispiel ich hatte mir ein YouTube Video angeschaut und als ich meinen Basic bekam sah der vom Aufbau ganz anders aus und hatte eine andere Vers. Nr. da bist ewig am verändern, wenn den Chinesen was neues einfällt.

zu b) ich denke das ist evtl. das beste, denn einmal vllt auch im Wiki ein Beispiel dann weiß jeder wie er sie ergänzen kann, wobei die readinglist jetzt nicht das schwierige ist.

zu c) kann ich nichts sagen, weil ich grad nicht weiß was du meinst oder ich verstehe es nur nicht. :-\

O.T.
Meine 4 Shelly 1 sind auch schon unterwegs, dort in dem Thread habe ich auch schon mitgelesen, da tut sich auch einiges  ;)

Inhalt nur vom STATE des 4-fach Schalter:
<div>Drucker:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="617pt" viewBox="0 0 468 617" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)" stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> Dell Server:<svg class=" on" data-txt="on" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="537pt" viewBox="0 0 468 537" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,537) scale(0.181395,-0.181395)" stroke="none"> <path d="M957 2932 c-14 -16 -17 -43 -17 -174 0 -135 2 -157 18 -171 28 -25 72 -26 96 -1 13 13 16 43 16 173 0 140 -2 160 -18 174 -25 22 -75 21 -95 -1z"/> <path d="M1506 2928 c-13 -18 -16 -53 -16 -174 0 -138 2 -152 20 -169 24 -22 77 -22 99 0 13 12 17 44 19 151 4 147 1 174 -24 198 -24 24 -80 20 -98 -6z"/> <path d="M278 2834 c-29 -15 -44 -50 -34 -81 3 -11 73 -85 154 -166 127 -126 153 -147 180 -147 34 0 72 38 72 73 0 34 -312 341 -342 337 -2 -1 -15 -7 -30 -16z"/> <path d="M2235 2840 c-34 -14 -315 -305 -315 -327 0 -35 38 -73 72 -73 27 0 53 21 180 148 82 81 151 157 155 170 12 51 -44 100 -92 82z"/> <path d="M1039 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M2110 2123 c-49 -19 -64 -68 -34 -111 15 -22 19 -22 238 -22 211 0 224 1 241 20 23 25 24 76 1 98 -14 15 -44 17 -224 19 -114 1 -214 -1 -222 -4z"/> <path d="M16 2098 c-22 -31 -20 -71 5 -94 19 -17 39 -19 240 -19 236 0 241 1 254 55 4 18 0 34 -15 53 l-21 27 -224 0 c-220 0 -224 0 -239 -22z"/> <path d="M26 1559 c-32 -25 -35 -70 -6 -99 19 -19 33 -20 238 -20 207 0 220 1 237 20 26 29 24 79 -4 102 -21 16 -44 18 -231 18 -195 0 -209 -1 -234 -21z"/> <path d="M2080 1560 c-23 -23 -26 -68 -6 -96 13 -18 30 -19 233 -22 203 -3 221 -2 243 16 32 26 32 78 1 104 -21 16 -44 18 -237 18 -201 0 -215 -1 -234 -20z"/> <path d="M20 1010 c-29 -29 -26 -74 7 -100 26 -20 36 -21 240 -18 184 3 215 5 229 20 23 22 22 73 -1 98 -17 19 -30 20 -237 20 -205 0 -219 -1 -238 -20z"/> <path d="M2077 1012 c-22 -25 -21 -75 1 -95 16 -15 48 -17 238 -17 120 0 224 4 231 8 32 20 32 94 0 114 -7 4 -111 8 -233 8 -201 0 -222 -2 -237 -18z"/> <path d="M998 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M1023 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M1023 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M1101 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P3:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="617pt" viewBox="0 0 468 617" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)" stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P4:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="617pt" viewBox="0 0 468 617" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)" stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg></div>
« Letzte Änderung: 14 Dezember 2018, 23:57:15 von moonsorrox »
Intel-NUC i3: FHEM-Server 5.9 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8493
  • eigentlich eher user wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #18 am: 15 Dezember 2018, 00:34:23 »
...das mit dem Zeit lassen ist relativ:
Zum einen will ich erst mal recht schnell einen Stand haben, der erst mal "brauchbar" ist => sowas wie dir passiert ist (welche Variante soll ich denn nehmen?!?) sollte - nach Lektüre der vorhandenen Info dazu - nicht sein. Und da es recht neu ist, wollen alle es a) einfach haben und b) möglichst sofort richtig...
Daher will ich den Schwung hier "mitnehmen" und schnell was brauchbares haben, und so wie ich den support durch Rudi hier erlebt habe, unterstelle ich mal: er (und andere) auch :) .

Dass das naturgemäß über die diversen Hardwarerevisionen und (v.a.) firmware-Varianten nicht einfach ist, ist einerseits klar, andererseits ist auch Theo & sein Team dahingehend "faul", dass die auch nicht ständig am Controllerinterface (hier: FHEM) rumbasteln wollen, sondern eher die firmware so hinbiegen, dass das über der Zeit möglichst keine Brüche generiert (=> Topicstruktur etc. bleibt möglichst unverändert)
Im Tasmota-Bereich dürfte daher der Anknüpfungspunkt eher eine/mehrere bestimmte (verbreitete) Firmware-Varianten sein, die im desc: auftauchen (=> lösbar und auch nicht ständig zu aktualisieren).

weitere Frage am Rande zum 4-Kanl Schalter, hast du mal gesehen was dort im STATE drin steht, bei meinen anderen Geräten steht dort maximal ein ON oder OFF oder auch off drin.
Nein, ich habe keinen einzigen Tasmota-geflashten ESP ;) . Und auch nur ganze 2 ESP8266 hier im Einsatz: Einen für Milight (Beleuchtung!) und einen mit einer selbergebastelten IR-firmware (die vielleicht demnächst ESPEasy@MQTT weicht). WLAN für Hausautomatisierungszwecke halte ich btw. für eine eher schlechte Lösung, die nur für Nebendevices gewählt werden sollte - dass ich hier grade ziemlich viel für Tasmota und Shelly mache, ist nicht ganz ironiefrei ;D .

Der Code wurde von jemandem anderen in dem Shelly-MQTT-Thread beigesteuert, Fragen also bitte da stellen (bzw. ggf. einen neuen aufmachen und den Autor bitten, das dort zu analysieren).

Zitat
zu b) ich denke das ist evtl. das beste, denn einmal vllt auch im Wiki ein Beispiel dann weiß jeder wie er sie ergänzen kann, wobei die readinglist jetzt nicht das schwierige ist.
zu c) kann ich nichts sagen, weil ich grad nicht weiß was du meinst oder ich verstehe es nur nicht. :-\
Bei c) geht es darum, dem ESP ein Kommando zu schicken, damit der seinerseits was an Infos liefert, was nicht regelmäßig kommt (bei der zigbee-Bridge z.B. alle Geräte mit weiteren Infos). Ist eigentlich ein set, allerdings gefollt von einem Dialogfeld mit der Anzeige des Ergebnisses. Das Problem bei der Sache scheint zu sein, dass dabei schon das Reading angegeben werden muß, unter dem die Info zurückgeliefert wird. Teilweise hängt es dann von der Rückmeldung bzw. der setList ab, wie das dargestellt wird. Ergo sind hier zu viele Automatismen nicht unbedingt hilfreich...
Bin aber selber erst am experimentieren und nicht sicher, ob ich a) alles selbst schon verstanden habe und b) das alles wirklich so funktioniert wie gedacht. Wenn, dann kommt es als erstes als Beispiel in die templates und dann hoffentlich zeitnah auch ins Wiki (wie gehabt, das letzte update bei den "Praxisbeispielen" hat m.E. leider zu lange gedauert, aber ich will das vorher auch "in echt" durchspielen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #19 am: 15 Dezember 2018, 13:24:33 »
also das mit par:DEVNAME sollte so OK sein, vorausgesetzt autocreate ist an so dass die readingList gefüllt wird. Das ist natürlich so universeller. Daran habe ich nicht gedacht. Mit leerer readingList funktioniert par:DEVNAME, so wie ich das verstehe, nicht. Oder liege ich da falsch?

Zur Info für nicht Tasmota-User:

Standardmäßig wird das Gerät in FHEM mit autocreate mit dem Namen MQTT2_<Tasmota-mqtt-client> angelegt. Tasmota verwendet dafür DVES_<letzte 6 Stellen der MAC-Adresse> wenn der client nicht gesetzt wird. Ich verwende in Tasmota normalerweise einen Namen wie sonoffBueroBriefkasten als client. FHEM legt das Gerät dann mit MQTT2_sonoffBueroBriefkasten an. Wenn ich das Gerät in FHEM fertig angelegt habe mache ich ein ren MQTT2_sonoffBueroBriefkasten sonoffBueroBriefkasten. Auch für DHCP wird der client benutzt und ich sehe so auch im DHCP-Server den Namen.

Bezüglich dem Topic (das kann man auch in Tasmota einstellen und konfigurieren) ist es so dass Tasmota hier sonoff als Voreinstellung hat. Dies muss immer abgeändert werden. Sonst haben alle Geräte das selbe topic, was natürlich Fatal ist wenn man nicht alle zusammen schalten will. Ich verwendet hier normalerweise die selbe Bezeichnung wie beim client also sonoffBueroBriefkasten.

Man kann hier MQTT-mäßig natürlich mit / feiner aufteilen. Da ich vorher ZWave hatte und da schon eine gewisse Logik im Namen hatte, mache ich da nix mit / sondern habe lieber alles einheitlich. Name des Gerätes, Topic, Benennung anderer Geräte.

Deswegen sieht das bei mir z. B. so aus

tele/sonoffBueroBriefkasten/STATE

und das Gerät heisst entsprechend sonoffBueroBriefkasten

Da ging das natürlich mit dem Device im template ;-) Für die die im anderen Forumthread nicht mitgelesen haben, das Ursprungstemplate war von mir.

Prinzipiell haben wir aktuell 2 Varianten die grundsätzlich mit und ohne Präfix möglich wären, was dann 4 Varianten wären.

Ist die Variante mit Präfix in den Readings jetzt ganz raus? Wenn das keiner nutzt wäre die Frage ob autocreate das auch ohne wieder generiert. Wer das dann wirklich mit nutzen möchte, kann das ja jederzeit machen. Mir fällt hier aber kein Grund ein wo das einen Vorteil bringt? Ihr wisst ja ich war da von vorn herein kein Freund von ;-)

Dann die 2 Varianten:
1. relay etc. auf mehrere FHEM-Geräte aufteilen
2. relay etc. alles in einem FHEM-Gerät

Mein Vorschlag wäre zumindest in den Templates generell nur ohne präfix zu fahren. Ist denke ich in der aktuellen Version schon so umgesetzt?

Für die Benennung:

A_09x_tasmota_pure_base
als basis ist gut und klar. War ja auch ursprünglich von mir ;-) Würde aber zuerst autocreate auf 0, dann readingList und zum Schluss deleteReading machen. Ist zwar eher theoretischer natur aber wir wollen ja nicht, dass nach setzen von readingList per autocreate noch was rein kommt.

Das mit den Mehrfachgeräten finde ich insgesamt schon etwas seltsam. Bei einem ZWave Bewegungssensor macht ja auch keiner X-Geräte für Temperatur, Bewegungserkennung etc. Ist das wirklich allgemein benutzt bei Tasmota da mehrere Geräte in FHEM draus zu machen? Oder einfach nur weil viele nicht wussten wie sie das in einem Gerät machen können? Ich weiss ich war da der Vorreiter mit dem Template und ich hatte das früher auch in mehreren Geräten gemacht...

Aber lohnt sich die Verwirrung in den Templates oder sollten wir uns nicht besser darauf konzentrieren für die wichtigsten Anwendungsfälle eine einfache und von der großen Mehrheit bevorzugte Variante bereit zu stellen? Die Frage hier was meint die große Mehrheit dazu? Wenn das Einzelaufteilen die Mehrheit darstellt. Sollte meine Variante mit einem Gerät wieder raus. Man könnte das ja dann stattdessen im Wiki als Beispiel für eigene Templates erklären. Aber so weiss doch keiner was er da jetzt wählen soll für ein Template, erst recht mit dem noprefix.

Für mich ist das logischer für meine Markisensteuerung 1 Gerät mit 2 Relay zu haben anstatt 2 wo ich mir dann schon bei der Benennung einen abbrechen muss mit einem Gerät als MarkiseRaus und einem als MarkiseRein. Aber bin ich da mehrheitsfähig?

Zum Thema Firmware ist mir keine Firmware von Tasmota bekannt wo der Aufbau unterschiedlich ist. Von daher muss aktuell in der desc kein Hinweis auf eine bestimmte Firmware stehen.

Bezüglich POWER1 bei einem Gerät mit nur einem Relay wird von Tasmota da normalerweise POWER verwendet ohne Zusatzzahl. Das selbe bei Switches und Buttons. Nur wenn mehr als einer im Gerät aktiv ist werden Zahlen benutzt. Allerdings scheint Tasmota da recht fehlertolerant zu sein und ein cmnd mit POWER1 bei einem Gerät nur mit POWER funktioniert auch. Generell ist Tasmota zumindest in der aktuellen Firmware (da habe ich es eben nochmal getestet) Groß/Kleinschreibung egal.

Das heisst cmnd/sonoffBueroBriefkasten/power1 OFF funktioniert genauso wie cmnd/sonoffBueroBriefkasten/Power Off

Hat das Gerät mehr als ein Relay kann für das erste Relay power1 oder power verwendet werden geht beides. das  2. Relay dann mit power2.

Ansonsten sind die aktuellen Template Versionen nicht ganz sauber.

Template A_01a wird nicht benötigt und funktioniert auch nicht. Bei einem 1 channel device wird in State etc. kein POWER1 sondern POWER zurückgegeben! Das heisst der Status wird so nicht aktualisiert.

Gerät A_01 sollte heißen:
desc: Applies to devices with one POWER reading like Sonoff Basic, S20, ...

Der Name vom A_01a Template wäre eigentlich super für A_01 da allgemein sonoff Basic ist da nur eine Variante unter sehr vielen bei Tasmota

Statt bei COMMAND/POWER1 Ziffern, sollten eigentlich die Texte verwendet werden 0 ist off, 1 ist on, 2 ist toggle. Gibt es da nicht vielleicht auch eine elegantere Variante, dass der Parameter gleich benutzt wird? Schließlich ist
off:noArg COMMAND/POWER1 off
doppelt off ;-) oder eventuell dass mit in setlist das nicht einzeln aufführen muss? wie z. B. beim 4 channel Gerät mit
p1:on,off  COMMAND/POWER1 $EVTPART1

Falls die zusammengefassten Tasmota Geräte gewünscht werden, kann ich auch die templates überarbeiten und hier nochmal bereitstellen.

Was mich an den Templates im Moment am meisten stört, ist dass ich noch keine Lösung habe um über die Icons zu schalten, sprich ein toggle abzusetzen. Ansonsten passt das für mich sehr gut. Bis auf p1, p2 etc in was sprechendes umbenennen und gegebenenfalls die Symbole z. B. auf sani_buffer_temp_down und sani_buffer_temp_up umzustellen, mache ich jetzt bei Neuinbetriebnahmen nichts mehr wesentliches und es geht ruck zuck.

Bitte entschuldigt den langen Post und ich will da auch keinem auf die Nerven gehen, mich würde auch sehr interessieren, wie andere ihre Tasmota konfigurieren. Eventuell wäre da sogar ein eigener Thread sehr interessant zum Austausch.

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #20 am: 15 Dezember 2018, 13:34:32 »
b) Macht es Sinn, eine Standard-readingList für alle Tasmota-Varianten mit auszuliefern? (Die vom 4-fach, oder?)
c) vermutlich braucht es für manche Readings eine Art "get ...". Könnte man gleich am Ende publishen, ich würde dann nur den Befehl benötigen...

b) die readingList von pure_base ist doch OK. Mehr braucht es nicht, oder habe ich was nicht richtig verstanden? Oder meinst du die setList? Die kann aber sehr unterschiedlich sein.
c) nein get's braucht es eigentlich nicht. Über STATE und SENSOR (sofern Sensoren angeschlossen sind) kommt eigentlich alles automatisch alle paar Minuten. Nur INFO1,2,3 kommt glaube ich nur beim restart des Tasmota-Gerätes, oder in sehr großen Zeitabständen. Aber auch wenn sich das Gerät neu mit dem mqtt-Server verbindet.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8493
  • eigentlich eher user wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #21 am: 15 Dezember 2018, 14:38:33 »
Ich hoffe, nichts wichtiges zu vergessen, sonst bitte melden:

b) die readingList von pure_base ist doch OK. Mehr braucht es nicht, oder habe ich was nicht richtig verstanden? Oder meinst du die setList? Die kann aber sehr unterschiedlich sein.
Sorry, die war gemeint und wird jetzt bei allen Tasmota-Varianten so eingesetzt. Damit müßte auch "noprefix" als default bei allen gesetzt sein
Zitat
c) nein get's braucht es eigentlich nicht. Über STATE und SENSOR (sofern Sensoren angeschlossen sind) kommt eigentlich alles automatisch alle paar Minuten. Nur INFO1,2,3 kommt glaube ich nur beim restart des Tasmota-Gerätes, oder in sehr großen Zeitabständen. Aber auch wenn sich das Gerät neu mit dem mqtt-Server verbindet.
Da wäre super, wenn man das IO-Device noch bestimmen würde und darüber ein set <IO-Device> publish <was es braucht, um die INFO- usw.-Readings direkt zu befüllen> abzusetzen. Dann hat der user direkt auch alle Readings angelegt, die er (z.B. in irgendwelchen ReadingsGrous) erwartet...

also das mit par:DEVNAME sollte so OK sein, vorausgesetzt autocreate ist an so dass die readingList gefüllt wird. Das ist natürlich so universeller. Daran habe ich nicht gedacht. Mit leerer readingList funktioniert par:DEVNAME, so wie ich das verstehe, nicht. Oder liege ich da falsch?
Wer meint, autocreate nicht nutzen zu wollen, weiß sich hoffentlich zu helfen. M.E. sollten die templates v.a. denen helfen, die eine Art "assisted configuration" wollen/benötigen.

Zitat
Prinzipiell haben wir aktuell 2 Varianten die grundsätzlich mit und ohne Präfix möglich wären, was dann 4 Varianten wären.

Ist die Variante mit Präfix in den Readings jetzt ganz raus? Wenn das keiner nutzt wäre die Frage ob autocreate das auch ohne wieder generiert. Wer das dann wirklich mit nutzen möchte, kann das ja jederzeit machen.
Wie gesagt, per default ist prefix ausgeschaltet und auch autocreate bringt das nicht zurück, selbst wenn man es einschaltet (war jedenfalls meine bisherige Erfahrung).
Zitat
Mir fällt hier aber kein Grund ein wo das einen Vorteil bringt? Ihr wisst ja ich war da von vorn herein kein Freund von ;-)
Es bringt dann einen Vorteil, wenn man ein "Einheitsdevice" bevorzugt, wie du das nachfolgend ja auch beschreibst. MAcht also an sich Sinn, aber eben nicht mehr, wenn die Topicstruktur so sauber vorbereitet ist wie bei Tasmota ;) .
Zitat
A_09x_tasmota_pure_base
als basis ist gut und klar. War ja auch ursprünglich von mir ;-) Würde aber zuerst autocreate auf 0, dann readingList und zum Schluss deleteReading machen. Ist zwar eher theoretischer natur aber wir wollen ja nicht, dass nach setzen von readingList per autocreate noch was rein kommt.
Schaue ich mir an, aber wir sprechen über minimale Zeiträume, oder?
Zitat
Das mit den Mehrfachgeräten finde ich insgesamt schon etwas seltsam. Bei einem ZWave Bewegungssensor macht ja auch keiner X-Geräte für Temperatur, Bewegungserkennung etc. Ist das wirklich allgemein benutzt bei Tasmota da mehrere Geräte in FHEM draus zu machen? Oder einfach nur weil viele nicht wussten wie sie das in einem Gerät machen können? Ich weiss ich war da der Vorreiter mit dem Template und ich hatte das früher auch in mehreren Geräten gemacht...
M.E. gibt es kein klares Votum für eine der beiden Varianten, beides hat m.E. seine Berechtigung:
Für Einheitsdevices spricht, dass in FHEMWEB alles beieinander  zu finden ist, was physisch zusammengehört. Dann benötigt man aber Umwege (z.B. ReadingsProxy), um sinnvolle Auszüge z.B. in einer Raumansicht darzustellen. Das kann man durch das Aufsplitten umgehen.

Aber z.B. einen Rolladenaktor sollte man nicht nach Kanälen auftrennen (daher im Parallelthread meine dringende Bitte an miggun, den 4-fach-Shelly AUCH als Einheitsdevice zu liefern (und die Empfehlung, dann nur 2x2 einzelne Kanäle für ROLLO zu nutzen).

Im Ergebnis meine ich: Man sollte klar rausarbeiten, dass beide Varianten möglich sind, dafür je firmwaretyp (shelly/tasmota/ESPEasy) je ein template "split" und "unified". Damit sollte sich gerade das Wissen vermitteln lassen, wie man das hinbekommen kann ;) .
Zitat
Zum Thema Firmware ist mir keine Firmware von Tasmota bekannt wo der Aufbau unterschiedlich ist. Von daher muss aktuell in der desc kein Hinweis auf eine bestimmte Firmware stehen.
Dann kommt es bei Gelegenheit wieder raus, sollte der Erhellung dienen, nicht der Verwirrung.

Zitat
Ansonsten sind die aktuellen Template Versionen nicht ganz sauber.

Template A_01a wird nicht benötigt und funktioniert auch nicht. Bei einem 1 channel device wird in State etc. kein POWER1 sondern POWER zurückgegeben! Das heisst der Status wird so nicht aktualisiert.

Gerät A_01 sollte heißen:desc: Applies to devices with one POWER reading like Sonoff Basic, S20, ...

Der Name vom A_01a Template wäre eigentlich super für A_01 da allgemein sonoff Basic ist da nur eine Variante unter sehr vielen bei Tasmota
Danke für den Hinweis. Die A_01 war nur im desc irreführend, oder? Das andere habe ich umbenannt, da das bei mehrkanaligen als template für den ersten Kanal dient - auch hier der Gedanke: am Beispiel lernen.
Zitat
Statt bei COMMAND/POWER1 Ziffern, sollten eigentlich die Texte verwendet werden 0 ist off, 1 ist on, 2 ist toggle. Gibt es da nicht vielleicht auch eine elegantere Variante, dass der Parameter gleich benutzt wird? Schließlich ist
off:noArg COMMAND/POWER1 off
doppelt off ;-) oder eventuell dass mit in setlist das nicht einzeln aufführen muss? wie z. B. beim 4 channel Gerät mit
p1:on,off  COMMAND/POWER1 $EVTPART1

Falls die zusammengefassten Tasmota Geräte gewünscht werden, kann ich auch die templates überarbeiten und hier nochmal bereitstellen.

Bitte ggf. den hier beachten: https://forum.fhem.de/index.php/topic,94495.0.html
(und gerne hier oder gesondert auch Rückmeldung zu den Hinweisen da geben, wenn Verbesserungsvorschläge bestehen).
Hmmm, also dazu folgendes:
Mein Wunsch an Rudi war, bei Schaltanweisungen ein "set_" voranzustellen und das dann jeweils auf state oder das passende Reading zu schreiben (bis die erfolgreiche Ausführung zurückgemeldet wird), hatte dazu auch einen patch vorgeschlagen.
Dazu muß man aber "state"-bezogene und "sonstige Reading-bezogene" Anweisungen unterscheiden können. Will hier bedeuten: on und off, die direkt als "set_on" bzw. "set_off" in den state geschrieben werden sollen, müssen einzelne (:noArg)-Zeilen bleiben, der Rest kann so mit $EVENT arbeiten wie von Dir vorgeschlagen.

Zitat
Was mich an den Templates im Moment am meisten stört, ist dass ich noch keine Lösung habe um über die Icons zu schalten, sprich ein toggle abzusetzen. Ansonsten passt das für mich sehr gut. Bis auf p1, p2 etc in was sprechendes umbenennen und gegebenenfalls die Symbole z. B. auf sani_buffer_temp_down und sani_buffer_temp_up umzustellen, mache ich jetzt bei Neuinbetriebnahmen nichts mehr wesentliches und es geht ruck zuck.
Für die Icon-Sache habe ich im Moment auch keine wirkliche Idee (mangels Device auch keine "Spieloption"), wirf vielleicht mal einen Blick auf diesen Post: https://forum.fhem.de/index.php/topic,86932.msg860636.html#msg860636, da ist evtl. ein Lösungsansatz zu finden.

Was die Umbenennung von "p1, p2" angeht: Macht es Sinn, erst mal die richtige (?) Reading-Benennung zu verwenden (p1=POWER1)? Dann wäre das insoweit konsistent (und ggf. sogar schaltbar?)

Ansonsten freue ich mich, wenn du weitere Templates für die jeweiligen Varianten beisteuern würdest, es kann ja eigentlich kein besseres Ergebnis geben wie: "mache ich jetzt bei Neuinbetriebnahmen nichts mehr wesentliches und es geht ruck zuck"

Zitat
Bitte entschuldigt den langen Post und ich will da auch keinem auf die Nerven gehen, mich würde auch sehr interessieren, wie andere ihre Tasmota konfigurieren. Eventuell wäre da sogar ein eigener Thread sehr interessant zum Austausch.
Ist schon ok mit der Länge, steckt ja auch einiges drin ;) .

Gerne dürft ihr weiterdiskutieren, was wie am besten@tasmota zu konfigurieren ist :) . Die allseits als sehr gut empfundenen Varianten sollten dann in die templates, oder? ;) 8) ::)

Schönes WE allseits!
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 3422
  • Online
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #22 am: 15 Dezember 2018, 14:39:38 »
Template A_01a wird nicht benötigt und funktioniert auch nicht. Bei einem 1 channel device wird in State etc. kein POWER1 sondern POWER zurückgegeben! Das heisst der Status wird so nicht aktualisiert.
das habe ich auch schon bemerkt, da ich heute mal die Neue Version im Update geholt habe, soll heißen ich musste bei
stateFormat{lc ReadingsVal("$name","POWER","") }die "1" ergänzen bei POWER, weil er mir sonst kein devStateIcon anzeigt egal was ich dort eingebe.

Hast du evtl. zu dem devStateIcon eine Lösung..?
Ich z.B. nutze bei allen Sonoff Basic, da sie alle Lampen schalten dieses Icon der Glühlampe welches mir am besten gefällt ist aber ja Ansichtssache

So zeigt er mir die Glülampe an, vorausgesetzt es steht da POWER1:
on:li_wht_on:off off:li_wht_off:on
So zeigt er mir das andere svg Icon, aber auch hier muss POWER1 stehen
ON:li_wht_on:OFF OFF:li_wht_off:ON
ich denke hier wird sich noch einiges ändern lassen da die Geschmäcker da verschieden sind

Nur INFO1,2,3 kommt glaube ich nur beim restart des Tasmota-Gerätes, oder in sehr großen Zeitabständen. Aber auch wenn sich das Gerät neu mit dem mqtt-Server verbindet.
ja da hast du vollkommen Recht, dass wußte ich nicht, denn ich habe ums verrecken keine Infos rein bekommen  :-\
Aber nach dem Neustart des Gerätes waren sie alle da. Vielen Dank

Als Ergänzung hier mal die readings die jetzt alle rein kommen:
READINGS:
     2018-12-15 14:24:07   FallbackTopic   DVES_3B5E50
     2018-12-15 14:24:07   GroupTopic      sonoffs
     2018-12-15 14:24:07   Hostname        WZ_Schrank-7760
     2018-12-15 14:24:07   IPAddress       10.0.0.152
     2018-12-15 14:24:07   LWT             online
     2018-12-15 14:24:07   Module          Sonoff Basic
     2018-12-15 14:24:07   POWER           
     2018-12-15 14:45:38   POWER1          ON
     2018-12-15 14:24:07   RestartReason   Software/System restart
     2018-12-15 14:44:16   Time            2018-12-15T14:44:13
     2018-12-15 14:44:16   Uptime          0T00:20:13
     2018-12-15 14:44:16   Vcc             3.247
     2018-12-15 14:24:07   Version         6.3.0
     2018-12-15 14:24:07   WebServerMode   Admin
     2018-12-15 14:44:16   Wifi_AP         1
     2018-12-15 14:44:16   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-15 14:44:16   Wifi_Channel    11
     2018-12-15 14:44:16   Wifi_RSSI       100
     2018-12-15 14:44:16   Wifi_SSId       xxxxxxxxxxxxxxxxxxx
     2018-12-15 14:45:38   state           on

und das komplette list meines Sonoff Basic:
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_3B5E50
   DEF        DVES_3B5E50
   DEVICETOPIC WZ_Schrank
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     31
   NAME       WZ_Schrank
   NR         4843
   STATE      off
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 31
   m2server_TIME 2018-12-15 14:48:27
   READINGS:
     2018-12-15 14:24:07   FallbackTopic   DVES_3B5E50
     2018-12-15 14:24:07   GroupTopic      sonoffs
     2018-12-15 14:24:07   Hostname        WZ_Schrank-7760
     2018-12-15 14:24:07   IPAddress       10.0.0.152
     2018-12-15 14:24:07   LWT             online
     2018-12-15 14:24:07   Module          Sonoff Basic
     2018-12-15 14:24:07   POWER           
     2018-12-15 14:48:27   POWER1          OFF
     2018-12-15 14:24:07   RestartReason   Software/System restart
     2018-12-15 14:44:16   Time            2018-12-15T14:44:13
     2018-12-15 14:44:16   Uptime          0T00:20:13
     2018-12-15 14:44:16   Vcc             3.247
     2018-12-15 14:24:07   Version         6.3.0
     2018-12-15 14:24:07   WebServerMode   Admin
     2018-12-15 14:44:16   Wifi_AP         1
     2018-12-15 14:44:16   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-15 14:44:16   Wifi_Channel    11
     2018-12-15 14:44:16   Wifi_RSSI       100
     2018-12-15 14:44:16   Wifi_SSId       xxxxxxxxxxxxxxxxxxxxxxxx
     2018-12-15 14:48:27   state           off
Attributes:
   IODev      m2server
   alias      Wohnzimmer Schrank - Vitrine
   autocreate 0
   devStateIcon on:li_wht_on:off off:li_wht_off:on
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   group      Beleuchtung Wohnzimmer
   icon       light_cabinet@#FF6D00
   readingList tele/WZ_Schrank/LWT:.* LWT
  cmnd/WZ_Schrank/POWER:.* POWER
  stat/WZ_Schrank/POWER1:.* POWER1
  tele/WZ_Schrank/STATE:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/SENSOR:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO.:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO1:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO2:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO3:.* { json2nameValue($EVENT) }
  stat/WZ_Schrank/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT,Wohnzimmer
   setList    off:noArg    cmnd/WZ_Schrank/POWER1 0
  on:noArg     cmnd/WZ_Schrank/POWER1 1
  toggle:noArg cmnd/WZ_Schrank/POWER1 2
   sortby     06
   stateFormat {lc ReadingsVal("$name","POWER1","") }
« Letzte Änderung: 15 Dezember 2018, 14:50:19 von moonsorrox »
Intel-NUC i3: FHEM-Server 5.9 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8493
  • eigentlich eher user wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #23 am: 15 Dezember 2018, 14:52:03 »
Hmm, also brauchen wir doch beide - dann stimmt der gerade eingecheckte desc zu der umbenannten 01x-Version wieder nicht, oder verstehe ich hier was miß?...

@moonsorrox: beide templates sind (im Ergebnis) praktisch gleich, nur eben im stateFormat unterschiedlich. Eines sollte ohne Modifikationen passen.

ja da hast du vollkommen Recht, dass wußte ich nicht, denn ich habe ums verrecken keine Infos rein bekommen  :-\
Aber nach dem Neustart des Gerätes waren sie alle da. Vielen Dank
Dann bitte die Info, was man absetzen muß, um den ESP zu "überreden", die Infos zu liefern ::) . (Siehe meinen vorherigen Post). Muß vermutlich kein reboot sein, notfalls aber eben auch das...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 3422
  • Online
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #24 am: 15 Dezember 2018, 15:00:50 »
Hmm, also brauchen wir doch beide - dann stimmt der gerade eingecheckte desc zu der umbenannten 01x-Version wieder nicht, oder verstehe ich hier was miß?...
das habe ich noch nicht kapiert  :-\ weil ich auch gestern schon sagte das ich bei POWER die "1" brauche, oder wir haben beide von etwas anderem gesprochen  ;)

Also ich habe heute zum anlegen des Sonoff Basic den "A_01_tasmota_basic_noprefix" genutzt..!
Wenn du magst kann ich den nochmal komplett löschen und einmal beide Varianten anlegen lassen, also
1. A_01_tasmota_basic_noprefix und
2. A_01a_tasmota_1channel_noprefix
Intel-NUC i3: FHEM-Server 5.9 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8493
  • eigentlich eher user wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #25 am: 15 Dezember 2018, 15:22:10 »
Ok, jetzt ist  hoffentlich auch bei mir der Groschen vollends gefallen.
Für stateFormat also POWER1 bei allen Varianten, der Basic kann daher wirklich für alles als Basis herangezogen werden, auch bzgl. der readingList :D .
Nochmals aktualisierte Version im svn, so bekomme ich das auch geübt ::) .

Wenn das dann effektiv paßt, fliegen die jetzt auskommentierten Teile raus.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 3422
  • Online
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #26 am: 15 Dezember 2018, 15:31:22 »
Zur Info...
ich habe Sonoff Basic, Sonoff 4CH, Sonoff Dual und Sonoff S20 zur Verfügung und zum testen, fehlt noch Sonoff Pow und Sonoff Touch 1-3 mehr kenne ich nicht  :-\ ;)
Die Touch gibt es jetzt auch in Black sehen sehr gut aus und davon hole ich mir die Tage den 3-Kanal

Ein Basic hat noch die Tasmota Version 5.12.0, weil ich nicht über OTA updaten kann und den erst später ausbauen muss um ihn über FTDI zu flaschen..!
Alle anderen  haben Tasmota Version 6.3.0
« Letzte Änderung: 15 Dezember 2018, 15:33:25 von moonsorrox »
Intel-NUC i3: FHEM-Server 5.9 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 3422
  • Online
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #27 am: 15 Dezember 2018, 16:46:54 »
Dann melde ich mich jetzt mal zum Sonoff Dual..!

Aber ich denke da bist du sicher noch nicht soweit um den anzupassen, oder sollte der fertig sein..?
Da ist noch einiges komplett anders... aber hier erst mal zur Information für dich, wenn du noch etwas brauchst sag bescheid

Den Dual habe ich jetzt mal per "template A02a_" eingerichtet und habe mich gewundert warum der in meiner readingsgroup nicht auftaucht.
Eine Info zum Gerät bei Tasmota muss ich ihn anlegen als Dual R2, den anderen der nur Dual heißt, der funktioniert bei mir nicht weil ich wohl einen der neueren Generation habe.

Dann hat er mir davon gleich zwei erstellt obwohl ich nur einen definiert habe, diesen hier "HWR_Dual" habe ich angelegt und den "HWR_Dual_CH2" hat er selber erstellt.
Bei einem hat er keine setlist angelegt bei dem anderen hat er eine setlist angelegt, die angelegte setlist sieht aber komplett anders aus als die der vorherigen Geräte und deshalb schaltet er wohl auch nicht
So sieht die setlist aus vom HWR_Dual_CH2:
off:noArg    COMMAND/POWER2 0
  on:noArg     COMMAND/POWER2 1
  toggle:noArg COMMAND/POWER2 2

readinglist wurde bei beiden Geräten angelegt angelegt.

Ich werde die jetzt nochmals löschen, denn mein MQTT Server sollte doch mit Autocreate die Geräte sobald sie gesehen werden erstellen. Denn ich hatte den Dual vorher ausser Betrieb, da ich ihn aber jetzt einsetzen möchte in meinem HWR wollte ich den mal in Betrieb nehmen.

Habe jetzt nochmal den unten von Hand angelegt
Er hat bei den ersten Angaben andere Readings die mit INFO1-3 beginnen, das denke ich braucht nicht sein da sie ja auch für den zweiten Kanal gelten. Oder die anderen Geräte müßten alle auch so benannt werden da wir sonst Unterschiede in den Readings haben.
Hier mal das list:
Internals:
   CFGFN     
   CID        DVES_98C414
   DEF        DVES_98C414
   DEVICETOPIC HWR_Dual
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     1
   NAME       HWR_Dual
   NR         5806
   STATE      off
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 1
   m2server_TIME 2018-12-15 16:38:56
   READINGS:
     2018-12-15 16:38:48   INFO1_FallbackTopic DVES_98C414
     2018-12-15 16:38:48   INFO1_GroupTopic sonoffs
     2018-12-15 16:38:48   INFO1_Module    Sonoff Dual R2
     2018-12-15 16:38:48   INFO1_Version   6.3.0
     2018-12-15 16:38:48   INFO2_Hostname  HWR_Dual-1044
     2018-12-15 16:38:48   INFO2_IPAddress 10.0.0.154
     2018-12-15 16:38:48   INFO2_WebServerMode Admin
     2018-12-15 16:38:48   INFO3_RestartReason Software/System restart
     2018-12-15 16:38:48   LWT             online
     2018-12-15 16:38:48   POWER           
     2018-12-15 16:38:48   POWER1          OFF
     2018-12-15 16:38:48   POWER2          OFF
     2018-12-15 16:38:48   RESULT_POWER1   OFF
     2018-12-15 16:38:48   RESULT_POWER2   OFF
     2018-12-15 16:38:56   STATE_POWER1    OFF
     2018-12-15 16:38:56   STATE_POWER2    OFF
     2018-12-15 16:38:56   STATE_Time      2018-12-15T16:38:56
     2018-12-15 16:38:56   STATE_Uptime    0T00:00:14
     2018-12-15 16:38:56   STATE_Vcc       3.134
     2018-12-15 16:38:56   STATE_Wifi_AP   2
     2018-12-15 16:38:56   STATE_Wifi_BSSId 9C:C7:A6:08:43:67
     2018-12-15 16:38:56   STATE_Wifi_Channel 8
     2018-12-15 16:38:56   STATE_Wifi_RSSI 100
     2018-12-15 16:38:56   STATE_Wifi_SSId xxxxxxxxxxxxxxx
Attributes:
   IODev      m2server
   comment    Channel 1 for HWR_Dual, see also HWR_Dual_CH2
   readingList DVES_98C414:tele/HWR_Dual/STATE:.* { json2nameValue($EVENT, 'STATE_') }
DVES_98C414:tele/HWR_Dual/LWT:.* LWT
DVES_98C414:cmnd/HWR_Dual/POWER:.* POWER
DVES_98C414:tele/HWR_Dual/INFO1:.* { json2nameValue($EVENT, 'INFO1_') }
DVES_98C414:tele/HWR_Dual/INFO2:.* { json2nameValue($EVENT, 'INFO2_') }
DVES_98C414:tele/HWR_Dual/INFO3:.* { json2nameValue($EVENT, 'INFO3_') }
DVES_98C414:stat/HWR_Dual/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }
DVES_98C414:stat/HWR_Dual/POWER1:.* POWER1
DVES_98C414:stat/HWR_Dual/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }
DVES_98C414:stat/HWR_Dual/POWER2:.* POWER2
   room       MQTT
   stateFormat {lc ReadingsVal("$name","POWER1","") }

Übrigens ich habe beide gelöscht und nun habe ich nur den einen.

Intel-NUC i3: FHEM-Server 5.9 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 8493
  • eigentlich eher user wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #28 am: 15 Dezember 2018, 17:17:34 »
Dann melde ich mich jetzt mal zum Sonoff Dual..!

Aber ich denke da bist du sicher noch nicht soweit um den anzupassen, oder sollte der fertig sein..?
Hmmm, wie ich das sehe, könnte da das 4-ch-template (one device) an sich passen, müßte aber eben um die zwei Kanäle gekürzt werden.

Du hast das 2-ch-template verwendet, oder? Da ist es "normal", dass zwei Devices angelegt werden, steht auch so in der desc. Komisch ist aber, dass er COMMAND nicht übersetzt hat. Da sollte stattdessen "tele/HWR_Dual" stehen.

Ansonsten sehe ich im Moment nicht, dass der von der MQTT-Seite her speziell wäre.

Kann aber grade nicht intensiv drüber sehen, versuch dich ruhig selbst (nach der Anleitung in dem contribute-Thread).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 3422
  • Online
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #29 am: 15 Dezember 2018, 17:22:41 »
Ja ich habe dieses verwednet "template A02a_"

Ehrlich gesagt finde ich das anlegen der zwei Kanäle wesentlich übersichtlicher und besser, es erscheinen beide Kanäle und das ist gut so als wenn man da alle in einem hat, das kann man besser Konfigurieren da ja sowieso alle für andere Geräte verwendet werden.
Das sollte man mal in die Runde fragen was da gewünscht ist..!

Ja das mit der setlist habe ich schon bereinigt bei mir und dann schaltet es auch  ;)

Die anderen readings versuche ich mal in meiner rg unterzubringen damit diese auf zwei unterschiedliche readings anspricht

Ich hänge mal den Screenshot meiner MQTT Geräte ran  ;)
« Letzte Änderung: 15 Dezember 2018, 17:36:14 von moonsorrox »
Intel-NUC i3: FHEM-Server 5.9 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

 

decade-submarginal