Hallo,
ich stehe gerade komplett auf dem Schlauch.
ich habe schon jede Menge Tasmota-Devices (Sonoff Basic, Wemos Mini D1) über MQTT2 in FHEM eingebunden. Schalten und Schaltzustand melden (auch bei Schalten über das Web-IF der Geräte) funktioniert einwandfrei.
Jetzt wollte ich noch einen Shelly 1 über MQTT2 einbinden.
- Automatisches Anlegen ==> kein Problem
- Readings werden (beim Schalten über das WEB-IF des Shelly) richtig aktualisiert
- Schalten aus FHEM funktioniert nicht (nicht richtig)
Wenn ich extern schalte, dann wird das Reading "relay_0" auf "on" oder "off" aktuallisiert
Wenn ich aus FHEM schalte, dann wird aber das Reading "state" geschaltet und nicht "relay_0" und damit auch nicht das physische Relais im Shelly.
Ich suche/probiere jetzt schon seit Stunden, finde aber den Fehler nicht.
Funktionierende Konfi eines Sonoff Basic:defmod MQTT2_DVES_D5A12E MQTT2_DEVICE DVES_D5A12E
attr MQTT2_DVES_D5A12E IODev MQTT2_FHEM_Server
attr MQTT2_DVES_D5A12E alias Stehlampe
attr MQTT2_DVES_D5A12E devStateIcon EIN:li_wht_on on:li_wht_on AUS:li_wht_off off:li_wht_off
attr MQTT2_DVES_D5A12E event-on-change-reading POWER
attr MQTT2_DVES_D5A12E eventMap on:EIN off:AUS
attr MQTT2_DVES_D5A12E group EG.Diele
attr MQTT2_DVES_D5A12E icon light_floor_lamp
attr MQTT2_DVES_D5A12E readingList DVES_D5A12E:tele/IoT_Stehlampe_Flur/LWT:.* LWT\
DVES_D5A12E:cmnd/IoT_Stehlampe_Flur/POWER:.* POWER\
DVES_D5A12E:tele/IoT_Stehlampe_Flur/INFO1:.* { json2nameValue($EVENT) }\
DVES_D5A12E:tele/IoT_Stehlampe_Flur/INFO2:.* { json2nameValue($EVENT) }\
DVES_D5A12E:tele/IoT_Stehlampe_Flur/INFO3:.* { json2nameValue($EVENT) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/RESULT:.* { json2nameValue($EVENT) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/POWER:.* POWER\
DVES_D5A12E:tele/IoT_Stehlampe_Flur/STATE:.* { json2nameValue($EVENT) }\
DVES_D5A12E:tele/IoT_Stehlampe_Flur/UPTIME:.* { json2nameValue($EVENT) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS:.* { json2nameValue($EVENT, 'STATUS_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS1:.* { json2nameValue($EVENT, 'STATUS1_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS2:.* { json2nameValue($EVENT, 'STATUS2_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS3:.* { json2nameValue($EVENT, 'STATUS3_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS4:.* { json2nameValue($EVENT, 'STATUS4_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS5:.* { json2nameValue($EVENT, 'STATUS5_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS6:.* { json2nameValue($EVENT, 'STATUS6_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS7:.* { json2nameValue($EVENT, 'STATUS7_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS10:.* { json2nameValue($EVENT, 'STATUS10_', $JSONMAP) }\
DVES_D5A12E:stat/IoT_Stehlampe_Flur/STATUS11:.* { json2nameValue($EVENT, 'STATUS11_', $JSONMAP) }\
DVES_D5A12E:EG:.* EG
attr MQTT2_DVES_D5A12E room Aktoren,Erdgeschoß
attr MQTT2_DVES_D5A12E setList on cmnd/IoT_Stehlampe_Flur/POWER ON\
off cmnd/IoT_Stehlampe_Flur/POWER OFF
attr MQTT2_DVES_D5A12E sortby 05
attr MQTT2_DVES_D5A12E webCmd EIN:AUS
setstate MQTT2_DVES_D5A12E EIN
setstate MQTT2_DVES_D5A12E 2019-01-25 18:15:04 EG off
setstate MQTT2_DVES_D5A12E 2018-12-29 23:30:34 FallbackTopic DVES_D5A12E
setstate MQTT2_DVES_D5A12E 2018-12-29 23:30:34 GroupTopic sonoffs
setstate MQTT2_DVES_D5A12E 2018-12-29 23:30:34 Hostname IoT_Stehlampe_Flur-0302
setstate MQTT2_DVES_D5A12E 2018-12-29 23:30:34 IPAddress 192.168.178.161
setstate MQTT2_DVES_D5A12E 2019-02-10 15:21:04 LWT online
setstate MQTT2_DVES_D5A12E 2018-12-29 23:30:34 Module Sonoff Basic
setstate MQTT2_DVES_D5A12E 2019-02-10 15:21:04 POWER
setstate MQTT2_DVES_D5A12E 2018-12-29 23:30:34 RestartReason Software Watchdog
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:48 STATUS10_StatusSNS_Time 2019-01-25T17:24:41
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_POWER ON
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_Time 2019-01-25T17:24:41
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_Uptime 26T17:55:56
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_Vcc 3.191
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_Wifi_AP 1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_Wifi_BSSId 38:10:D5:CD:8B:0A
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_Wifi_Channel 6
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_Wifi_RSSI 64
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:49 STATUS11_StatusSTS_Wifi_SSId WLAN FRITZ!Mesh
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_Baudrate 115200
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_BootCount 29
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_GroupTopic sonoffs
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_OtaUrl http://thehackbox.org/tasmota/release/sonoff.bin
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_RestartReason Software Watchdog
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_SaveAddress F4000
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_SaveCount 384
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_Sleep 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_StartupUTC 2018-12-29T22:28:45
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS1_StatusPRM_Uptime 26T17:55:56
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS2_StatusFWR_Boot 7
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS2_StatusFWR_BuildDateTime 2018.11.28 21:30:26
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS2_StatusFWR_Core 2_3_0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS2_StatusFWR_SDK 1.5.3(aec24ac9)
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS2_StatusFWR_Version 6.3.0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_LogHost
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_LogPort 514
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_SSId_1 WLAN FRITZ!Mesh
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_SSId_2
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_SerialLog 2
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_SetOption_1 00008009
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_SetOption_2 55818000
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_SetOption_3 00000001
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_SysLog 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_TelePeriod 300
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS3_StatusLOG_WebLog 2
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_Features_1 00000407
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_Features_2 0FDAE794
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_Features_3 240183A0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_Features_4 23B617CE
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_Features_5 00003BC0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_FlashMode 3
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_FlashSize 1024
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_Free 508
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_Heap 17
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_ProgramFlashSize 1024
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:42 STATUS4_StatusMEM_ProgramSize 492
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:43 STATUS5_StatusNET_DNSServer 192.168.178.1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:43 STATUS5_StatusNET_Gateway 192.168.178.1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:43 STATUS5_StatusNET_Hostname IoT_Stehlampe_Flur-0302
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:43 STATUS5_StatusNET_IPAddress 192.168.178.161
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:43 STATUS5_StatusNET_Mac DC:4F:22:D5:A1:2E
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:43 STATUS5_StatusNET_Subnetmask 255.255.255.0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:43 STATUS5_StatusNET_Webserver 2
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:43 STATUS5_StatusNET_WifiConfig 5
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:44 STATUS6_StatusMQT_KEEPALIVE 15
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:44 STATUS6_StatusMQT_MAX_PACKET_SIZE 1000
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:44 STATUS6_StatusMQT_MqttClient DVES_D5A12E
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:44 STATUS6_StatusMQT_MqttClientMask DVES_%06X
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:44 STATUS6_StatusMQT_MqttHost 192.168.178.130
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:44 STATUS6_StatusMQT_MqttPort 1883
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:44 STATUS6_StatusMQT_MqttType 1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:44 STATUS6_StatusMQT_MqttUser DVES_USER
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:45 STATUS7_StatusTIM_EndDST Sun Oct 27 03:00:00 2019
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:45 STATUS7_StatusTIM_Local Fri Jan 25 17:24:41 2019
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:45 STATUS7_StatusTIM_StartDST Sun Mar 31 02:00:00 2019
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:45 STATUS7_StatusTIM_Sunrise 08:29
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:45 STATUS7_StatusTIM_Sunset 17:35
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:45 STATUS7_StatusTIM_Timezone 1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:45 STATUS7_StatusTIM_UTC Fri Jan 25 16:24:41 2019
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_ButtonRetain 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_ButtonTopic 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_FriendlyName_1 Stehlampe Diele
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_LedState 1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_Module 1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_Power 1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_PowerOnState 3
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_PowerRetain 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SaveData 1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SaveState 1
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SensorRetain 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchMode_1 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchMode_2 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchMode_3 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchMode_4 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchMode_5 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchMode_6 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchMode_7 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchRetain 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_SwitchTopic 0
setstate MQTT2_DVES_D5A12E 2019-01-25 17:24:41 STATUS_Status_Topic IoT_Stehlampe_Flur
setstate MQTT2_DVES_D5A12E 2019-02-10 15:13:10 Time 2019-02-10T15:13:08
setstate MQTT2_DVES_D5A12E 2019-02-10 15:13:10 Uptime 42T15:44:23
setstate MQTT2_DVES_D5A12E 2019-02-10 15:13:10 Vcc 3.193
setstate MQTT2_DVES_D5A12E 2018-12-29 23:30:34 Version 6.3.0
setstate MQTT2_DVES_D5A12E 2018-12-29 23:30:34 WebServerMode Admin
setstate MQTT2_DVES_D5A12E 2019-02-10 15:13:10 Wifi_AP 1
setstate MQTT2_DVES_D5A12E 2019-02-10 15:13:10 Wifi_BSSId C8:0E:14:44:82:0B
setstate MQTT2_DVES_D5A12E 2019-02-10 15:13:10 Wifi_Channel 1
setstate MQTT2_DVES_D5A12E 2019-02-10 15:13:10 Wifi_RSSI 82
setstate MQTT2_DVES_D5A12E 2019-02-10 15:13:10 Wifi_SSId WLAN FRITZ!Mesh
setstate MQTT2_DVES_D5A12E 2019-02-10 14:13:31 state on
Nicht funktionierende Konfi eines des Shelly 1:defmod MQTT2_shelly1_12CB79 MQTT2_DEVICE shelly1_12CB79
attr MQTT2_shelly1_12CB79 IODev MQTT2_FHEM_Server
attr MQTT2_shelly1_12CB79 alias Pumpe WW (Speicher)
attr MQTT2_shelly1_12CB79 devStateIcon EIN:li_wht_on on:li_wht_on AUS:li_wht_off off:li_wht_off
attr MQTT2_shelly1_12CB79 event-on-change-reading .*
attr MQTT2_shelly1_12CB79 group Heizung
attr MQTT2_shelly1_12CB79 icon sani_pump
attr MQTT2_shelly1_12CB79 readingList shelly1_12CB79:shellies/shelly1-12CB79/online:.* online\
shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* relay_0\
shelly1_12CB79:shellies/shelly1-12CB79/input/0:.* input_0
attr MQTT2_shelly1_12CB79 room Kellergeschoß,MQTT2_DEVICE
attr MQTT2_shelly1_12CB79 setList on cmd/shellies/shelly1-12CB79/relay/0 on\
off cmd/shellies/shelly1-12CB79/relay/0 off
attr MQTT2_shelly1_12CB79 sortby 04
attr MQTT2_shelly1_12CB79 webCmd on:off
setstate MQTT2_shelly1_12CB79 on
setstate MQTT2_shelly1_12CB79 2019-02-10 15:21:49 input_0 0
setstate MQTT2_shelly1_12CB79 2019-02-10 14:48:48 online true
setstate MQTT2_shelly1_12CB79 2019-02-10 11:38:05 power off
setstate MQTT2_shelly1_12CB79 2019-02-10 15:21:49 relay_0 off
setstate MQTT2_shelly1_12CB79 2019-02-10 14:48:46 shelly1-12CB79 false
setstate MQTT2_shelly1_12CB79 2019-02-10 15:05:24 state on
attr MQTT2_shelly1_12CB79 setList on cmd/shellies/shelly1-12CB79/relay/0 on\
off cmd/shellies/shelly1-12CB79/relay/0 off
Ohne den "Shelly 1" zu kennen (bzw. das gilt fuer alle Geraete): man muss das Attribut setList "richtig" setzen, d.h. topic und message muessen genau sein.
Was richtig ist, kann man aus der Geraete/Firmware-Doku und aus der aktuellen Konfiguration des Geraetes entnehmen.
Einen Hinweis fuer die topics findet man beim Einsatz von MQTT2_SERVER per "list .* subscriptions", weil die Geraete nur auf diese topics hoeren.
Zitat von: rudolfkoenig am 10 Februar 2019, 15:44:21
list .* subscriptions
erstmal thx für diese info.
gehört aber in mein augen irgendwo dokumentiert ... commandref? wiki?
Hallo Rudi,
vielen Dank. Hätte ich ja auch selbst drauf kommen können. Das war schonmal die Hälfte der "Miete". In der Shelly-Doku ist der richtige Befehl beschrieben, d.h.
"on shellies/shelly1-12CB79/relay/0/command on"
und NICHT
"on cmd/shellies/shelly1-12CB79/relay/0 on" (Das paßt für Sonoff).
Ich kann jetzt den Shelly von FHEM aus schalten und die Anzeigen in FHEM (DevStateIcon) und im Shelly Web-IF funktionieren und passen.
Was noch nicht funktioniert, bzw. ich auch noch nicht richtig verstehe ist, daß ein externes Schalten (also über das Shelly Web-IF) die Anzeige in FHEM nicht umschaltet. Das zuständige Reading heißt "relay_0" und wird richtig umgeschaltet, egal von wo ich schalte, aber die Anzeige in FHEM schaltet nur richtig wenn ich über FHEM schalte. Auf was bezieht sich denn das "on/off" in DevStateIcon? Normal ja auf das Reading "state", aber das ändert sich nicht, egal von wo ich schalte.
Hallo,
also ich weiß nicht warum, aber das Reading "state" verändert sich nun doch. Damit ist zumindest wieder alles logisch.
Trotzdem bleibt noch die Frage wie kann ich das attr "DevStateIcon" dazu bringen auf das Reading "relay_0" zu hören und NICHT auf das Reading "state"? Kann man das irgendwie "mappen"?
Gruß
So, ich habe jetzt mal (zumindest temporär) eine Lösungsmöglichkeit gefunden. Ich habe einfach in meiner readingList dem Wert für ...relay/0 das Reading "state" zugewiesen. Damit habe ich mein "mapping" und es funktioniert alles so wie es soll.
Allerdings funktioniert das natürlich nur für einen Shelly 1. Bei einem Shelly 2, oder 4 (mit seinen 2, bzw. 4 Kanälen) funktioniert dieser Workaround natürlich nicht mehr. D.h. mein Problem bleibt weiterhin aktuell.
Wie kann ich das attr "DevStateIcon" dazu bringen auf das Reading "relay_0" zu hören und NICHT auf das Reading "state"? Kann man das irgendwie "mappen"?
Gruß und noch einen schönen Sonntag Abend
Du hast aber schon gesehen, dass für viele der Dinge, die du hier abarbeitest vielleicht Lösungen in den AttrTemplates enthalten sind?
@Beta-User
ja klar, habe ich schon gesehen, aber leider funktioniert es eben nicht richtig.
Ok, das mit dem Command war mein Fehler. Ist mir einfach nicht aufgefallen daß beim Sonoff der "cmd" vorne steht und beim Shelly der "command" hinten.
Aber bezüglich dem 2. Punkt "mappen" von reading relay_0 auf state war das zwar im Template vorhanden, funktioniert aber nicht, d.h.
defmod MQTT2_shelly1_12CB79 MQTT2_DEVICE shelly1_12CB79
attr MQTT2_shelly1_12CB79 IODev MQTT2_FHEM_Server
attr MQTT2_shelly1_12CB79 alias Pumpe WW (Speicher)
attr MQTT2_shelly1_12CB79 devStateIcon EIN:li_wht_on on:li_wht_on AUS:li_wht_off off:li_wht_off
attr MQTT2_shelly1_12CB79 event-on-change-reading .*
attr MQTT2_shelly1_12CB79 group Heizung
attr MQTT2_shelly1_12CB79 icon sani_pump
attr MQTT2_shelly1_12CB79 model A_10_shelly1
attr MQTT2_shelly1_12CB79 readingList shellies/shelly1-12CB79/relay/0:.* state\
shellies/shelly1-12CB79/relay/0:.* relay0\
shellies/shelly1-12CB79/input/0:.* input0\
shellies/shelly1-12CB79/online:.* online\
shellies/shelly1-12CB79/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr MQTT2_shelly1_12CB79 room Kellergeschoß,MQTT2_DEVICE
attr MQTT2_shelly1_12CB79 setList off:noArg shellies/shelly1-12CB79/relay/0/command off\
on:noArg shellies/shelly1-12CB79/relay/0/command on
attr MQTT2_shelly1_12CB79 sortby 04
attr MQTT2_shelly1_12CB79 webCmd on:off
Wenn ich von FHEM aus schalte ist alles ok:
- DeviceStateIcon schaltet um
- Anzeige im Shelly Web-IF schaltet um
Wenn ich aber vom Shelly Web-IF aus schalte, dann:
- Shelly schaltet
- richtige Anzeige im Shelly Web-IF
- richtiger Wert im Reading relay_0
- keine Änderung im Reading state
--> dadurch natürlich auch keine Änderung des DeviceStateIcon
Irgend etwas funktioniert mit der "Namensauflösung" nicht.
Wenn ich
attr MQTT2_shelly1_12CB79 readingList shellies/shelly1-12CB79/relay/0:.* state\
auf
attr MQTT2_shelly1_12CB79 readingList shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* state\
ändere, dann funktioniert alles richtig.
Ein von der autocreate-Funktion angelegtes Shelly Device hat den Shelly-Namen "shelly1_12CB79:" noch vorne im Pfad stehen. Erst durch das Template wird das gelöscht. Das wird aber offensichtlich benötigt. Ist das noch ein Fehler im Template?
Bei den restlichen Readings habe ich das noch nicht ergänzt, gehört da aber wohl auch hin.
Gruß
Hmmm,
eigentlich sollte die Angabe der CID vorneweg nicht erforderlich sein (shelly1_12CB79:).Könnte nur sein, dass das damit zusammenhängt, dass es zwei "Abonnenten" für diese Info gibt (relay0 und state) und du quasi durch die Angabe der CID state "erzwingst" (um den Preis, dass ggf. relay0 nicht mehr aktuell ist? Ob es in der jüngeren Vergangenheit Änderungen gab, die sowas verursachen, kann evtl. Rudi besser beantworten).
"Notfalls" sollte "stateFormat relay0" helfen.
Ok, dann werde ich noch ein wenig testen.
Allerdings ist der CID nach autocreate vorangestellt und wird ja erst durch das Template "quasi" entfernt.
Ich hatte das mit dem "mappen" des relay0-values auf state eigentlich nur als Workaround gesehen, aber wenn ich das jetzt richtig verstehe dann ist das DevStateIcon immer fest an "state" gebunden und kann auch nicht umgeleitet werden, oder? Außerdem kann es auch immer nur ein Icon geben. Damit muß man bei mehrkanaligen Geräten zwangsläufig für jeden Kanal ein eigenes Device anlegen, oder? Es sei denn man baut was mit Dummies, Readinggroups, etc. So hab ich das im Moment noch mit meinem Shelly 4Pro gemacht, den ich über das Shelly-Modul steuere. Da das Shelly-Modul aber die energy-Werte (kWh) nicht abfragt werde ich das demnächst rausschmeißen und dann alle Shellies über MQTT2 anbinden. Ist sowieso besser, da dann die Infos direkt vom Device kommen und nicht extra gepollt werden müssen.
Gruß
Vorsicht, du wirfst da ein paar Dinge durcheinander...
Vielleicht immer noch verkürzt: stateFormat mappt nicht irgendwas auf state, sondern beeinflußt STATE. STATE ist in der Regel Grundlage für devStateIcon. Further reading: https://wiki.fhem.de/wiki/DeviceOverview_anpassen
Es gibt aber auch eine Perl-Variante von devStateIcon, mit der lassen sich auch mehrere Icons samt unterschiedlicher "Klick"-Befehle auf die einzelnen Icons generieren. In den mqtt2.templates findet sich da z.B. was beim 4-Ch-Tasmota ;) . Dabei ist man nicht mal auf Readings des "eigentlichen" Devices beschränkt - ich nutze das neuerdings, um meine HM-Thermostate grafisch netter darzustellen (ca. eine Handvoll Ions für die Funkverbindung/Batterie, manual/auto, Valve-Zustand...).
Schau mal bei den Tasmota-templates nach und melde dich, wenn du (nach eigenen Experimenten dazu, bitte) Hilfe benötigst :) .
Das mit "STATE" (großgeschrieben) habe ich schon verstanden. Ich bezog mich mit dem "mappen" auch nicht auf stateFormat sondern auf die Zuweisung des Readings "...relay/0" auf "state" (kleingeschrieben).
Deinen Tip mit den 4-ch Tasmotas werde ich mir mal genau anschauen. Hört sich sehr interessant an. Mal sehen.
Ich muß noch ein wenig weiter testen, aber bis jetzt sieht es so aus das der CID auf jeden Fall in der setList vorangestellt werden muß. Sonst wird "state" beim Bedienen über das Shelly Web-IF nicht umgesetzt. HW-Eingang am Shelly hab ich noch nicht probiert. Ich denke aber das wird das gleiche Ergebnis liefern.
Gruß
Sorry, dass ich das mit dem "mappen" mißverstanden hatte.
Vielleicht kannst du auch testweise mal die beiden Angaben relay0 und state in der readingList tauschen? Würde mich interessieren, ob wirklich nur eines (das letzte?) bedient wird.
Das mit der CID (bzw. dem Entfernen derselben) ist jedenfalls früher kein Problem gewesen. Nutzt man MQTT2_CLIENT als IO, ist die CID sowieso wenigstens unnötig, im schlimmsten Fall hinderlich; m.E. ist es daher kein Fehler, die zu entfernen.
Mit "Tauschen" meinst Du die Reihenfolge, also Zeile in der setList, oder? Hab ich noch nicht probiert, kann ich aber gleich mal versuchen. Was ich allerdings sicher sagen kann ist, daß es ohne vorangestellte CID nicht geht. Allerdings: Wenn ich beide Readings in der setList habe (also relay0 UND state) und beide haben die CID vorangestellt, dann funktioniert es auch nicht. Ich nutze den MQTT2-Server.
Im Moment habe ich es so:
attr MQTT2_shelly1_12CB79 readingList shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* state\
shelly1_12CB79:shellies/shelly1-12CB79/input/0:.* input0\
shelly1_12CB79:shellies/shelly1-12CB79/online:.* online\
shelly1_12CB79:shellies/shelly1-12CB79/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
Damit funktioniert erstmal alles so wie es soll.
Zitat von: Guzzi-Charlie am 12 Februar 2019, 15:00:31
Mit "Tauschen" meinst Du die Reihenfolge, also Zeile in der setList, oder?
Ja, das war gemeint gewesen.
Dass es mit der "doppelten" CID vorangestellt dann auch nicht geht, beruhigt mich irgendwie - du kannst die vorangestellten CID's m.E. daher auch wieder löschen... Auch der Reihenfolge-Test bringt vermutlich nur das Ergebnis, dass eben eines (das letzte?) der Readings bedient wird. Ich würde daher erst mal empfehlen, das "eigentliche" Reading relay0 zu füllen und dann mit stateFormat zu arbeiten. Dann sind wenigstens die Daten in sich konsistent(er), geschrieben wird auf relay/0, empfangen auch...
Also, hier die Ergebnisse der Tests:
attr MQTT2_shelly1_12CB79 readingList shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* relay0\
shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* state\
shelly1_12CB79:shellies/shelly1-12CB79/input/0:.* input0\
shelly1_12CB79:shellies/shelly1-12CB79/online:.* online\
shelly1_12CB79:shellies/shelly1-12CB79/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
funktioniert, aber "relay0" wird nicht gelesen
attr MQTT2_shelly1_12CB79 readingList shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* state\
shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* relay0\
shelly1_12CB79:shellies/shelly1-12CB79/input/0:.* input0\
shelly1_12CB79:shellies/shelly1-12CB79/online:.* online\
shelly1_12CB79:shellies/shelly1-12CB79/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
funktioniert nicht, bzw. nur über FHEM Web-IF (dann wird "relay0" UND "state" gelesen und richtig gesetzt)
attr MQTT2_shelly1_12CB79 readingList shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* state\
shellies/shelly1-12CB79/relay/0:.* relay0\
shelly1_12CB79:shellies/shelly1-12CB79/input/0:.* input0\
shelly1_12CB79:shellies/shelly1-12CB79/online:.* online\
shelly1_12CB79:shellies/shelly1-12CB79/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
funktioniert und beide Werte werden gelesen/gesetzt
attr MQTT2_shelly1_12CB79 readingList shellies/shelly1-12CB79/relay/0:.* relay0\
shelly1_12CB79:shellies/shelly1-12CB79/relay/0:.* state\
shelly1_12CB79:shellies/shelly1-12CB79/input/0:.* input0\
shelly1_12CB79:shellies/shelly1-12CB79/online:.* online\
shelly1_12CB79:shellies/shelly1-12CB79/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
funktioniert und beide Werte werden gelesen/gesetzt
Was Du vorgeschlagen hast "attr stateFormat relay0" hab ich auch gerade nochmal getestet. Das funktioniert zwar, aber dann gibt es eine Inkonsistenz zwischen "relay0" und "state".
attr MQTT2_shelly1_12CB79 readingList shellies/shelly1-12CB79/relay/0:.* relay0\
shellies/shelly1-12CB79/input/0:.* input0\
shellies/shelly1-12CB79/online:.* online\
shellies/shelly1-12CB79/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr MQTT2_shelly1_12CB79 room Kellergeschoß,MQTT2_DEVICE
attr MQTT2_shelly1_12CB79 setList off:noArg shellies/shelly1-12CB79/relay/0/command off\
on:noArg shellies/shelly1-12CB79/relay/0/command on
attr MQTT2_shelly1_12CB79 sortby 04
attr MQTT2_shelly1_12CB79 stateFormat relay0
attr MQTT2_shelly1_12CB79 webCmd on:off
Bei Bedienung über das FHEM Web-IF werden beide Werte richtig gesetzt
Bei Bedienung über das Shelly Web-IF wird nur "relay0" richtig gesetzt, d.h je nachdem wie der "state" vorher stand ist er gleich, oder unterschiedlich zu "relay0". Das gefällt mir auch nicht wirklich.
Hmm, spannend...
Dann habe ich vorläufig keine weitere Idee. Man könnte noch mit userreadings rumexperimentieren, aber das finde ich persönlich eigentlich Mist (wird ständig getriggert und man kann den eigentlichen Zeitstempel nicht mehr erkennen...).
Ansonsten würde es mir persönlich genügen, wenn alles, was von FHEM aus geht und ggf. von lokalen Schaltungen soweit sauber abgebildet ist, mit gewissen (unvermeidbaren) Inkonsitenzen kann ich dann persönlich leben; hier scheint ja nur state nicht zu passen, STATE ist ok, und die Anzeige selbst in allen Fällen auch, oder?
Ja, im Moment scheint es nur um die Inkonsistenz von "state" zu gehen. Mir genügt es im Moment auch erstmal, aber ich werde die Variante benutzen bei der beide Werte konsistent sind und stelle halt bei der "state"-Zuweisung die CID voran. Gefällt mir persönlich besser. Ob das andere Nebenwirkungen hat wird die Zukunft zeigen.
Jetzt werde ich mich mal mit dem Shelly 2 und anschließend mit dem Shelly 4Pro beschäftigen und schauen ob ich das mit den Perl-Befehlen aus dem Tasmota-Template hinbekomme und ob mir das gefällt.
Vielen Dank erstmal für die Unterstützung.
Gruß
Hallo,
ich hab mal versucht auf Basis des Sonoff 4-channel Templates etwas auf den Shelly 4Pro zu übertragen, aber das krieg ich nicht gebacken. Dafür verstehe ich einfach zu wenig von der Perl-Syntax.
Das lasse ich jetzt besser bleiben und verwende doch lieber 4 einzelne devices. Vielleicht erschließt sich das mir ja nach einem Jahr intensiver FHEM-Verwendung. Ich hab noch soviel vor. Da beschäftige ich mich besser erstmal mit der Quantität statt den tiefen Details.
Trotzdem nochmals vielen Dank für die Unterstützung bisher.
Ich versuche zwar immer erstmal durch stundenlange Recherche selbst voran zu kommen, aber ich werde sicherlich trotzdem noch öfters Hilfe benötigen.
Gruß
Nur 'mal laienhaft nachgefragt:
Was steht den in der tasmota console, wenn die jeweiligen Schaltungen durchgeführt werden?
Vielleicht hilft es weiter,
Gernot
Zitat von: Guzzi-Charlie am 12 Februar 2019, 23:39:49
Hallo,
ich hab mal versucht auf Basis des Sonoff 4-channel Templates etwas auf den Shelly 4Pro zu übertragen, aber das krieg ich nicht gebacken. Dafür verstehe ich einfach zu wenig von der Perl-Syntax.
Hi,
eigentlich sollte es kein Hexenwerk sein, und so "tiefes" Perl ist es eigentlich auch nicht. Man kann nach meiner persönlichen Erfahrung an den templates eigentlich ganz gut manches lernen, was state, STATE usw. angeht. Aber es geht ja in dem Fall auch so :) .
@supernova1963:
Ich glaube nicht an ein Problem von der Shelly-MQTT-Seite her, schließlich kommt ja was an. Es werden mit der eingehenden Info aber nicht 2 Readings aktualisiert (wenn man nicht zusätzlich mit der CID rumspielt), sondern leider nur eines - warum auch immer...
@supernova1963:
ich glaube Du hast da was mißverstanden. Es geht nicht um einen Tasmota-geflashten Shelly. Es geht um die Original-FW und MQTT2.
@Beta-User
Du hast bestimmt Recht. Es sind bestimmt nur Kleinigkeiten, aber wenn einem die fehlen dann klappt es eben auch nicht. Aber wie gesagt: Ich habe noch viel vor und möchte mich nicht tagelang an Sachen aufhalten die mehr, oder weniger der Optik dienen. Funktionieren tut es ja auch anders (z.B. mit 4 devices, oder dummies, oder ...).
Falls Du aber irgendwie ein auf den Shelly angepaßtes Stückchen Code hast, dann probier ich es gerne aus.
Danke und Gruß
Zitat von: Guzzi-Charlie am 13 Februar 2019, 15:34:48
Falls Du aber irgendwie ein auf den Shelly angepaßtes Stückchen Code hast, dann probier ich es gerne aus.
Ungetestet, und weil ich nicht weiß, ob der Shelly auch toggle versteht erst mal ohne das :) .
# shelly4pro unified device using original firmware
name:A_14b_shelly4pro_unified
filter:TYPE=MQTT2_DEVICE
desc:shelly4pro using original firmware <br>NOTE: only one device will be created
par:DEVNAME;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
set DEVICE attrTemplate A_10a_shellyplug
attr DEVICE getList \
power0:noArg shellies/DEVNAME/relay/0/power power0\
energy0:noArg shellies/DEVNAME/relay/0/energy energy0\
power1:noArg shellies/DEVNAME/relay/1/power power1\
energy1:noArg shellies/DEVNAME/relay/1/energy energy1\
power2:noArg shellies/DEVNAME/relay/2/power power2\
energy2:noArg shellies/DDEVNAME/relay/2/energy energy2\
power3:noArg shellies/DEVNAME/relay/3/power power3\
energy3:noArg shellies/DEVNAME/relay/3/energy energy3
attr DEVICE readingList \
shellies/DEVNAME/relay/0:.* relay0\
shellies/DEVNAME/input/0:.* input0\
shellies/DEVNAME/relay/1:.* relay1\
shellies/DEVNAME/input/1:.* input1\
shellies/DEVNAME/relay/2:.* relay2\
shellies/DEVNAME/input/2:.* input2\
shellies/DEVNAME/relay/3:.* relay3\
shellies/DEVNAME/input/3:.* input3\
shellies/DEVNAME/online:.* online\
shellies/DEVNAME/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr DEVICE setList \
relay0:on,off shellies/DEVNAME/relay/0/command $EVTPART1\
relay1:on,off shellies/DEVNAME/relay/1/command $EVTPART1\
relay2:on,off shellies/DEVNAME/relay/2/command $EVTPART1\
relay3:on,off shellies/DEVNAME/relay/3/command $EVTPART1
attr DEVICE stateFormat R0: relay0 R1: relay1 R2: relay2 R3: relay3
attr DEVICE model A_14b_shelly4pro_unifiedBitte testen, und wenn es funktioniert dann mal "relay0:on,off,toggle ..." in der setList austesten. Wenn das klappt, ist es recht einfach, den code vom Tasmota vollends "rüberzuholen"...
Ok, Danke. Ich werde es nochmal versuchen.
Ich melde mich dann wieder.
Gruß
Hab's mal eingecheckt, das macht es ggf. einfacher.
Wäre nett, wenn du das mit dem toggle testen könntest. Nach dem Editieren dann einfach ein { AttrTemplate_Initialize() } ausführen.
Ok, Danke.
Ich installiere gerade meine vier neuen Shelly 4Pro. Falls ich dazu komme fange ich Heute Nachmittag noch an, ansonsten Morgen.
Gruß
Hallo,
@Beta-User
ich habe Gestern Abend noch ein wenig getestet. Ich bin auch etwas weiter gekommen, aber ganz so wie gewünscht funktioniert das Ganze noch nicht. Mit Deinem Original-Script läßt sich in der Device-Overview gar nichts bedienen (mit, oder ohne "toggle"). Lediglich eine richtige (Text-) Anzeige ist damit gegeben, d.h. es werden die Zustände (on/off) aller 4 Relais korrekt dargestellt.
Nach etlichen Tests ist mein aktueller Stand nun folgender:
1. stateFormat habe ich erstmal entfernt (ist ja nur Anzeige und hat keinen Einfluß auf die Bedienung)
2. webCmd eingesetztattr MQTT2_shelly4pro_4BBF45 webCmd relay0:relay1:relay2:relay3
Dadurch erscheinen 4 "Pulldown-Boxen" mit denen man alle 4 Kanäle korrekt bedienen kann (funktioniert auch "rückwärts" bei Bedienung über das Shelly Web-IF).
Bei jeder Bedienung wird der Name des Kanals ("relay0, ..1, ..2, ..3") in den state geschrieben
Damit habe ich etwas gespielt und mit devStateIcon verschiedene Icons für die 4 Kanäle vergeben. Ist aber mehr Spielerei, weil es zeigt halt nur an welcher Kanal (relay) als letztes bedient wurde.
attr MQTT2_shelly4pro_4BBF45 devStateIcon relay0:rc_1 relay1:rc_2 relay2:rc_3 relay3:rc_4
Aber vielleicht könnte man es irgendwie nutzten um anzuzeigen das irgendein Kanal eingeschaltet ist.
3. webCmdLabel eingesetztattr MQTT2_shelly4pro_4BBF45 webCmdLabel Kanal 1:\
Kanal 2:\
Kanal 3:\
Kanal 4:
Dadurch konnte ich erreichen, daß die Kanäle untereinander (mehrzeilig) angezeigt werden. Zumindest fast. Der 2. Kanal wird trotzdem in der ersten Reihe hinter Kanal 1 angezeigt.
Warum, habe ich noch nicht herausgefunden.
4. Dann habe ich noch mit cmdIcon experimentiert. Das hat allerdings zu keinem Ergebnis geführt.
Also wenn man die "Pulldown-Boxen" durch "toggle"-bare Icons ersetzen könnte und die dann tatsächlich alle untereinander stehen würden, dann wäre das schon sehr nahe an dem was ich mir vorstelle.
Moin,
dass sich das mit dem stateFormat nicht bedienen läßt, ist/war klar. Die Frage war, ob ein toggle möglich ist (sollte in den pulldown-Menüs angezeigt werden und dann da Aktionen auslösen...). Wenn ja, kann man recht einfach einen devStateIcon-Perl-Code basteln, der dann alle 4 Kanäle anzeigt und bedienbar macht... (das mache ich dann schon ;) ). Sonst ist es komplizierter, das würde ich gerne vermeiden.
Was die Label-Geschichte angeht: Vertausche mal Doppelpunkte und Zeilenumbrüche ;) .
Hallo,
ah, toggle hatte ich in der setList auch schon versucht. Das erscheint bei webCmd-Nutzung auch in der "Dropdown-Box" löst aber bei Betätigung keinerlei Aktionen aus. In der Shelly Doku steht unter MQTT auch nur "on" und "off" als akzeptiertes Kommando.
Das mit dem Doppelpunkt liegt mal wieder an dem zuviel "ungenügendem Wissen". Ich dachte der Doppelpunkt gehört zum Text, hab dann aber gar nicht bemerkt, daß der Doppelpunkt nicht im Text auftaucht. Jetz stehen die Kanäle alle untereinander.
Hm, ok, schade mit dem toggle.
Mal ausgehend davon, dass das Teil in Kleinschreibung Werte zurückgibt folgender Versuch:
attr DEVICE devStateIcon {"<div>\
<a href=\"/fhem?cmd.dummy=set ".$name." relay0 ".ReadingsVal($name, "relay0", "off") =~ /off/ ? "on": "off" . "&XHR=1\">Relay 0:" . FW_makeImage(ReadingsVal($name, "relay0", "off")) . "</a> \
<a href=\"/fhem?cmd.dummy=set ".$name." relay0 ".ReadingsVal($name, "relay1", "off") =~ /off/ ? "on": "off" . "&XHR=1\">Relay 1:" . FW_makeImage(ReadingsVal($name, "relay1", "off")) . "</a> \
<a href=\"/fhem?cmd.dummy=set ".$name." relay0 ".ReadingsVal($name, "relay2", "off") =~ /off/ ? "on": "off" . "&XHR=1\">Relay 2:" . FW_makeImage(ReadingsVal($name, "relay2", "off")) . "</a> \
<a href=\"/fhem?cmd.dummy=set ".$name." relay0 ".ReadingsVal($name, "relay3", "off") =~ /off/ ? "on": "off" . "&XHR=1\">Relay 3:" . FW_makeImage(ReadingsVal($name, "relay3", "off")) . "</a\
></div>" }
Sonst bitte mal in ""off") =~ /off/" jeweils Großschreibung verwenden.
Habs gerade getestet, aber leider ohne jeden Erfolg (Der Shelly liefert die Werte in Kleinschreibung, das ist schon richtig).
Das ist praktisch komplett wirkungslos. Angezeigt wird der Inhalt von state (also relay0...3), je nachdem welcher Kanal zuletzt geschaltet wurde. Genauso wie bei mir vorher.
Da ich die gesamte Befehlskette nicht verstehe wüßte ich auch nicht wo ich einen Fehler suchen sollte. Tut mir Leid.
Was ich gesehen habe und auch mit Änderung versucht hatte:
Im ersten Teil der Befehle (...dummy=set ".$name." relay0 ".Readi...) steht überall "relay0". Ist das richtig? Hab da mal "realy0...3" in den vier Zeilen versucht. ==> Ergebnis identisch.
Und was ist weiter hinten? Da steht: "...>Relay 0:..." Soll das so sein, oder müßte das auch "relay0...3" heißen?
Wie gesagt:
Ich verstehe die Befehlssequenz nicht und weiß nicht was die einzelnen Teile darin bewirken sollen.
Oder muß ich irgendwo noch was auf mein device anpassen.
Ich hatte die Tage noch was zu cmdIcon gefunden, konnte damit aber auch keine Ergebnisse erziehlen. Vielleicht ist es trotzdem nützlich.
https://waschto.eu/aufwerten-von-fhem-devices-durch-icons/
Hmm, vorne hast du natürlich recht, das sollte der passende Set-Befehl sein, also mit dem richtigen Indexwert. Hinten ist es eigentlich (hoffentlich) nur Text, da sollte es "egal" sein (aber natürlich inhaltlich passen).
Steht was im log?
Ansonsten würde ich ein list von dem Gesamtgerät benötigen, dann kann ich uu. am WE mal spielen.
Der waschto-Beitrag ist zwar qualitativ besser als das meiste, was man so in den Weiten des INet findet (siehe https://wiki.fhem.de/wiki/Dokumentationsstruktur), deckt aber unser Problem nicht ab. Wenn du magst und evtl. einen RT-DN hast, kannst du ja mal den Code hier testen (https://forum.fhem.de/index.php/topic,97430.msg906576.html#msg906576) und nachvollziehen; der ist entstanden, nachdem ich den im mqtt2-template enthaltenen Code von dem 4-er Tasmota verstanden habe...)
"RT-DN", wußte ich erst gar nicht was das ist, aber wenn ich das nun richtig verstanden habe, dann ist das ein Raumthermostat von Homematic, oder? Damit kann ich aber leider nicht dienen. Ich setzte keine Hommatic-Komponenten ein.
List vom Gesamtgerät:defmod MQTT2_shelly4pro_4BBF45 MQTT2_DEVICE shelly4pro_4BBF45
attr MQTT2_shelly4pro_4BBF45 IODev MQTT2_FHEM_Server
attr MQTT2_shelly4pro_4BBF45 alias IoT-Licht-WZ1
attr MQTT2_shelly4pro_4BBF45 devStateIcon {"<div>\ <a href=\"/fhem?cmd.dummy=set ".$name." relay0 ".ReadingsVal($name, "relay0", "off") =~ /off/ ? "on": "off" . "&XHR=1\">Relay 0:" . FW_makeImage(ReadingsVal($name, "relay0", "off")) . "</a> \ <a href=\"/fhem?cmd.dummy=set ".$name." relay1 ".ReadingsVal($name, "relay1", "off") =~ /off/ ? "on": "off" . "&XHR=1\">Relay 1:" . FW_makeImage(ReadingsVal($name, "relay1", "off")) . "</a> \ <a href=\"/fhem?cmd.dummy=set ".$name." relay2 ".ReadingsVal($name, "relay2", "off") =~ /off/ ? "on": "off" . "&XHR=1\">Relay 2:" . FW_makeImage(ReadingsVal($name, "relay2", "off")) . "</a> \ <a href=\"/fhem?cmd.dummy=set ".$name." relay3 ".ReadingsVal($name, "relay3", "off") =~ /off/ ? "on": "off" . "&XHR=1\">Relay 3:" . FW_makeImage(ReadingsVal($name, "relay3", "off")) . "</a\ ></div>" }
attr MQTT2_shelly4pro_4BBF45 getList power0:noArg shellies/shelly4pro-4BBF45/relay/0/power power0\
energy0:noArg shellies/shelly4pro-4BBF45/relay/0/energy energy0\
power1:noArg shellies/shelly4pro-4BBF45/relay/1/power power1\
energy1:noArg shellies/shelly4pro-4BBF45/relay/1/energy energy1\
power2:noArg shellies/shelly4pro-4BBF45/relay/2/power power2\
energy2:noArg shellies/Dshelly4pro-4BBF45/relay/2/energy energy2\
power3:noArg shellies/shelly4pro-4BBF45/relay/3/power power3\
energy3:noArg shellies/shelly4pro-4BBF45/relay/3/energy energy3
attr MQTT2_shelly4pro_4BBF45 group EG.Wohnzimmer
attr MQTT2_shelly4pro_4BBF45 icon light_ceiling
attr MQTT2_shelly4pro_4BBF45 model A_14b_shelly4pro_unified
attr MQTT2_shelly4pro_4BBF45 readingList shellies/shelly4pro-4BBF45/relay/0:.* relay0\
shellies/shelly4pro-4BBF45/input/0:.* input0\
shellies/shelly4pro-4BBF45/relay/1:.* relay1\
shellies/shelly4pro-4BBF45/input/1:.* input1\
shellies/shelly4pro-4BBF45/relay/2:.* relay2\
shellies/shelly4pro-4BBF45/input/2:.* input2\
shellies/shelly4pro-4BBF45/relay/3:.* relay3\
shellies/shelly4pro-4BBF45/input/3:.* input3\
shellies/shelly4pro-4BBF45/online:.* online\
shellies/shelly4pro-4BBF45/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/0/power:.* relay_0_power\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/1/power:.* relay_1_power\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/2/power:.* relay_2_power\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/3/power:.* relay_3_power\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/0/energy:.* relay_0_energy\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/1/energy:.* relay_1_energy\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/2/energy:.* relay_2_energy\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/3/energy:.* relay_3_energy
attr MQTT2_shelly4pro_4BBF45 room MQTT2_DEVICE
attr MQTT2_shelly4pro_4BBF45 setList relay0:on,off shellies/shelly4pro-4BBF45/relay/0/command $EVTPART1\
relay1:on,off shellies/shelly4pro-4BBF45/relay/1/command $EVTPART1\
relay2:on,off shellies/shelly4pro-4BBF45/relay/2/command $EVTPART1\
relay3:on,off shellies/shelly4pro-4BBF45/relay/3/command $EVTPART1
attr MQTT2_shelly4pro_4BBF45 webCmd relay0:relay1:relay2:relay3
attr MQTT2_shelly4pro_4BBF45 webCmdLabel Kanal 1\
:Kanal 2\
:Kanal 3\
:Kanal 4\
:
setstate MQTT2_shelly4pro_4BBF45 relay3
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay0 off
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay1 off
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay2 off
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay3 off
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:45:46 relay_0_energy 0
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay_0_power 0.00
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:45:46 relay_1_energy 0
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay_1_power 0.00
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:45:47 relay_2_energy 0
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay_2_power 0.00
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:45:47 relay_3_energy 0
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay_3_power 0.00
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:46:20 state relay3
"Steht was im log?":
Das Log ist riesengroß. Wonach soll ich da suchen? Das Einzige was mir auf die Schnelle aufgefallen ist, ist das alle Naselang ein autocreate stattfindet (aber nicht nur für dieses Gerät).2019.02.15 15:30:12 5: PINGREQ:
2019.02.15 15:30:12 4: MQTT2_FHEM_Server_192.168.178.161_14747 DVES_D5A12E PINGREQ
2019.02.15 15:30:14 5: PINGREQ:
2019.02.15 15:30:14 4: MQTT2_FHEM_Server_192.168.178.167_49175 DVES_D41D1D PINGREQ
2019.02.15 15:30:14 5: PINGREQ:
2019.02.15 15:30:14 4: MQTT2_FHEM_Server_192.168.178.163_11722 DVES_D5AFC8 PINGREQDas sind Sonoff Basic
2019.02.15 15:30:14 3: DS18B20_D2AF77911102: reading temperature did not return a value
2019.02.15 15:30:15 3: DS18S20_516ADE020800: reading temperature did not return a value Momentan nicht angeschlossene 1-Wire Sensoren
2019.02.15 15:30:18 5: PINGREQ:
2019.02.15 15:30:18 4: MQTT2_FHEM_Server_192.168.178.165_23362 DVES_D5A12C PINGREQ
2019.02.15 15:30:18 5: PINGREQ:
2019.02.15 15:30:18 4: MQTT2_FHEM_Server_192.168.178.162_53230 DVES_E4AC01 PINGREQ
2019.02.15 15:30:20 5: PINGREQ:
2019.02.15 15:30:20 4: MQTT2_FHEM_Server_192.168.178.169_49205 DVES_D44E1E PINGREQSonoff Basic
2019.02.15 15:30:20 5: PUBLISH: 0)(0)$shellies/shellyswitch-135A27/relay/0o
2019.02.15 15:30:20 4: MQTT2_FHEM_Server_192.168.178.141_4809 shellyswitch-135A27 PUBLISH shellies/shellyswitch-135A27/relay/0:off
2019.02.15 15:30:20 5: MQTT2_FHEM_Server: dispatch autocreate\000shellyswitch_135A27\000shellies/shellyswitch-135A27/relay/0\000off
2019.02.15 15:30:20 5: PUBLISH: 0)(0)$shellies/shellyswitch-135A27/relay/1o
2019.02.15 15:30:20 4: MQTT2_FHEM_Server_192.168.178.141_4809 shellyswitch-135A27 PUBLISH shellies/shellyswitch-135A27/relay/1:off
2019.02.15 15:30:20 5: MQTT2_FHEM_Server: dispatch autocreate\000shellyswitch_135A27\000shellies/shellyswitch-135A27/relay/1\000off
2019.02.15 15:30:20 5: PUBLISH: 0.(0)(shellies/shellyswitch-135A27/relay/power0.
2019.02.15 15:30:20 4: MQTT2_FHEM_Server_192.168.178.141_4809 shellyswitch-135A27 PUBLISH shellies/shellyswitch-135A27/relay/power:0.00
2019.02.15 15:30:20 5: MQTT2_FHEM_Server: dispatch autocreate\000shellyswitch_135A27\000shellies/shellyswitch-135A27/relay/power\0000.00
2019.02.15 15:30:20 5: PUBLISH: 0'(0)$shellies/shellyswitch-135A27/input/
2019.02.15 15:30:20 4: MQTT2_FHEM_Server_192.168.178.141_4809 shellyswitch-135A27 PUBLISH shellies/shellyswitch-135A27/input/0:0
2019.02.15 15:30:20 5: MQTT2_FHEM_Server: dispatch autocreate\000shellyswitch_135A27\000shellies/shellyswitch-135A27/input/0\0000
2019.02.15 15:30:20 5: PUBLISH: 0'(0)$shellies/shellyswitch-135A27/input/
2019.02.15 15:30:20 4: MQTT2_FHEM_Server_192.168.178.141_4809 shellyswitch-135A27 PUBLISH shellies/shellyswitch-135A27/input/1:0
2019.02.15 15:30:20 5: MQTT2_FHEM_Server: dispatch autocreate\000shellyswitch_135A27\000shellies/shellyswitch-135A27/input/1\0000 Das sit ein Shelly 2
autocreate\000shelly4pro_4BBF45\000shellies/shelly4pro-4BBF45/relay/1/power\0000.00
2019.02.15 12:48:52 5: PUBLISH: 0'(0)"shellies/shelly4pro-4BBF45/relay/1o
2019.02.15 12:48:52 4: MQTT2_FHEM_Server_192.168.178.132_53696 shelly4pro-4BBF45 PUBLISH shellies/shelly4pro-4BBF45/relay/1:off
2019.02.15 12:48:52 5: MQTT2_FHEM_Server: dispatch autocreate\000shelly4pro_4BBF45\000shellies/shelly4pro-4BBF45/relay/1\000off
2019.02.15 12:48:52 5: PUBLISH: 0.(0)(shellies/shelly4pro-4BBF45/relay/2/power0.
2019.02.15 12:48:52 4: MQTT2_FHEM_Server_192.168.178.132_53696 shelly4pro-4BBF45 PUBLISH shellies/shelly4pro-4BBF45/relay/2/power:0.00
2019.02.15 12:48:52 5: MQTT2_FHEM_Server: dispatch Das ist der Shelly 4Pro an dem ich teste
OK, sorry, dachte durch den Link usw. wäre klar, dass es sich um die besagten Raum-Temperatur-Dinger handelt :) .
Aber das Bild da und die Beschreibung sind ja hoffentlich auch für andere Thermostate "im Prinzip" nachvollziehbar, hoffe ich.
Mit "was steht im Log" war gemeint: gibt es irgendwelche Auffälligkeiten, die mit der Zuweisung des Attributes (devStateIcon) zu tun haben. Scheint nicht der Fall zu sein, die Anweisung wird geschluckt, aber mehr auch nicht...
Muß das mal gedanklich durchspielen, wird dauern, wie bereits angekündigt.
Kein Problem, ich habs ja herausgefunden (über den Link). Konnte halt rein vom Text nichts damit anfangen, da ich keine Homematic-Komponenten habe.
Mit dem Log war mir im Prinzip schon klar das es um Auffälligkeiten geht, aber wie Du schon sagtest. Der Befehl wird "geschluckt", d.h. die Syntax ist wohl ok, aber er hat offensichtlich keinerlei funktionalen Auswirkungen.
Etwas weiter sind wir ja trotzdem schon. Ich kann alle 4 Kanäle in einem Gerät bedienen und erhalte die korrekten Rückmeldungen. Jetzt geht es "nur" noch um die Ästhetik.
Hallo,
ich habe gerade noch was ganz anderes ausgegraben.
uzsu (universelle zeitschaltuhr)
und
iconSwitch
Hab mal für die vier Kanäle vier verschiedene settings in der setList eingetragen (als Beispiele).
attr MQTT2_shelly4pro_4BBF45 setList relay0:uzsuSelectRadio,on,off shellies/shelly4pro-4BBF45/relay/0/command $EVTPART1\
relay1:uzsuToggle,on,off shellies/shelly4pro-4BBF45/relay/1/command $EVTPART1\
relay2:iconSwitch,on,li_wht_off,off,li_wht_on shellies/shelly4pro-4BBF45/relay/2/command $EVTPART1\
relay3:on,off shellies/shelly4pro-4BBF45/relay/3/command $EVTPART1
- Kanal 1 mit uzsuSelectRadio (zwei Buttons, der ausgewählte ist gelb umrandet, aber schlecht zu sehen. Vielleicht kann man das auch noch konfigurieren)
- Kanal 2 mit uzsuToggle (ein "Toggle"-Button mit Status "on/off"-Text)
- Kanal 3 mit iconSwitch (ein "Toggle"-Button der mit beliebigen Icons hinterlegt werden kann)
- Kanal 4 ohne alles (Dropdown-Box mit Auswahl)
Kanal 3 mit iconSwitch hat eigentlich schon alles was ich benötige. Alle Varianten funktionieren sowohl bei Bedienung über FHEM als auch bei externer Bedienung über das Shelly Web-IF.
Jetzt muß ich nur noch schauen was ich mit der state-Anzeige mache. Ob ich die noch für irgendetwas brauchen kann, oder ob ich die irgendwie ganz unterdrücke.
Das hier scheint zu funktionieren, ist aber noch nicht vollständig aufgehübscht - geändert sind nur setStateList und devStateIcon:
defmod MQTT2_shelly4pro_4BBF45 MQTT2_DEVICE shelly4pro_4BBF45
attr MQTT2_shelly4pro_4BBF45 IODev MQTT2_FHEM_Server
attr MQTT2_shelly4pro_4BBF45 alias IoT-Licht-WZ1
attr MQTT2_shelly4pro_4BBF45 devStateIcon {my $cmd00 = ReadingsVal($name, "relay0", "off") =~ /off/ ? "on": "off";;my $cmd01 = ReadingsVal($name, "relay1", "off") =~ /off/ ? "on": "off";;my $cmd02 = ReadingsVal($name, "relay2", "off") =~ /off/ ? "on": "off";;my $cmd03 = ReadingsVal($name, "relay3", "off") =~ /off/ ? "on": "off";; return "<div>\ <a href=\"/fhem?cmd.dummy=set ".$name." relay0 ". $cmd00 . "&XHR=1\">Relay 0:" . FW_makeImage(ReadingsVal($name, "relay0", "off")) . "</a> \ <a href=\"/fhem?cmd.dummy=set ".$name." relay1 ". $cmd01 . "&XHR=1\">Relay 1:" . FW_makeImage(ReadingsVal($name, "relay1", "off")) . "</a> \ <a href=\"/fhem?cmd.dummy=set ".$name." relay2 ". $cmd02 . "&XHR=1\">Relay 2:" . FW_makeImage(ReadingsVal($name, "relay2", "off")) . "</a> \ <a href=\"/fhem?cmd.dummy=set ".$name." relay3 ". $cmd03 . "&XHR=1\">Relay 3:" . FW_makeImage(ReadingsVal($name, "relay3", "off")) . "</a\ ></div>" }
attr MQTT2_shelly4pro_4BBF45 getList power0:noArg shellies/shelly4pro-4BBF45/relay/0/power power0\
energy0:noArg shellies/shelly4pro-4BBF45/relay/0/energy energy0\
power1:noArg shellies/shelly4pro-4BBF45/relay/1/power power1\
energy1:noArg shellies/shelly4pro-4BBF45/relay/1/energy energy1\
power2:noArg shellies/shelly4pro-4BBF45/relay/2/power power2\
energy2:noArg shellies/Dshelly4pro-4BBF45/relay/2/energy energy2\
power3:noArg shellies/shelly4pro-4BBF45/relay/3/power power3\
energy3:noArg shellies/shelly4pro-4BBF45/relay/3/energy energy3
attr MQTT2_shelly4pro_4BBF45 icon light_ceiling
attr MQTT2_shelly4pro_4BBF45 model A_14b_shelly4pro_unified
attr MQTT2_shelly4pro_4BBF45 readingList shellies/shelly4pro-4BBF45/relay/0:.* relay0\
shellies/shelly4pro-4BBF45/input/0:.* input0\
shellies/shelly4pro-4BBF45/relay/1:.* relay1\
shellies/shelly4pro-4BBF45/input/1:.* input1\
shellies/shelly4pro-4BBF45/relay/2:.* relay2\
shellies/shelly4pro-4BBF45/input/2:.* input2\
shellies/shelly4pro-4BBF45/relay/3:.* relay3\
shellies/shelly4pro-4BBF45/input/3:.* input3\
shellies/shelly4pro-4BBF45/online:.* online\
shellies/shelly4pro-4BBF45/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/0/power:.* relay_0_power\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/1/power:.* relay_1_power\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/2/power:.* relay_2_power\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/3/power:.* relay_3_power\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/0/energy:.* relay_0_energy\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/1/energy:.* relay_1_energy\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/2/energy:.* relay_2_energy\
shelly4pro_4BBF45:shellies/shelly4pro-4BBF45/relay/3/energy:.* relay_3_energy
attr MQTT2_shelly4pro_4BBF45 room MQTT2_DEVICE
attr MQTT2_shelly4pro_4BBF45 setList relay0:on,off shellies/shelly4pro-4BBF45/relay/0/command $EVTPART1\
relay1:on,off shellies/shelly4pro-4BBF45/relay/1/command $EVTPART1\
relay2:on,off shellies/shelly4pro-4BBF45/relay/2/command $EVTPART1\
relay3:on,off shellies/shelly4pro-4BBF45/relay/3/command $EVTPART1
attr MQTT2_shelly4pro_4BBF45 setStateList none power0
attr MQTT2_shelly4pro_4BBF45 webCmd relay0:relay1:relay2:relay3
attr MQTT2_shelly4pro_4BBF45 webCmdLabel Kanal 1\
:Kanal 2\
:Kanal 3\
:Kanal 4\
:
setstate MQTT2_shelly4pro_4BBF45 relay0
setstate MQTT2_shelly4pro_4BBF45 2019-02-17 15:18:15 relay0 set off
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay1 off
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay2 off
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay3 off
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:45:46 relay_0_energy 0
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay_0_power 0.00
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:45:46 relay_1_energy 0
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay_1_power 0.00
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:45:47 relay_2_energy 0
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay_2_power 0.00
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 12:45:47 relay_3_energy 0
setstate MQTT2_shelly4pro_4BBF45 2019-02-15 16:09:12 relay_3_power 0.00
setstate MQTT2_shelly4pro_4BBF45 2019-02-17 15:16:40 state relay0
Hallo,
ich werd mir das mal anschauen, Danke.
Hast Du Dir das mal angeschaut was ich gepostet hatte? Was hälst Du davon?
Gruß und einen schönen Sonntag Abend
Moin,
sorry, hat etwas gedauert, bis der Groschen gefallen war ;D , war etwas sehr auf das devStateIcon fixiert.
Zitat von: Guzzi-Charlie am 17 Februar 2019, 19:41:56
Was hälst Du davon?
Sehr gut! Hatte das mit den Widgets irgendwie nicht hinreichend auf dem Schirm und war im ersten Moment nicht von der Lampenoptik überzeugt - aber das kann man ja ändern :) . (Werde ich aber nicht, so sieht man besser, was die Stellschraube ist, wenn man andere icons will :) ).
Magst du das soweit (mit "nur" iconSwitch) bereinigen, dass ich das direkt als template übernehmen kann?
Wünschen würde ich mir dabei nur, dass die Darstellung "default" einzeilig ist und die Kanalnummern zur internen Nummerierung passen:
attr MQTT2_shelly4pro_4BBF45 webCmdLabel Kanal 0:Kanal 1:Kanal 2:Kanal 3Bin zwar kein Didaktiker, habe aber den Verdacht, dass eine andere Nummerierung sonst "irgendwann" zu Verwirrung führt, wenn sich der unbedachte user dann doch irgendwann mit den Internas beschäftigt.
Das mit der mehrzeiligen Darstellung könnten wir dann als Beispiel für eine Anpassung in's Wiki zu webCmdLabel oder "Device_Overview" packen?
Gruß, Beta-User
Hallo,
ich werde mich im Laufe des Tages darum kümmern.
Deine letzte Variante mit devStateIcon funktioniert jetzt übrigens auch. Später mehr dazu, hab jetzt gerade nicht soviel Zeit.
Gruß
So, ich hab das Sript (den Teil für Shelly 4PRO unified) von Dir mal angepaßt:# shelly4pro unified device using original firmware
# source: https://forum.fhem.de/index.php/topic,97218.msg905689.html#msg905689
name:A_14b_shelly4pro_unified
filter:TYPE=MQTT2_DEVICE
desc:shelly4pro using original firmware <br>NOTE: UNTESTED! feedback is apreciated, please try also to add toggle commands <br>NOTE: only one device will be created.
par:DEVNAME;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
set DEVICE attrTemplate A_10a_shellyplug
attr DEVICE getList \
power0:noArg shellies/DEVNAME/relay/0/power power0\
energy0:noArg shellies/DEVNAME/relay/0/energy energy0\
power1:noArg shellies/DEVNAME/relay/1/power power1\
energy1:noArg shellies/DEVNAME/relay/1/energy energy1\
power2:noArg shellies/DEVNAME/relay/2/power power2\
energy2:noArg shellies/DDEVNAME/relay/2/energy energy2\
power3:noArg shellies/DEVNAME/relay/3/power power3\
energy3:noArg shellies/DEVNAME/relay/3/energy energy3
attr DEVICE readingList \
shellies/DEVNAME/relay/0:.* relay0\
shellies/DEVNAME/input/0:.* input0\
shellies/DEVNAME/relay/1:.* relay1\
shellies/DEVNAME/input/1:.* input1\
shellies/DEVNAME/relay/2:.* relay2\
shellies/DEVNAME/input/2:.* input2\
shellies/DEVNAME/relay/3:.* relay3\
shellies/DEVNAME/input/3:.* input3\
shellies/DEVNAME/online:.* online\
shellies/DEVNAME/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr DEVICE setList \
relay0:iconSwitch,on,li_wht_off,off,li_wht_on shellies/DEVNAME/relay/0/command $EVTPART1\
relay1:iconSwitch,on,li_wht_off,off,li_wht_on shellies/DEVNAME/relay/1/command $EVTPART1\
relay2:iconSwitch,on,li_wht_off,off,li_wht_on shellies/DEVNAME/relay/2/command $EVTPART1\
relay3:iconSwitch,on,li_wht_off,off,li_wht_on shellies/DEVNAME/relay/3/command $EVTPART1
attr DEVNAME webCmd relay0:relay1:relay2:relay3
attr DEVNAME webCmdLabel R0:R1:R2:R3
attr DEVICE model A_14b_shelly4pro_unified
Ich habe:
- setList auf jetzt nur mit iconSwitch geändert (die Varianten in meinem Post waren ja nur zur Veranschaulichung der Möglichkeiten. Ich benutze auch nur iconSwitch).
- die Kanäle in R0...R3 umbenannt
- webCmdLabel einzeilig ausgeführt
Mein Shelly sieht jetzt so aus:
defmod MQTT2_shelly4pro_801300 MQTT2_DEVICE shelly4pro_801300
attr MQTT2_shelly4pro_801300 IODev MQTT2_FHEM_Server
attr MQTT2_shelly4pro_801300 alias Beleuchtung
attr MQTT2_shelly4pro_801300 devStateIcon relay0:rc_BLANK relay1:rc_BLANK relay2:rc_BLANK relay3:rc_BLANK
attr MQTT2_shelly4pro_801300 getList power0:noArg shellies/shelly4pro-801300/relay/0/power power0\
energy0:noArg shellies/shelly4pro-801300/relay/0/energy energy0\
power1:noArg shellies/shelly4pro-801300/relay/1/power power1\
energy1:noArg shellies/shelly4pro-801300/relay/1/energy energy1\
power2:noArg shellies/shelly4pro-801300/relay/2/power power2\
energy2:noArg shellies/Dshelly4pro-801300/relay/2/energy energy2\
power3:noArg shellies/shelly4pro-801300/relay/3/power power3\
energy3:noArg shellies/shelly4pro-801300/relay/3/energy energy3
attr MQTT2_shelly4pro_801300 group EG.Diele
attr MQTT2_shelly4pro_801300 icon light_ceiling
attr MQTT2_shelly4pro_801300 model A_14b_shelly4pro_unified
attr MQTT2_shelly4pro_801300 readingList shellies/shelly4pro-801300/relay/0:.* relay0\
shellies/shelly4pro-801300/input/0:.* input0\
shellies/shelly4pro-801300/relay/1:.* relay1\
shellies/shelly4pro-801300/input/1:.* input1\
shellies/shelly4pro-801300/relay/2:.* relay2\
shellies/shelly4pro-801300/input/2:.* input2\
shellies/shelly4pro-801300/relay/3:.* relay3\
shellies/shelly4pro-801300/input/3:.* input3\
shellies/shelly4pro-801300/online:.* online\
shellies/shelly4pro-801300/announce:.* { json2nameValue($EVENT, '', $JSONMAP) }\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* relay_0_power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/power:.* relay_1_power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/power:.* relay_2_power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/power:.* relay_3_power\
shelly4pro_801300:shellies/shelly4pro-801300/relay/0/energy:.* relay_0_energy\
shelly4pro_801300:shellies/shelly4pro-801300/relay/1/energy:.* relay_1_energy\
shelly4pro_801300:shellies/shelly4pro-801300/relay/2/energy:.* relay_2_energy\
shelly4pro_801300:shellies/shelly4pro-801300/relay/3/energy:.* relay_3_energy
attr MQTT2_shelly4pro_801300 room Erdgeschoß,MQTT2_DEVICE
attr MQTT2_shelly4pro_801300 setList relay0:iconSwitch,on,li_wht_off,off,li_wht_on shellies/shelly4pro-801300/relay/0/command $EVTPART1\
relay1:iconSwitch,on,li_wht_off,off,li_wht_on shellies/shelly4pro-801300/relay/1/command $EVTPART1\
relay2:iconSwitch,on,li_wht_off,off,li_wht_on shellies/shelly4pro-801300/relay/2/command $EVTPART1\
relay3:iconSwitch,on,li_wht_off,off,li_wht_on shellies/shelly4pro-801300/relay/3/command $EVTPART1
attr MQTT2_shelly4pro_801300 webCmd relay0:relay1:relay2:relay3
attr MQTT2_shelly4pro_801300 webCmdLabel Sternenhimmel\
:Spot Bilder\
:Garderobe\
:Haustür\
:
setstate MQTT2_shelly4pro_801300 relay0
setstate MQTT2_shelly4pro_801300 2019-02-17 16:35:06 fw_ver 20190122-162215/v1.4.5@5cbc6229
setstate MQTT2_shelly4pro_801300 2019-02-17 16:35:06 id shelly4pro-801300
setstate MQTT2_shelly4pro_801300 2019-02-17 16:35:06 ip 192.168.178.131
setstate MQTT2_shelly4pro_801300 2019-02-17 16:35:06 mac C8FD19801300
setstate MQTT2_shelly4pro_801300 2019-02-17 16:35:06 new_fw false
setstate MQTT2_shelly4pro_801300 2019-02-17 16:35:06 online true
setstate MQTT2_shelly4pro_801300 2019-02-18 17:52:55 relay0 off
setstate MQTT2_shelly4pro_801300 2019-02-18 17:52:55 relay1 off
setstate MQTT2_shelly4pro_801300 2019-02-18 17:52:55 relay2 off
setstate MQTT2_shelly4pro_801300 2019-02-18 17:52:55 relay3 off
setstate MQTT2_shelly4pro_801300 2019-02-18 17:32:24 relay_0_energy 0
setstate MQTT2_shelly4pro_801300 2019-02-18 17:52:55 relay_0_power 0.00
setstate MQTT2_shelly4pro_801300 2019-02-16 18:04:01 relay_1_energy 0
setstate MQTT2_shelly4pro_801300 2019-02-18 17:52:55 relay_1_power 0.00
setstate MQTT2_shelly4pro_801300 2019-02-18 12:31:01 relay_2_energy 0
setstate MQTT2_shelly4pro_801300 2019-02-18 17:52:55 relay_2_power 0.00
setstate MQTT2_shelly4pro_801300 2019-02-18 07:56:39 relay_3_energy 0
setstate MQTT2_shelly4pro_801300 2019-02-18 17:52:55 relay_3_power 0.00
setstate MQTT2_shelly4pro_801300 2019-02-18 17:32:49 state relay0
Zwei Dinge verstehe ich noch nicht ganz:
1. Du legst eine getList an mit für die power und Energiewerte,power0:noArg shellies/shelly4pro-801300/relay/0/power power0
energy0:noArg shellies/shelly4pro-801300/relay/0/energy energy0
Für "relay.." und "input.." eine readingList. readingList verstehe ich ja, aber das mit der getList nicht zumal der Shelly/das autocreate offensichtlich sowieso automatisch die "power" und "energy"-Werte selbst sendet/anlegt, dabei allerdings wieder mit der vorangestellten CID und als "relay_0_power/relay_0_energy"shelly4pro_801300:shellies/shelly4pro-801300/relay/0/power:.* relay_0_power
2. Auch das mit dem attrTemplate angelegte reading { json2nameValue($EVENT, '', $JSONMAP) }wird automatisch neu (zusätzlich) geschrieben in { json2nameValue($EVENT) }
Ich glaube ein klein wenig sollten wir das alles noch anpassen. Mir gefällt zwar "power0" besser als "relay_0_power" weil genauso eindeutig aber kürzer. Das müßte dann aber im autocreate (sprich von Rudi angepaßt werden),oder? Ich weiß nicht was er dazu meint und wieviele Leute das schon so verwenden wie es jetzt ist. Ich kann natürlich auch so damit leben, aber dann sollte es in Deinem Template geändert werden.
So, und nun noch eine Frage zu Deiner Variante mit devStateIcon. Wo/wie wird denn da das icon festgelegt? Ist das FS20-Lämpchen das Standard-Icon?
Gruß
So langsam wird das was, Danke auch für die kritische Durchsicht...
Kurz du deinen Fragen:
- manches (wie die JSONMAP) hat sich erst ergeben bzw. weiterentwickelt, ohne dass das in allen templates schon durchgängig berücksichtigt wäre (hier: wieder raus). mea culpa (zur Entschuldigung nochmal: ich habe die meiste Hardware gar nicht und müßte alles "trocken" vorhersehen... Da die templates nur der einmaligen Einrichtung dienen, eilt das nicht, aber ich checke das nochmal durch).
- autocreate wird nur aktiv, wenn es noch nichts passendes gibt. Es wäre daher sinnvoll, die readingList so zu erweitern, dass die angefragen Ergebnisse (aus getList) auch in den passenden Readings landen (power0 und energy0 etc.). Die längeren Reading-Namen sind das Ergebnis der Feststellung, dass einige mehrkanalige MQTT-Geräte eine pure Zahl zwischen den Trennzeichen "/" verwenden und das eine Art "Warnsignal" ist, das kann man aber händisch umbiegen (und sollte das m.E. hier auch, die kurzen Readingnamen sind hinreichend klar und eindeutig).
Wie gesagt, das ist eine Einrichtungshilfe, von daher habe ich keine Schwierigkeiten damit, das schlicht und einfach so zu ändern, dass es für jeden paßt, der das ab "jetzt" nutzt. Für die anderen bleibt ja alles "as is", und wer das template - aus welchem Grund auch immer - nochmal anwendet, wird hoffentlich wissen, dass das Änderungen zur Folge haben kann.
Zu dem devStateIcon (wir brauchen das hier nicht mehr, das ist - so habe ich die Frage auch verstanden - nur zur Info gedacht):
In dem Perl-Code ist es das FW_makeImage(), eine Funktion aus FHEMWEB, das aus einem Text ein Icon generiert (also vereinfacht gesagt bei "off" nach einem Icon "off.svg" sucht und das html-tauglich verpackt = Kauderwelsch, wenn man es in stateFormat packt, was auch geht ::) ). Wenn du mehr zu FW_makeImage wissen willst, kannst du gerne den code in https://forum.fhem.de/index.php/topic,97430.msg906576.html#msg906576 nachzuvollziehen.
Wie jetzt weiter? Machst du das bitte vollends?
Hallo,
Danke erstmal für die Antworten. Ich werde mir das jetzt erstmal alles noch genau anschauen damit ich das auch halbwegs verstehe.
Das mit den devStateIcon war so gedacht (zur Info) ja.
Die HW ist be mir vorhanden, sowohl Shelly 1, Shelly 2, Shelly 4Pro, Sonoff Basic, Wemos D1 mini, etc. Da kann ich im Zweifel schon einiges probieren.
Gerade hab ich auch die neuen Shelly 1PM und Shelly 2.5 bestellt. Das wird aber wohl noch 6 Wochen dauern bis die hier sind.
Ok, ich mach damit weiter. Morgen muß ich mir allerdings mal eine Auszeit nehmen (neues Motorrad abholen).
Melde mich wieder, Gruß
Mußte eh' ein update machen; Änderungen zum shelly4 ist hoffentlich zum großen Teil passend drin, bitte um Rückmeldung.