Hallo,
ich habe jetzt meine erste Sonoff S20 Steckdose mit Tasmato geflasht, und dann in Fhem den MQTT2 Server installiert und autocreate aktiviert. DIe S 20 wird dann auch sofort gefunden, ich habe dann das Templeta A_01a_tasmato_basic_state_power1 zu geordnet, war das das richtige?
Das on/off schalten über das Fhem Webif funktioniert zumindest, nur der aktuelle Status wird mir nicht angezeigt, da steht immer nur POWER1, wieso ist das so?
Internals:
CID DVES_37B49797
DEF DVES_37B49797
DEVICETOPIC MQTT2_DVES_37B49797
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 66
MQTT2_FHEM_Server_TIME 2019-01-05 16:37:49
MSGCNT 66
NAME Laya_Steckdose_Sonoff
NR 388
STATE POWER1
TYPE MQTT2_DEVICE
Helper:
DBLOG:
LWT:
myDbLog:
TIME 1546685437.28996
VALUE Online
LoadAvg:
myDbLog:
TIME 1546702669.12276
VALUE 19
POWER:
myDbLog:
TIME 1546702669.12276
VALUE on
Sleep:
myDbLog:
TIME 1546702669.12276
VALUE 50
SleepMode:
myDbLog:
TIME 1546702669.12276
VALUE Dynamic
Time:
myDbLog:
TIME 1546702669.12276
VALUE 2019-01-05T16:37:48
Uptime:
myDbLog:
TIME 1546702669.12276
VALUE 0T22:46:53
Vcc:
myDbLog:
TIME 1546702669.12276
VALUE 3.505
Wifi_AP:
myDbLog:
TIME 1546702669.12276
VALUE 1
Wifi_BSSId:
myDbLog:
TIME 1546702669.12276
VALUE 44:4E:6D:9B:DD:E9
Wifi_Channel:
myDbLog:
TIME 1546702669.12276
VALUE 13
Wifi_RSSI:
myDbLog:
TIME 1546702669.12276
VALUE 52
Wifi_SSId:
myDbLog:
TIME 1546702669.12276
VALUE T&T2,4
state:
myDbLog:
TIME 1546702620.82828
VALUE set_on
READINGS:
2019-01-05 11:50:37 LWT Online
2019-01-05 16:37:49 LoadAvg 19
2019-01-05 16:37:49 POWER ON
2019-01-05 16:37:49 Sleep 50
2019-01-05 16:37:49 SleepMode Dynamic
2019-01-05 16:37:49 Time 2019-01-05T16:37:48
2019-01-05 16:37:49 Uptime 0T22:46:53
2019-01-05 16:37:49 Vcc 3.505
2019-01-05 16:37:49 Wifi_AP 1
2019-01-05 16:37:49 Wifi_BSSId 44:4E:6D:9B:DD:E9
2019-01-05 16:37:49 Wifi_Channel 13
2019-01-05 16:37:49 Wifi_RSSI 52
2019-01-05 16:37:49 Wifi_SSId T&T2,4
2019-01-05 16:37:00 state set_on
Attributes:
IODev MQTT2_FHEM_Server
autocreate 0
eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
group Steckdosen
model A_01a_tasmota_basic_state_power1
readingList tele/layamicky/LWT:.* LWT
tele/layamicky/STATE:.* { json2nameValue($EVENT) }
tele/layamicky/SENSOR:.* { json2nameValue($EVENT) }
tele/layamicky/INFO.:.* { json2nameValue($EVENT) }
stat/layamicky/RESULT:.* { json2nameValue($EVENT) }
room Kinderzimmer_Laya
setList off:noArg cmnd/layamicky/POWER1 0
on:noArg cmnd/layamicky/POWER1 1
toggle:noArg cmnd/layamicky/POWER1 2
setStateList on off toggle
stateFormat POWER1
Das zweite Problem welches ich habe ist, das ich die Dose nicht über meine FTUI definition Steuern kann, einer eine idee wieso nicht?
data-row="4" data-col="6" data-sizex="1" data-sizey="1">
<header class="headerTransparent">Laya<br>Licht</header>
<div data-type="switch" data-off-background-color="#aaaaaa" data-on-background-color="#aaaaaa" data-icon="fa-plug" data-device='Laya_Steckdose_Sonoff'
data-get-on='["on","off"]' data-colors='["#00ff00","#ff0000"]' data-set-on="on" data-set-off="off" class="cell"></div>
Danke
EDIT
Ich glaub ich habe es gefunden der Wert "POWER1" war falsch, es muss "POWER" heissen. Aber der war automatisch gesetzt, wieso?
...weil das so in dem template hinterlegt ist.
Für Einfach-Devices ist eigentlich das "Basic"-template (das aber bis zum Update morgen früh noch kaputt ist).
Hast du eine Rückmeldung, wenn du über den Button am Device schaltest? (Es gibt grad in dem "Eine Frage..."-Thread dazu auch eine Teildiskussion).
Ja der state wird im POWER reading aktualisiert, das funktioniert.
Die eigentliche Rückmeldung vom dem Device kommt über das Reading "RESULT_POWER".
Ist aber auch nur bei den neuren tasmota-Versionen so.
Zitat von: Papaloewe am 05 Januar 2019, 17:00:23
Die eigentliche Rückmeldung vom dem Device kommt über das Reading "RESULT_POWER".
Ist aber auch nur bei den neuren tasmota-Versionen so.
Sollte dann stateFormat RESULT_POWER sein, oder?
Kann man das irgendwie fest machen, ab welcher Tasmota-Version das so ist, dann würde ich ggf. das Basic-template so anpassen bzw. ein 2. für die neueren firmwares bereitstellen?
Für die, die POWER1 nutzen (mit dieser 26-er Option) ändert sich ja nichts, oder?
Scheint als es das neue RESULT-Topic ab der tasmota Version 5.14.0 gibt.
Ja, ich habe das stateformat auf RESULT_POWER bei mir gesetzt.
lst ist doch schon etwas länger her.
https://github.com/klein0r/fhem-tasmota/issues/17 (https://github.com/klein0r/fhem-tasmota/issues/17)
@Papaloewe:
Du nutzt das andere Modul und MQTT als IO, oder?
Die MQTT2-Module packen das vermutlich anders aus als das TASMOTA_DEVICE-Modul, da würde ich drauf tippen, dass das passt.
@Tommy82: Oder hast du bei aktiviertem autocreate (müßtest du dazu ändern) andere Erkenntnisse?
Wo liegt jetzt noch das Problem? Bei FTUI?
Zitat
Ja der state wird im POWER reading aktualisiert, das funktioniert.
Das ist bei mir auch so, aber state wird nicht aktualisiert, wenn über den Taster geschaltet wird.
Wird über set geschaltet, dann wird state aktualisiert.
Ist das bei dir auch so?
Falls state bei dir in beiden Fällen aktualisiert wird, zeig doch mal die Def, dann kann ich es auch mal probieren.
ZitatDas ist bei mir auch so, aber state wird nicht aktualisiert, wenn über den Taster geschaltet wird.
Warum genau stoert das?
Zitat von: Papaloewe am 05 Januar 2019, 17:00:23
Die eigentliche Rückmeldung vom dem Device kommt über das Reading "RESULT_POWER".
Ist aber auch nur bei den neuren tasmota-Versionen so.
Hi,
das ist seltsam, bei mir gibt es kein Reading "RESULT_POWER", die Rückmeldung kommt bei mir im Reading "POWER"
Zitat von: Beta-User am 05 Januar 2019, 17:41:12
@Tommy82: Oder hast du bei aktiviertem autocreate (müßtest du dazu ändern) andere Erkenntnisse?
Wo liegt jetzt noch das Problem? Bei FTUI?
De Fehler war bei mir das na dem setzen des nach dem setzen des Templates, in den Attributen "setList" "POWER1" und in "stateFormat" auch "POWER1" stand, nachdem ich das auf "POWER" geändert habe funktioniert auch alles über die FTUI, dazu kommt das meine Definition in der FTUI noch aus Zeiten von MQTT war und dort "ON" und "OFF" waren, und jetzt bei MQTT2 "on" und "off" sind.
Was meinst du mit autocreate? Im MQTT2 Server? da ist autocreate aktiv
Zitat von: Invers am 05 Januar 2019, 17:56:21
Falls state bei dir in beiden Fällen aktualisiert wird, zeig doch mal die Def, dann kann ich es auch mal probieren.
Bei mir wird der "POWER" state aktualisiert wenn ich den Taster drücke. Die Def des Devices steht etwas weiter oben
ZitatWarum genau stoert das?
Ich vermute, weil eine Abfrage auf state dann sinnlos wird, wenn es mal stimmt und mal nicht und weil das devStateIcon daran hängt!? Sowas wie [Steckdose_3] eq "on" muss dann leider [Steckdose_3:POWER] eq "ON" heissen.
@Tommy82
Schde, geht dann ja bei dir auch nicht.
ZitatIch vermute, weil eine Abfrage auf state dann sinnlos wird, wenn es mal stimmt und mal nicht und weil das devStateIcon daran hängt!? Sowas wie [Steckdose_3] eq "on" muss dann leider [Steckdose_3:POWER] eq "ON" heissen.
Danke.
DOIF hatte ich nicht auf dem Schirm, und devStateIcon wohl auch verdraengt.
Um solche Probleme zu vermeiden sollten wir statt
attr DEVICE stateFormat POWERlieber
attr DEVICE userReadings state:POWER:.* { lc(ReadingsVal("DEVICE","POWER","")) }verwenden.
Hier mal das List eines frisch erkannten Tasmota-Devices:
defmod MQTT2_tasmota_gosund5723 MQTT2_DEVICE tasmota_gosund5723
attr MQTT2_tasmota_gosund5723 IODev MQTT2_mosquito
attr MQTT2_tasmota_gosund5723 readingList tasmota/gosund-5723/tele/STATE:.* { json2nameValue($EVENT, 'STATE_', $JSONMAP) }\
tasmota/gosund-5723/tele/SENSOR:.* { json2nameValue($EVENT, 'SENSOR_', $JSONMAP) }\
tasmota/gosund-5723/stat/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }\
tasmota/gosund-5723/stat/POWER:.* POWER\
tasmota/gosund-5723/stat/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }\
tasmota/gosund-5723/stat/POWER:.* POWER
attr MQTT2_tasmota_gosund5723 room MQTT2_DEVICE
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:23:01 POWER OFF
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:23:01 RESULT_POWER OFF
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_ApparentPower 30
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_Current 0.132
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_Factor 0.01
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_Period 0
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_Power 0
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_ReactivePower 30
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_Today 0.161
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_Total 29.603
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_TotalStartTime 2018-10-31T18:23:23
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_Voltage 229
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_ENERGY_Yesterday 0.316
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 SENSOR_Time 2019-01-05T19:22:39
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_LoadAvg 19
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_POWER OFF
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Sleep 50
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_SleepMode Dynamic
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Time 2019-01-05T19:22:39
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Uptime 0T00:05:14
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Vcc 3.409
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Wifi_AP 1
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Wifi_BSSId 82:2A:A8:17:C0:E0
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Wifi_Channel 6
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Wifi_RSSI 100
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:22:39 STATE_Wifi_SSId sh@4loewen.de
setstate MQTT2_tasmota_gosund5723 2019-01-05 19:23:01 associatedWith ESP_MQTT2_Bridge
"POWER_RESULT" wird aus dem json-String des RESULT Topics erzeugt.
Wenn ich manuell schalte ändert sich genau dieses Reading.
Aber eben auch bei einem publish tasmota/gosund-2464/cmnd/POWER 0/1
Zitat von: Invers am 05 Januar 2019, 18:51:07
@Tommy82
Schde, geht dann ja bei dir auch nicht.
Was geht bei mir nicht? Der state wird doch aktualisiert
Zitat von: Papaloewe am 05 Januar 2019, 19:30:10
Hier mal das List eines frisch erkannten Tasmota-Devices:
"POWER_RESULT" wird aus dem json-String des RESULT Topics erzeugt.
Wenn ich manuell schalte ändert sich genau dieses Reading.
Aber eben auch bei einem publish tasmota/gosund-2464/cmnd/POWER 0/1
Dann müsste das POWER bei mir aus dem Template set kommen?
ZitatUm solche Probleme zu vermeiden sollten wir statt
Code: [Auswählen]
attr DEVICE stateFormat POWER
lieber
Code: [Auswählen]
attr DEVICE userReadings state:POWER:.* { lc(ReadingsVal("DEVICE","POWER","")) }
verwenden.
Herzlichen Dank. Damit wird state aktualisiert, zeigt on und off und devStateIcon wird korrekt angezeigt. Somit sind alle Probleme zu state gelöst, soweit ich das derzeit beurteilen kann. Bin begeistert.
Auch allen Anderen noch einmal meinen herzlichen Dank für die Geduld und Mühe.
Zitat von: rudolfkoenig am 05 Januar 2019, 19:13:55
Um solche Probleme zu vermeiden sollten wir statt
attr DEVICE stateFormat POWER
lieberattr DEVICE userReadings state:POWER:.* { lc(ReadingsVal("DEVICE","POWER","")) }verwenden.
Habe es eben für die Tasmotas in die templates eingecheckt.
@all:
Damit funktionieren hoffentlich nach einem update morgen die Tasmota-templates für eure Anwendungsfälle wie gewünscht.
@Papaloewe:
Du hast ein typisches list vor Anwendung eines der templates. Tommy82 und Invers hatten jeweils eines angewandt bzw. die Attribute selbst angepaßt.
Was es mit den templates auf sich hat, kannst du z.B. hier nachlesen: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele.
@Papaloewe
ZitatHier mal das List eines frisch erkannten Tasmota-Devices:
attr MQTT2_tasmota_gosund5723 readingList\
tasmota/gosund-5723/tele/STATE:.* { json2nameValue($EVENT, 'STATE_', $JSONMAP) }\
tasmota/gosund-5723/tele/SENSOR:.* { json2nameValue($EVENT, 'SENSOR_', $JSONMAP) }\
tasmota/gosund-5723/stat/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }\
tasmota/gosund-5723/stat/POWER:.* POWER\
tasmota/gosund-5723/stat/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }\
tasmota/gosund-5723/stat/POWER:.* POWER
Handelt es sich hier um einen Kopierfehler oder enthält die readingList des frisch erkannten Tasmota-Devices tatsächlich 2x die folgenden Zeilen
tasmota/gosund-5723/stat/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }\
tasmota/gosund-5723/stat/POWER:.* POWER
Nein, das war kein Kopierfehler!
Die beiden Einträge sind doppelt automatisch angelegt worden.
Warum, weiß ich auch nicht?
Hab gerade mal A_01_tasmota_basic mit ein paar Sonoffs probiert, funktioniert jetzt alles gut.
Ein paar Anmerkungen noch zu A_04b_tasmota_4ch_unified_icon, ich hab es mit einer 4-fach Steckdose getestet:
Es wird ein Raum mit dem Devicenamen angelegt, das war wohl nicht so gedacht?!
Das devStateIcon hat ein paar div zuviel oder zuwenig, kommt drauf an welche Darstellung beabsichtigt war. Ich hab jetzt mal so gemacht:
{ "<div><a href=\"/fhem?cmd.dummy=set ".$name." p1 toggle&XHR=1\">POWER1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off")) . "</a> <a href=\"/fhem?cmd.dummy=set ".$name." p2 toggle&XHR=1\">POWER2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off")) . "</a> <a href=\"/fhem?cmd.dummy=set ".$name." p3 toggle&XHR=1\">POWER3:" . FW_makeImage(lc ReadingsVal($name, "POWER3", "off")) . "</a> <a href=\"/fhem?cmd.dummy=set ".$name." p4 toggle&XHR=1\">POWER4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off")) . "</a></div>" }
Es gibt ein Userreading:
state:POWER1:.* { lc(ReadingsVal("VIFLYKOO_SH21","POWER1","")) }
Damit hat man nur die erste Steckdose im state. Ich hab das hier so geändert:
state:POWER.*:.* { lc(ReadingsVal($NAME,"POWER1","") . " " . ReadingsVal($NAME,"POWER2","") . " " .
ReadingsVal($NAME,"POWER3","") . " " . ReadingsVal($NAME,"POWER4","")) }
Thx @sinus61,
hab's hoffentlich soweit vollständig mit übernommen; hin und wieder hat die "Vererberei" auch ihre Nachteile...
Zitat von: Tommy82 am 05 Januar 2019, 18:37:55
Hi,
das ist seltsam, bei mir gibt es kein Reading "RESULT_POWER", die Rückmeldung kommt bei mir im Reading "POWER"
De Fehler war bei mir das na dem setzen des nach dem setzen des Templates, in den Attributen "setList" "POWER1" und in "stateFormat" auch "POWER1" stand, nachdem ich das auf "POWER" geändert habe funktioniert auch alles über die FTUI, dazu kommt das meine Definition in der FTUI noch aus Zeiten von MQTT war und dort "ON" und "OFF" waren, und jetzt bei MQTT2 "on" und "off" sind.
Bitte das nicht vermischen. Result_ wird in FHEM nur angezeigt/benutzt wenn die Templates nicht benutzt werden!
Also das Gerät normal mit autocreate erzeugt wurde und kein Template angewandt wurde.
Mit den Tasmota-Templates in FHEM ist das alles kein Problem! Die Probleme kamen vor allem mit FHEM seit bei autocreate die RESULT_ etc. in den Readings ausgegeben wird. Erst ab da fand das alte Überlagern der Readings nicht mehr statt. Das Problem ist genauso mit STATE_ ...
Das hat mich am Anfang auch verwirrt, aber dank den Templates kann man das einfach korrigieren. Das Problem sind wohl andere MQTT-Geräte wo das Klassifizieren wohl sinnvoll ist. Man kann es hier wohl schlicht nicht allen recht machen mit autocreate ;-)
Ist evtl. nur die eventMap das "Problem"?