MQTT2 attrTemplate für Shelly TRV

Begonnen von casoe, 28 September 2022, 22:36:05

Vorheriges Thema - Nächstes Thema

casoe

Dieser Thread soll eine funktionierendes AttrTemplate für einen Shelly TRV Thermostat liefern. Als seperater Thread ist es ein Follow-Up von hier: https://forum.fhem.de/index.php/topic,94060.msg1236956.html#msg1236956

Auf dieser Seite gibt es eine Doku zu den Kommandos: https://shelly-api-docs.shelly.cloud/gen1/#shelly-trv-overview

Diese lauten:
Command topics
Shelly TRV supports a set of commands published on shellies/thermostat/0/command/ to address all TRVs or shellies/shellytrv-<id>/thermostat/0/command/ to address an individual device:
settings will trigger piblishing the content of http /settings endpoint
schedule accepts 1 or 0 to enable/disable schedule
schedule_profile accepts number from 1 to 5 to choose active schedule profile with the provided id
target_t accepts number from 4 to 31 set target temperature.
ext_t accepts number to send external sensor temperature, in deg C
valve_pos accepts number from 0 to 100 to set manually the valve position, in %
boost_minutes accepts number to start boost mode for the given minutes, in minutes
set_boost_minutes accepts number to set the default boost time, in minutes
valve_min_percent accepts number from 0 to 10 to set the valve clse postion percent, in %
accelerated_heating accepts 1 or 0 to enable/disable accelerated heating


Die RAW-Definition des Devices lautet wie folgt:

defmod MQTT2_shellytrv_BC33AC034B28 MQTT2_DEVICE shellytrv_BC33AC034B28
attr MQTT2_shellytrv_BC33AC034B28 DbLogInclude tmp_value,target_t_value
attr MQTT2_shellytrv_BC33AC034B28 autocreate 1
attr MQTT2_shellytrv_BC33AC034B28 readingList shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/status:.* { json2nameValue($EVENT) }\
shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/info:.* { json2nameValue($EVENT) }\
shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/settings:.* { json2nameValue($EVENT) }\
shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/online:.* online\
shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/announce:.* { json2nameValue($EVENT) }
attr MQTT2_shellytrv_BC33AC034B28 room MQTT2_DEVICE

setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:41:55 IODev broker
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 actions_stats_skipped 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 bat 99
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 bat_value 99
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 bat_voltage 4.093
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 build_info_build_id 20220811-152343/v2.1.8@5afc928c
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 build_info_build_timestamp 2022-08-11T15:23:43Z
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 build_info_build_version 2022081115
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 calibrated true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 cfg_changed_cnt 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 charger false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 child_lock false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 clog_prevention true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 cloud_connected false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 cloud_enabled false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 coiot_enabled false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 coiot_peer
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 coiot_update_period 3600
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 dbg_flags 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 device_hostname shellytrv-BC33AC034B28
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 device_mac BC33AC034B28
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 device_num_outputs 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 device_type SHTRV-01
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 discoverable true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 display_brightness 7
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 display_flipped false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 fs_free 59388
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 fs_size 65536
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 fw 20220811-152343/v2.1.8@5afc928c
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 fw_info_device shellytrv-BC33AC034B28
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 fw_info_fw 20220811-152343/v2.1.8@5afc928c
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:00 fw_ver 20220811-152343/v2.1.8@5afc928c
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 has_update false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 hwinfo_batch_id 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 hwinfo_hw_revision dev-prototype
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:00 id shellytrv-BC33AC034B28
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:00 ip 192.168.2.12
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 login_default_username admin
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 login_enabled false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 login_unprotected false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 login_username admin
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 mac BC33AC034B28
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:00 model SHTRV-01
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 mqtt_clean_session true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 mqtt_connected true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 mqtt_enable true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 mqtt_id shellytrv-BC33AC034B28
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 mqtt_max_qos 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 mqtt_retain false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 mqtt_server 192.168.2.5:1883
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 mqtt_update_period 60
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:00 new_fw false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:00 online true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 pin_code
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 ps_mode 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 ram_free 30864
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 ram_total 97280
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 serial 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 sleep_mode_period 60
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 sleep_mode_unit m
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 sntp_enabled true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 sntp_server time.google.com
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 22:30:41 state target_t
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 target_t_enabled true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 target_t_units C
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 target_t_value 20.0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 temperature_offset 0.0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_boost_minutes 0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_calibration_correction true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_ext_t_enabled false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_ext_t_floor_heating false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_extra_pressure false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_force_close false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_open_window_report false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_pos 0.0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_schedule false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_schedule_profile 1
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_schedule_profile_names_1 Livingroom
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_schedule_profile_names_2 Livingroom 1
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_schedule_profile_names_3 Bedroom
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_schedule_profile_names_4 Bedroom 1
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_schedule_profile_names_5 Holiday
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_schedule_rules_1 0600-0123456-23
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_schedule_rules_2 2300-0123456-18
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_t_auto_enabled true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_target_t_accelerated_heating true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_target_t_enabled true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_target_t_units C
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_target_t_value 20.0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_target_t_value_op 8.0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_temperature_offset 0.0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_tmp_is_valid true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_tmp_units C
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_tmp_value 20.7
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 thermostats_1_valve_min_percent 0.00
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 thermostats_1_window_open false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 time 21:45
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 timezone Europe/Berlin
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 tmp_is_valid true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 tmp_units C
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 tmp_value 20.7
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 tz_dst false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 tz_dst_auto true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 tz_utc_offset 7200
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 tzautodetect true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 unixtime 1664394303
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 update_has_update false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 update_new_version 20220811-152343/v2.1.8@5afc928c
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 update_old_version 20220811-152343/v2.1.8@5afc928c
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 update_status unknown
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 uptime 122
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 wifi_ap_enabled false
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 wifi_ap_ssid shellytrv-BC33AC034B28
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 wifi_sta_connected true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 wifi_sta_dns 192.168.2.1
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 wifi_sta_enabled true
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 wifi_sta_gw 192.168.2.1
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 wifi_sta_ip 192.168.2.12
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 wifi_sta_ipv4_method static
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:43:50 wifi_sta_mask 255.255.255.0
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 wifi_sta_rssi -48
setstate MQTT2_shellytrv_BC33AC034B28 2022-09-28 21:45:03 wifi_sta_ssid Olymp


Beta-User

 :) Das nenne ich mal eine vorbildliche Vorbereitung.

Habe im svn was eingecheckt, das über update zu bekommen wäre. Leider habe ich bei dem gleich versucht, das Ganze auf devicetopic-Schreibweise umzustellen, was einige kleinere Wackler mitgebracht hat... (Außerdem ist mir jetzt wieder aufgefallen, dass das eine doofe und unklare Syntax ist, die sich die Fa. für das Ding ausgedacht hat! Vermutlich habe ich deswegen einen großen Bogen um das Ding gemacht...).

Die ersten paar Zeilen sollten so aussehen:
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*,TYPE=MQTT2_DEVICE:FILTER=devicetopic=.*shellies.*
desc:shelly-TRV using original firmware <br>early version
order:A_16d
par:DEV_TPC;"shellies/" and Shelly name in the topic;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m<(shellies/[^/]+)> ? $1 : undef }

Und dann muss noch der \ am Ende der readingList weg.

Wenn das Setzen der desired-temp "rund" klappt, sehen wir weiter.

PS: Falls du z.B. die Angaben zu longitude etc. nicht anonymisiert hattest, kannst du das gerne nachholen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

casoe

#2
Ich komme erst heute Abend zum Testen. Ich gehe das mal strukturiert durch. Um Seiteneffekte zu vermeiden, hab ich das Device in FHEM gelöscht und durch den MQTT-Server neu anlegen lassen. Dann habe ich direkt das Template angewandt. Folgende Punkte sind mir aufgefallen:

1. Stateformat funktioniert nicht

Nach Anwendung des Templates sieht so aus: Measured: temperature Battery: batteryPercent %
Die Werte scheinen nicht richtig verarbeitet zu werden. Ich hatte mir basierend auf anderen Templates schon mal ein devStateIcon zusammengebaut. Das sieht so aus:

{
  my $text = sprintf(" target: %.1f", ReadingsVal($name,"target_t_value","unknown")).sprintf(" aktuell: %.1f", ReadingsVal($name,"tmp_value","unknown"));
  my $onl = ReadingsVal($name,"online","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";
  "<div><a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> $text<b></b>"
}


Kann man mit Sicherheit drüber streiten, was schöner ist. Beim devStateIcon ist mit dem kleinen online-Button direkt ein Absprung auf die Weboberfläche des Shelly möglich. Das finde ich ganz schick.

2. Setzen desired_temp

Klappt sehr gut. Das UI-Element dafür finde ich ein bisschen klein in der Bedienung, aber das setzen der Temperatur wird 1:1 wiedergegeben.

Die anderen Kommandos klappen mehr oder weniger alle noch nicht. Ich verstehe deine Mail so, dass das ggf. auch noch gar nicht das Ziel war. Deswegen höre ich an der Stelle erst mal mit dem Test auf.

Beste Grüße
Carsten   





casoe

PS: Latitude und Longitude hab ich in den Settings auf den Shellys mal rausgeschmissen. ;-)

Danke für den Hinweis.

casoe

Auch spannend: Nach nochmaligem Löschen und Wiederanlegen tauschen ip und online als Readings nicht mehr auf. Hab deswegen devStateIcon wie folgt angepasst:

{
  my $text = sprintf(" target: %.1f", ReadingsVal($name,"target_t_value","unknown")).sprintf(" aktuell: %.1f", ReadingsVal($name,"tmp_value","unknown"));
  my $onl = ReadingsVal($name,"wifi_sta_connected","false") eq "true"?"10px-kreis-gruen":"10px-kreis-rot";
  "<div><a href=\"http://".ReadingsVal($name,"wifi_sta_ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> $text<b></b>"
}

Beta-User

Zitat von: Beta-User am 29 September 2022, 09:51:04
Und dann muss noch der \ am Ende der readingList weg.
Vermutlich ist das untergegangen bzw. es steht jetzt die "attr"-Anweisung für jsonMap am Ende der setList. Bevor das jsonMap nicht klar ist, brauchen wir uns nicht mit stateFormat/devStateIcon zu beschäftigen, denn dann ist der "Kreis" nicht rund.

PS: ich gehe eigentlich immer so vor wie in https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt beschrieben. Hier geht es etwas progressiver voran, weil es schon Referenzgeräte gibt, aber sonst würde man widgets und stateFormat etc. erst am Ende behandeln...

Dass die IP etc. nicht nochmal kommt, hat damit zu tun, dass das ggf. nur einmalig bei einem Reconnect gesendet wird, von solchen Effekten sollte man sich nicht ablenken lassen. Solange man einmal vorhandene Readings nicht aktiv unterdrückt (oder umbenennt), kommen die schon irgendwann wieder ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

casoe

Danke für den Hinweis. Werde ich mir mal reinziehen. Dazu komme ich aber leider erst am Wochenende. Ich melde mich wieder.

Beste Grüße
Carsten   

casoe

Okay, jetzt verstehe ich ein paar Sachen besser.

Das \ vor der jsonMap hab ich entfernt. Das Anwenden der Vorlage funktioniert damit dann auch direkt und das stateFormat sieht jetzt auch korrekt aus.

Das Setzen der desired_tem funktioniert einwandfrei. Auch das Widget reagiert jetzt wie erwartet.

Boost on/off funktioniert nicht.

Was aber klappt, ist boost_minutes. Mit "boost_minutes 0" kann man den boost auch wieder deaktivieren.

mode scheint keinen Effekt zu haben.

profile klappt wieder. Nur für das Deaktivieren gibt es kein Kommando. Müsste das nicht mit schedule 0 oder 1 klappen?

set_boost_minutes klappt ebenfalls nichts. Dabei wird nach jedem erneutem Aufruf immer noch ein set vorangestellt, so dass da dann irgendwann "set set set set 45" steht.

valve scheint ebenfalls zu klappen.

Ich hab ansonsten wie in der Anleitung beschrieben noch mal den MQTT-Verkehr mitgeschnitten. Dabei kam das:

shellytrv_BC33AC034B28
shellies/shellytrv-BC33AC034B28/status
{"tmp": {"value":20.5,"units": "C","is_valid": true},"target_t":{"enabled":true,"value":19.0,"units":"C"},"temperature_offset":0.0,"bat":99}
shellytrv_BC33AC034B28
shellies/shellytrv-BC33AC034B28/info
{"wifi_sta":{"connected":true,"ssid":"Olymp","ip":"192.168.2.12","rssi":-48},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"18:28","unixtime":1664645324,"serial":0,"has_update":false,"mac":"BC33AC034B28","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"thermostats":[{"pos":0.0,"target_t":{"enabled":true,"value":19.0,"value_op":8.0,"units":"C"},"tmp":{"value":20.5,"units":"C","is_valid":true},"schedule":false,"schedule_profile":1,"boost_minutes":0,"window_open":false}],"calibrated":true,"bat":{"value":99,"voltage":4.093},"charger":false,"update":{"status":"unknown","has_update":false,"new_version":"20220811-152343/v2.1.8@5afc928c","old_version":"20220811-152343/v2.1.8@5afc928c","beta_version":null},"ram_total":97280,"ram_free":30544,"fs_size":65536,"fs_free":59368,"uptime":167805,"fw_info":{"device":"shellytrv-BC33AC034B28","fw":"20220811-152343/v2.1.8@5afc928c"},"ps_mode":0,"dbg_flags":0}
shellytrv_BC33AC034B28
shellies/shellytrv-BC33AC034B28/settings
{ "device":{"type":"SHTRV-01","mac":"BC33AC034B28","hostname":"shellytrv-BC33AC034B28","num_outputs":0},"wifi_ap":{"enabled":false,"ssid":"shellytrv-BC33AC034B28"},"wifi_sta":{"enabled":true,"ssid":"Olymp","ipv4_method":"static","ip":"192.168.2.12","gw":"192.168.2.1","mask":"255.255.255.0","dns":"192.168.2.1"},"mqtt":{"enable":true,"server":"192.168.2.5:1883","user":null,"id":"shellytrv-BC33AC034B28","clean_session":true,"max_qos":0,"retain":false,"update_period":60},"sntp":{"server":"time.google.com","enabled":true},"login":{"enabled":false,"unprotected":false,"username":"admin","default_username":"admin"},"pin_code":"","name":"Thermostat Schlafzimmer","fw":"20220811-152343/v2.1.8@5afc928c","discoverable":true,"build_info":{"build_id":"20220811-152343/v2.1.8@5afc928c","build_timestamp":"2022-08-11T15:23:43Z","build_version":"2022081115"},"cloud":{"enabled":false},"coiot":{"enabled":false,"update_period":3600,"peer":""},"timezone":"Europe/Berlin","lat":0.000000,"lng":0.000000,"tzautodetect":false,"tz_utc_offset":3600,"tz_dst":false,"tz_dst_auto":true,"time":"18:28","child_lock":false,"clog_prevention":true,"display":{"brightness":1,"flipped":true},"hwinfo":{"hw_revision":"dev-prototype","batch_id":0},"sleep_mode":{"period":60,"unit":"m"},"thermostats":[{"target_t":{"enabled":true,"value":19.0,"value_op":8.0,"units":"C","accelerated_heating":true},"schedule":false,"schedule_profile":1,"schedule_profile_names":["Livingroom","Livingroom 1","Bedroom","Bedroom 1","Holiday"],"schedule_rules":["0600-0123456-23","2300-0123456-18"],"temperature_offset":0.0,"ext_t":{"enabled":false, "floor_heating": false},"t_auto":{"enabled":true},"boost_minutes":30,"valve_min_percent":0.00,"force_close":false,"calibration_correction":true,"extra_pressure":false,"open_window_report":false}] }


Bin mir nicht ganz sicher, o dir das was hilft.

Was kann ich jetzt sinnvoll weiter machen?

Beste Grüße
Carsten   







Beta-User

#8
Zitat von: casoe am 01 Oktober 2022, 22:21:14
Okay, jetzt verstehe ich ein paar Sachen besser.
:)
Zitat
Das \ vor der jsonMap hab ich entfernt. Das Anwenden der Vorlage funktioniert damit dann auch direkt und das stateFormat sieht jetzt auch korrekt aus.

Das Setzen der desired_tem funktioniert einwandfrei. Auch das Widget reagiert jetzt wie erwartet.
Damit ist schon mal die wichtigste Funktionalität gegeben, habe daher mal diesen Stand im svn eingecheckt.

Boost on/off funktioniert nicht.

Das kann jetzt mehrere Ursachen haben. Ich vermute, dass ich schon die Funktionalität möglicherweise falsch benannt habe. Kann aber (zusätzlich) auch sein, dass der Perl-Code nicht macht, was er soll...
Schritt 1 sollte daher sein, letzteres zu prüfen und mal zu schauen, was der Thermostat zurückmeldet.
Bei "on" sollte eine 1 auf den Topic versendet werden, bei "off" eine 0. Und eigentlich müsste man erwarten, dass der TRV irgendeine Info zurückgibt.

Kannst du das ggf. mal checken? ggf. dann hinter das "my $val=$EVTPART1 eq 'on'" explizit "?1:0" setzen und dann nochmal testen, dann wird es vielleicht klarer.

ZitatWas aber klappt, ist boost_minutes. Mit "boost_minutes 0" kann man den boost auch wieder deaktivieren.
Hmm, komische Methode für boost-Zeit. Müßte man ggf. in "comment" berücksichtigen und ggf. für sonstige Spezialitäten einen Wiki-Abschnitt entwerfen? Das bekommt man mit einem zusätzlichen Wert "off" in dem Widget nicht wirklich gut hin (zumindest habe ich grade noch keine gute Idee dazu).

Zitatmode scheint keinen Effekt zu haben.
Siehe "boost".

Zitatprofile klappt wieder. Nur für das Deaktivieren gibt es kein Kommando. Müsste das nicht mit schedule 0 oder 1 klappen?
...testen ;) .

Zitatset_boost_minutes klappt ebenfalls nichts. Dabei wird nach jedem erneutem Aufruf immer noch ein set vorangestellt, so dass da dann irgendwann "set set set set 45" steht.
Das ist erst mal gut. Das "set set" kommt daher, dass wir in den Rückmeldungen noch nichts gefunden haben, das per jsonMap hierher zu mappen wäre. Wenn es das nicht gibt, müßte/könnte man die überflüssigen sets auch einfach als User löschen können. Evtl. hilft auch ein passendes widget.

Zitatvalve scheint ebenfalls zu klappen.

ZitatIch hab ansonsten wie in der Anleitung beschrieben noch mal den MQTT-Verkehr mitgeschnitten. Dabei kam das:
[...]
Bin mir nicht ganz sicher, o dir das was hilft.
Das gibt schon mal einen Eindruck, was wohin gehört, ich werd's mir bei Gelegenheit nochmal intensiver anschauen, falls dann noch erforderlich.

Das "Problem": es ist eine Momentaufnahme, die als Startpunkt hilfreich ist. Darüber sind wir zu einem guten Teil aber jetzt raus. Jetzt geht es darum, die anderen Kreise zu schließen, und dazu muss man sich dann jeweils das einzelne Element rauspicken und das dann verfolgen.

Noch klarer jetzt?
(EDIT: Formatierung)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

casoe

#9
So, das Testen geht weiter. Ein paar Sachen werden jetzt klarer.

Boost wurde im Template mit accelerated_heating verknüpft. Das ist eine der Einstellungen im Shelly TRV (siehe accelerated_heating.png). Darauf hatte ich bisher noch nicht geachtet. Insofern klappt die Einstellung korrekt. In meinen Tests klappte es aber erst, wenn man wie von dir angeraten das explizite "?1:0" dahinter setzt. Deswegen würde ich in der setList das so kodieren:

accelerated_heating:on,off {my $val=$EVTPART1 eq 'on'?1:0; qq($DEVICETOPIC/thermostat/0/command/accelerated_heating $val)}

Damit klappt es dann 1a.

Da der Boost anders kodiert wird (mit boost_minutes 30 z. Bsp. 30min Boost und mit boost_minutes 0 Boost aus), macht das dann vermutlich auch mehr Sinn.

boost_minutes klappt wie bereits angesprochen korrekt.

external-temp klappt erst, wenn man in den Einstellungen das entsprechend freigeschaltet hat (siehe external-temp.png). Das macht auch Sinn. Die Einstellung kann man anscheinend nicht extern setzen. Zumindest steht es nicht in der API-Referenz.

Das Ein- und Ausschalten des schedule-profile habe ich genau so kodiert wie den boost weiter oben:

schedule:on,off {my $val=$EVTPART1 eq 'on'?1:0; qq($DEVICETOPIC/thermostat/0/command/schedule $val)}

Damit klappt es dann auch wie erwartet. Der Eintrag für mode ging in der Vorlage im aktuellen Stand auf schedule. Das war mir gar nicht aufgefallen. Deswegen funktioniert es auch nicht. Anscheinend kann man auto und manual nicht extern setzen.

Vielleicht kann man das ja in einem Setting realisieren und schedule 0 wäre dann das Deaktivieren des Schedule. So ist es auch in der Web-Oberfläche vom Shelly TRV realisiert (siehe schedule.png). Dafür reichen meine Perl-Kenntnisse aber nicht. Ich fände in der Oberfläche ein Dropdown statt eines Sliders auch intuitiver, aber das ist wahrscheinlich wiederum Geschmackssache.

valve hatte ich ja schon getestet. Das funktioniert aber auch erst, wenn man "Automatic Temperature Control" ausschaltet (siehe automatic-temperature-control.png).

valve_min_percent würde ich rausnehmen. Ich bin mir nicht sicher, ob das ggf. die Kalibrierung versaut. Use-Cases für das Setzen aus FHEM heraus fallen mir nicht ein. Mit desired-temp und den Schedules hat man ja eigentlich die wesentlichen Optionen, oder?

settings (API-Referenz: "will trigger piblishing the content of http /settings endpoint") wäre damit noch offen. Fällt dir was dazu ein?

Alles in allem würde ich die setList jetzt wie folgt kodieren (Reihenfolge angepasst):

desired-temp:slider,4.0,0.5,31.0,1 $DEVICETOPIC/thermostat/0/command/target_t $EVTPART1
external-temp:slider,4.0,0.5,31.0,1 $DEVICETOPIC/thermostat/0/command/ext_t $EVTPART1
schedule:on,off {my $val=$EVTPART1 eq 'on'?1:0; qq($DEVICETOPIC/thermostat/0/command/schedule $val)}
schedule_profile:slider,1,1,5,1 $DEVICETOPIC/thermostat/0/command/schedule_profile $EVTPART1
set_accelerated_heating:on,off {my $val=$EVTPART1 eq 'on'?1:0; qq($DEVICETOPIC/thermostat/0/command/accelerated_heating $val)}
boost_minutes $DEVICETOPIC/thermostat/0/command/boost_minutes $EVTPART1
set_boost_minutes $DEVICETOPIC/thermostat/0/command/set_boost_minutes $EVTPART1
valve:slider,0,1,100,1 $DEVICETOPIC/thermostat/0/command/valve_pos $EVTPART1
set_valve_min_percent:slider,0,1,100,1 $DEVICETOPIC/thermostat/0/command/valve_min_percent $EVTPART1


widgetOverride würde ich rausschmeißen, weil das von der Usability her meiner Meinung nach gruselig ist. Der normale Slider von FHEM ist viel feingranularer bedienbar.

Beste Grüße
Carsten   


casoe

Damit sieht es für mich schon ziemlich rund aus.

Mir ist noch aufgefallen, dass man nach dem Anwenden des attrTemplate "shelly_TRV" das nicht noch mal machen kann. Danach wird es anscheinend rausgefiltert. Ich hab mir dann jeweils so geholfen, dass ich das Device gelöscht und jeweils noch mal neu nach dem automatischen Anlegen durch den MQTT2-Server angefangen habe. Ist bzw. war das so beabsichtigt?

Beste Grüße
Carsten   

Beta-User

Zitat von: casoe am 03 Oktober 2022, 23:35:53
Damit sieht es für mich schon ziemlich rund aus.
Jein, s.u..

Zitat
Mir ist noch aufgefallen, dass man nach dem Anwenden des attrTemplate "shelly_TRV" das nicht noch mal machen kann. Danach wird es anscheinend rausgefiltert.
Hattest du den "Kopf" entsprechend meines Vorschlags hier ausgetauscht?

Zitat von: casoe am 03 Oktober 2022, 23:23:46
Boost wurde im Template mit accelerated_heating verknüpft. Das ist eine der Einstellungen im Shelly TRV (siehe accelerated_heating.png). Darauf hatte ich bisher noch nicht geachtet. Insofern klappt die Einstellung korrekt. In meinen Tests klappte es aber erst, wenn man wie von dir angeraten das explizite "?1:0" dahinter setzt. Deswegen würde ich in der setList das so kodieren:

accelerated_heating:on,off {my $val=$EVTPART1 eq 'on'?1:0; qq($DEVICETOPIC/thermostat/0/command/accelerated_heating $val)}
Damit klappt es dann 1a.
Anmerkungen dazu: Diese Funktionalität ist was spezielles, was ich bisher so noch nie gesehen habe. Das darf also gerne auch einen speziellen sprechenden Namen haben. Soweit so gut. ABER: Was ist mit der Rückmeldung, dass der Mode eingeschaltet ist? Der sollte dann auch "on" bzw. "off" sein, und nicht 0 und 1. Wir werden dazu vermutlich etwas mehr Perl-Code brauchen, ich bräuchte dazu aber erst mal passenden MQTT-Traffic. Falls du das selbst versuchen willst: Mache es als for-Schleife mit einer qw-Liste, diese Art Logik brauchen wir vermutlich bei noch ein paar mehr Datenpunkten.

ZitatDa der Boost anders kodiert wird (mit boost_minutes 30 z. Bsp. 30min Boost und mit boost_minutes 0 Boost aus), macht das dann vermutlich auch mehr Sinn.
Bin gedanklich im ersten Wurf gestolpert, weil dann eigentlich das Setzen einer boost-Zeit über "set_boost_minutes" komplett sinnfrei ist, wenn man den zugehörigen Status nicht toggeln kann... Dieser setter könnte dann raus?

Zitatexternal-temp klappt erst, wenn man in den Einstellungen das entsprechend freigeschaltet hat (siehe external-temp.png). Das macht auch Sinn. Die Einstellung kann man anscheinend nicht extern setzen. Zumindest steht es nicht in der API-Referenz.
Schade, ist halt erklärungsbedürftig, aber das ist ja nicht der einzige Punkt, gilt z.B. für "valve" (und valve-min) ja genauso...

ZitatDas Ein- und Ausschalten des schedule-profile habe ich genau so kodiert wie den boost weiter oben:

schedule:on,off {my $val=$EVTPART1 eq 'on'?1:0; qq($DEVICETOPIC/thermostat/0/command/schedule $val)}
Damit klappt es dann auch wie erwartet. Der Eintrag für mode ging in der Vorlage im aktuellen Stand auf schedule. Das war mir gar nicht aufgefallen. Deswegen funktioniert es auch nicht. Anscheinend kann man auto und manual nicht extern setzen.
Was on/off angeht, gilt wieder dasselbe. Allerdings gibt es bei den "anderen" Thermostaten, die sowas wie Wochenprogramme kennen dann die Unterscheidung zwischen den modes auto und manual. Das war der Grund, warum der setter so heißt, und ich meine immer noch, wir sollten etwas mehr Aufwand darauf verwenden, das "FHEM-Standard-konform" hinzubiegen. (=>MQTT-Traffic dazu?)
Setzt halt voraus, dass es genau das bewirkt (Fahre nach Wochenprofil = auto, fahre nach einzelner (per Handrad oder FHEM) vorgegebener Temperatur =manual).

Zitatvalve hatte ich ja schon getestet. Das funktioniert aber auch erst, wenn man "Automatic Temperature Control" ausschaltet (siehe automatic-temperature-control.png).

valve_min_percent würde ich rausnehmen. Ich bin mir nicht sicher, ob das ggf. die Kalibrierung versaut. Use-Cases für das Setzen aus FHEM heraus fallen mir nicht ein. Mit desired-temp und den Schedules hat man ja eigentlich die wesentlichen Optionen, oder?
Vermutlich. Allerdings ist meine Erfahrung eher die, dass sich die User hier dann wundern, warum bestimmte Dinge nicht umgesetzt sind... Wenn es nachgewiesenermaßen komplett kontraproduktiv ist, nehmen wir es raus.

Zitatsettings (API-Referenz: "will trigger piblishing the content of http /settings endpoint") wäre damit noch offen. Fällt dir was dazu ein?
Na ja, ist halt eine Abfrageoption. Keine Ahnung, ob man die braucht.

ZitatwidgetOverride würde ich rausschmeißen, weil das von der Usability her meiner Meinung nach gruselig ist. Der normale Slider von FHEM ist viel feingranularer bedienbar.
Na ja, ich hänge an diesem Widget, sehe aber auch das Problem... Daher ist es nicht in der setList vercoded und man kann es recht einfach bei Nichtgefallen löschen ;) . Kommt auch immer darauf an, was man alles im Detail View gezeigt haben will, und wie man die Dinger ggf. steuert (bei mir nimmt praktisch nie einer die Maus in die Hand, um da was zu ändern, das passiert alles über Wochenprogrammänderungen oder WeekdayTimer (iVm. weekprofile).)

Es bleibt daher mAn. durchaus noch eingiges zu tun...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

casoe

Zitat von: Beta-User am 04 Oktober 2022, 12:21:02
Hattest du den "Kopf" entsprechend meines Vorschlags hier ausgetauscht?

Hab ich jetzt gemacht und jetzt funzt es. Ich kann das attrTemplate noch mal anwenden.

Zitat von: Beta-User am 04 Oktober 2022, 12:21:02
Anmerkungen dazu: Diese Funktionalität ist was spezielles, was ich bisher so noch nie gesehen habe. Das darf also gerne auch einen speziellen sprechenden Namen haben. Soweit so gut. ABER: Was ist mit der Rückmeldung, dass der Mode eingeschaltet ist? Der sollte dann auch "on" bzw. "off" sein, und nicht 0 und 1. Wir werden dazu vermutlich etwas mehr Perl-Code brauchen, ich bräuchte dazu aber erst mal passenden MQTT-Traffic. Falls du das selbst versuchen willst: Mache es als for-Schleife mit einer qw-Liste, diese Art Logik brauchen wir vermutlich bei noch ein paar mehr Datenpunkten.

Ich hab das jetzt mal über FHEM-Oberfläche geschaltet und den MQTT-Traffic hoffentlich richtig mitgeloggt. Wenn das so nicht richtig ist, wäre eine kurze Anleitung super, wie ich das mitschneiden kann. Ich bin so vorgegangen, dass im MQTT2-Server verbose 5 gesetzt und denn ein eigenes Log für das Testdevice mit defmod FileLog_MQTT FileLog ./log/MQTT-%Y-%m-%d.log MQTT2_shellytrv_BC33AC034B28:.*  erzeugt hab.

Zitat von: Beta-User am 04 Oktober 2022, 12:21:02
Bin gedanklich im ersten Wurf gestolpert, weil dann eigentlich das Setzen einer boost-Zeit über "set_boost_minutes" komplett sinnfrei ist, wenn man den zugehörigen Status nicht toggeln kann... Dieser setter könnte dann raus?

Ich würde ihn erst mal lassen, weil er ja grundsätzlich funktioniert. Aber du bist ja der Maintainer ;-) Also ist das letzte Wort wohl bei dir. Use Cases fallen mir nicht so richtig dafür ein.

Zitat von: Beta-User am 04 Oktober 2022, 12:21:02
Was on/off angeht, gilt wieder dasselbe. Allerdings gibt es bei den "anderen" Thermostaten, die sowas wie Wochenprogramme kennen dann die Unterscheidung zwischen den modes auto und manual. Das war der Grund, warum der setter so heißt, und ich meine immer noch, wir sollten etwas mehr Aufwand darauf verwenden, das "FHEM-Standard-konform" hinzubiegen. (=>MQTT-Traffic dazu?)
Setzt halt voraus, dass es genau das bewirkt (Fahre nach Wochenprofil = auto, fahre nach einzelner (per Handrad oder FHEM) vorgegebener Temperatur =manual).

Siehe oben. Hab die Schedules auch noch mal durchgeschaltet. Klappt 1a. Kann man hoffentlich in dem Logfile sehen.

Ich stelle einstweilen verbose 5 wieder aus, weil da sonst echt viele Daten zusammenkommen.

Beste Grüße
Carsten

Beta-User

Zitat von: casoe am 06 Oktober 2022, 22:15:28
Hab ich jetzt gemacht und jetzt funzt es. Ich kann das attrTemplate noch mal anwenden.
:)

Zitat
Ich hab das jetzt mal über FHEM-Oberfläche geschaltet und den MQTT-Traffic hoffentlich richtig mitgeloggt. Wenn das so nicht richtig ist, wäre eine kurze Anleitung super,
Das verbose-5-log ist leider nur bedingt  aufschlussreich, weil das schon "verarbeitet" ist. Man kann zwar in etwa erahnen, was wie zusammengehört, aber das sieht mühsam aus....

Bitte schau dir im MQTT2_SERVER mal die Option "Show MQTT traffic" an, das sollte die Teile besser zusammengehörig darstellen können: (je) eine Anweisung "raus", und die zugehörige Antwort für alle die Teile, bei denen wir grade noch (etwas) rumrätseln, wie was zusammenpaßt.

ZitatIch würde ihn erst mal lassen, weil er ja grundsätzlich funktioniert. Aber du bist ja der Maintainer ;-) Also ist das letzte Wort wohl bei dir. Use Cases fallen mir nicht so richtig dafür ein.
Na ja, setter, die vorhanden sind, generieren Rückfragen von den usern, die diese Diskussion ggf. nicht wiederfinden oder intensiv lesen... Also lieber "sinnloses" Zeug eher erst mal weglassen...

Aber generell: Ich habe zwar "etwas Übung" darin, Rückfragen zur Funktionalität von allem möglichen zu stellen, aber letztlich ist das eher eine Art coaching der User, die was beitragen wollen und dann die Geräte effektiv haben/nutzen. Von daher bestimmt eher ihr, wie was am Ende sinnvoll ist...

ZitatSiehe oben. Hab die Schedules auch noch mal durchgeschaltet. Klappt 1a. Kann man hoffentlich in dem Logfile sehen.
Ja, kann man sehen. jsonMap müßte man wohl um "thermostats_1_schedule_profile:schedule_profile" erweitern. Kannst du das bitte mal testen?

ZitatIch stelle einstweilen verbose 5 wieder aus, weil da sonst echt viele Daten zusammenkommen.
...ein weiteres Argument für den "direkten" MQTT-Weg.

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

casoe

Okidoki. Ich gebe Feedback in der Reigenfolge, in der ich weiter gemacht bzw. getestet habe.

Zitat von: Beta-User am 07 Oktober 2022, 21:10:08
Ja, kann man sehen. jsonMap müßte man wohl um "thermostats_1_schedule_profile:schedule_profile" erweitern. Kannst du das bitte mal testen?

Hab ich ergänzt. Mal sehen, wie sich das auf den MQTT-Traffic auswirkt.

Zitat von: Beta-User am 07 Oktober 2022, 21:10:08
:)
Das verbose-5-log ist leider nur bedingt  aufschlussreich, weil das schon "verarbeitet" ist. Man kann zwar in etwa erahnen, was wie zusammengehört, aber das sieht mühsam aus....

Bitte schau dir im MQTT2_SERVER mal die Option "Show MQTT traffic" an, das sollte die Teile besser zusammengehörig darstellen können: (je) eine Anweisung "raus", und die zugehörige Antwort für alle die Teile, bei denen wir grade noch (etwas) rumrätseln, wie was zusammenpaßt.

Folgendes Testskript hab ich gemacht (jeweils aus der FHEM Oberfläche heraus mit Show MQ Traffic).

1. Temperatur auf 21.5 Grad
2. Temperatur wieder auf 20.0 Grad
3. "set_accelerated_heating off" gem. meiner aktuellen setList (siehe unten)
4. "set_accelerated_heating on"
5. "schedule on" gem. meiner aktuellen setList (siehe unten)
6. "schedule off"
7. "schedule_profile 5"
8. "schedule on"
9. "schedule_profile 3"
10. "schedule off"

Ich hab jeweils geschaut, dass sich nach dem Kommando in FHEM auch etwas in der Web-Oberfläche von dem Test-Shelly-TRV getan hat.

Ich hab erst nach dem ersten Testdurchlauf gesehen, dass ich in der Oberfläche mit dem MQTT-Traffic auch einen Filter auf ein Device-Topic setzen kann. Also noch mal gemacht, weil das manuelle Editieren der Datei und rausfiltern aller nicht mit dem Test zusammenhängenden MQTT-Devices echt aufwändig ist.

Anbei der Traffic per Copy-Paste aus der Oberfläche. Hätte ein vollwertiger Mosquitto-Server diesbezüglich eigentlich Vorteile, dass man direkt den Traffic in eine Datei schreiben lassen kann?

Der Vollständigkeit halber noch mal meine aktuelle Raw-Definition ohne setstates:

defmod MQTT2_shellytrv_BC33AC034B28 MQTT2_DEVICE shellytrv_BC33AC034B28
attr MQTT2_shellytrv_BC33AC034B28 DbLogInclude thermostats_1_target_t_value,tmp_value
attr MQTT2_shellytrv_BC33AC034B28 alias Thermostat Schlafzimmer
attr MQTT2_shellytrv_BC33AC034B28 devicetopic shellies/shellytrv-BC33AC034B28
attr MQTT2_shellytrv_BC33AC034B28 genericDeviceType thermostat
attr MQTT2_shellytrv_BC33AC034B28 icon temp_control
attr MQTT2_shellytrv_BC33AC034B28 jsonMap bat:0 bat_value:batteryPercent bat_voltage:batteryVoltage target_t_value:desired-temp thermostats_1_tmp_value:temperature thermostats_1_valve_min_percent:valve_min_percent thermostats_1_schedule_profile:schedule_profile
attr MQTT2_shellytrv_BC33AC034B28 model shelly_TRV
attr MQTT2_shellytrv_BC33AC034B28 readingList $DEVICETOPIC/status:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $DEVICETOPIC/info:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $DEVICETOPIC/settings:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $DEVICETOPIC/online:.* online\
  $DEVICETOPIC/announce:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr MQTT2_shellytrv_BC33AC034B28 room Heizung
attr MQTT2_shellytrv_BC33AC034B28 setList desired-temp:slider,4.0,0.5,31.0,1 $DEVICETOPIC/thermostat/0/command/target_t $EVTPART1\
external-temp:slider,4.0,0.5,31.0,1 $DEVICETOPIC/thermostat/0/command/ext_t $EVTPART1\
schedule:on,off {my $val=$EVTPART1 eq 'on'?1:0;; qq($DEVICETOPIC/thermostat/0/command/schedule $val)}\
schedule_profile:slider,1,1,5,1 $DEVICETOPIC/thermostat/0/command/schedule_profile $EVTPART1\
set_accelerated_heating:on,off {my $val=$EVTPART1 eq 'on'?1:0;; qq($DEVICETOPIC/thermostat/0/command/accelerated_heating $val)}\
boost_minutes $DEVICETOPIC/thermostat/0/command/boost_minutes $EVTPART1\
set_boost_minutes $DEVICETOPIC/thermostat/0/command/set_boost_minutes $EVTPART1\
valve:slider,0,1,100,1 $DEVICETOPIC/thermostat/0/command/valve_pos $EVTPART1\
set_valve_min_percent:slider,0,1,100,1 $DEVICETOPIC/thermostat/0/command/valve_min_percent $EVTPART1
attr MQTT2_shellytrv_BC33AC034B28 setStateList on off
attr MQTT2_shellytrv_BC33AC034B28 stateFormat Desired: thermostats_1_target_t_value, Measured: tmp_value, Battery: batteryPercent%
attr MQTT2_shellytrv_BC33AC034B28 webCmd desired-temp


Beste Grüße
Carsten

Beta-User

Hmm, diese firmwares sind echt gruselig, die die immergleichen Infos über mehrere Topics an jeweils einer anderen Stelle verpacken... (zumindest sieht das auf die Schnelle so aus).

Kommt denn immer gleich der "volle Status" (settings?). Dann würde es reichen, immer nur den auszuwerten, da scheint ja alles drin zu sein?

Würde mal vorschlagen, das mode:auto,manual-Ding angzugehen. Also zum einen ein passendes jsonMap zu belegen und zum anderen dann aus "true" vorneweg "auto" zu machen etc..
Muster dafür:
attr DEVICE readingList $\DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP); if defined ($ret->{state}) { $ret->{state}=$ret->{state} eq 'true' ? 'closed' : 'open' }; return $ret }



PS: Man kann sich auch am MQTT2_SERVER z.B. mit einem Kommandozeilen-Tool wie mosquitto_sub lesend aufschalten und damit alles in eine Datei pipen.

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

casoe

Ich befürchte, dass übersteigt meine Fähigkeiten. Ich hab das als neuen Inhalt für readingList ausprobiert, aber es kommen Fehlermeldungen.

Kannst du mir konkreter sagen, was ich machen soll?

Beta-User

Na ja, das war nicht für copy/paste gedacht, sondern zur Anpassung. Hier also nochmal der ausführlichere Weg:

- Wir definieren einen setter "mode" (statt shedule). Die Zeile sollte (editiert im Attribut-Feld) dann so aussehen:
mode:auto,manual {my $val=$EVTPART1 eq 'auto'?1:0; qq($DEVICETOPIC/thermostat/0/command/schedule $val)}
Damit sollte auf dem ESP schedule ein- und ausschaltbar sein.

Zurück kommt aber (vermutlich!) über den Topic settings eine Info zu "thermostats_1_schedule", die "true" oder "false" ist. Das korrigieren wir für FHEM an zwei Stellen:
- zum einen muss jsonMap ergänzt werden, damit aus "thermostats_1_schedule" wieder "mode" wird.
- zum anderen muss in der readingList dann aus "mode"=>"true" wieder "on" werden... Diese Zeile lautet dann in etwa so:
$DEVICETOPIC/settings:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP); if (defined $ret->{mode}) { $ret->{mode}=$ret->{mode} eq 'true' ? 'auto' : 'manual' }; for (qw(accelerated_heating boost)) { next if !defined $ret->{$_}; $ret->{$_}=$ret->{$_} eq 'true' ? 'on' : 'off' }; return $ret }


Wie du siehst, ist hier gleich noch eine Schleife eingebaut, die das "true" nach "on" gleich noch für zwei andere keys machen würde (unterstellt, die sind vorhanden.

Für jeden "Fehler" muss man jetzt also in genau der beschriebenen Reihenfolge vorgehen, damit am Ende was "FHEM-konformes" rauskommt. Kommst du damit weiter?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

casoe

#18
Ich komme erst heute wieder zum Testen.

Das mit dem mode funktioniert nach meinem Dafürhalten schon sehr gut. Ich hab den Setter, die jsonMap und das Reading ergänzt bzw. verändert. Wenn ich "mode" auf auto stelle, wird der Schedule eingeschaltet und mode als Reading richtig auf true gesetzt. Beim Setzen auf manual geht schedule in der Shelly-Weboberfläche auf disabled und das Reading mode geht auf false.

Ich hab dann noch in der jsonMap "thermostats_1_target_t_accelerated_heating:accelerated_heating" ergänzt. Damit wird mit dem setter accelerated_heating dann auch das gleichnamige reading auf on bzw. auf off gesetzt. Das klappt auch wie erwartet.

Damit bleibt noch boost offen. Hier scheint der Shelly TRV ja etwas anders zu funktionieren. Man schaltet den boost mit der Angabe von Minuten ein und kann ihn über 0 Minuten ausschalten. Ansonsten gibt es noch den Setter für den Default-Boost. Wie wollen wir damit umgehen?

casoe

#19
Ich hab über Shelly-Oberfläche folgende Sachen mit dem Boost gemacht:

1. Boost time auf 25min gestellt
2. Boost eingeschaltet
3. Boost ausgeschaltet

Dabei ergab sich der angehängte MQ Traffic.

Beta-User

Habe mal was eingecheckt, kannst ja wieder testen.

Damit sollte boost funktionieren (mit den ansonsten auch häufig als default anzutreffenden 5 Minuten).

Zitat von: casoe am 17 Oktober 2022, 22:21:38
Wenn ich "mode" auf auto stelle, wird der Schedule eingeschaltet und mode als Reading richtig auf true gesetzt. Beim Setzen auf manual geht schedule in der Shelly-Weboberfläche auf disabled und das Reading mode geht auf false.
Auf true oder auto (bzw. false => manual)? Soll wäre auto (nach der Asuwertung der Rückmeldung), sonst empfinde ich das nicht als "richtig". Der Code müßte das eigentlich bereits hergeben...?

Zitat
Ansonsten gibt es noch den Setter für den Default-Boost. Wie wollen wir damit umgehen?
Habe ihn mal drin gelassen, aber an sich kann er raus, wenn er keine Funktion hat... Vielleicht mal bei der Fa. nachhaken, was das eigentlich bewirken soll?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

casoe

Okay, ich das eins der Devices gelöscht und dann darauf gewartet, dass der MQTT-Server es neu anlegt.

Beim Anwenden der Vorlage kommt folgende Fehlermeldung:

MQTT2_shellytrv_BC33AC034B28: bad reading name $MQTT2_shellytrv_BC33AC034B28TOPIC/settings:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP); if (defined $ret->{mode}) { $ret->{mode}=$ret->{mode} eq 'true' ? 'auto' : 'manual' }; if (defined $ret->{set_boost_minutes}) { $ret->{boost}=$ret->{set_boost_minutes}?'on' : 'off' }; for (qw(accelerated_heating boost)) { next if !defined $ret->{$_}; $ret->{$_}=$ret->{$_} eq 'true' ? 'on' : 'off' }; return $ret } (contains not A-Za-z/\d_\.- or is too long)

Nach dem Anwenden der Vorlage ergibt sich folgende RAW-Definition:

defmod MQTT2_shellytrv_BC33AC034B28 MQTT2_DEVICE shellytrv_BC33AC034B28
attr MQTT2_shellytrv_BC33AC034B28 devicetopic shellies/shellytrv-BC33AC034B28
attr MQTT2_shellytrv_BC33AC034B28 genericDeviceType thermostat
attr MQTT2_shellytrv_BC33AC034B28 icon temp_control
attr MQTT2_shellytrv_BC33AC034B28 jsonMap bat:0 bat_value:batteryPercent bat_voltage:batteryVoltage target_t_value:desired-temp thermostats_1_tmp_value:temperature thermostats_1_valve_min_percent:valve_min_percent thermostats_1_target_t_accelerated_heating:accelerated_heating thermostats_1_schedule:mode
attr MQTT2_shellytrv_BC33AC034B28 model shelly_TRV
attr MQTT2_shellytrv_BC33AC034B28 readingList shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/status:.* { json2nameValue($EVENT) }\
shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/info:.* { json2nameValue($EVENT) }\
shellytrv_BC33AC034B28:shellies/shellytrv-BC33AC034B28/settings:.* { json2nameValue($EVENT) }
attr MQTT2_shellytrv_BC33AC034B28 room MQTT2_DEVICE
attr MQTT2_shellytrv_BC33AC034B28 setList accelerated_heating:on,off {my $val=$EVTPART1 eq 'on'?1:0;; qq($DEVICETOPIC/thermostat/0/command/accelerated_heating $val)}\
  mode:auto,manual {my $val=$EVTPART1 eq 'auto'?1:0;; qq($DEVICETOPIC/thermostat/0/command/schedule $val)}\
  schedule_profile:slider,1,1,5,1 $DEVICETOPIC/thermostat/0/command/schedule_profile $EVTPART1\
  desired-temp:slider,4.0,0.5,31.0,1 $DEVICETOPIC/thermostat/0/command/target_t $EVTPART1\
  external-temp:slider,4.0,0.5,31.0,1 $DEVICETOPIC/thermostat/0/command/ext_t $EVTPART1\
  valve:slider,0,1,100,1 $DEVICETOPIC/thermostat/0/command/valve_pos $EVTPART1\
  valve_min_percent:slider,0,1,100,1 $DEVICETOPIC/thermostat/0/command/valve_min_percent $EVTPART1\
  boost:on,off {my $val=$EVTPART1 eq 'on'?5:0;; qq($DEVICETOPIC/thermostat/0/command/boost_minutes $val)}\
  boost_minutes $DEVICETOPIC/thermostat/0/command/boost_minutes $EVTPART1\
  set_boost_minutes $DEVICETOPIC/thermostat/0/command/set_boost_minutes $EVTPART1
attr MQTT2_shellytrv_BC33AC034B28 setStateList on off
attr MQTT2_shellytrv_BC33AC034B28 stateFormat Measured: temperature Battery: batteryPercent %
attr MQTT2_shellytrv_BC33AC034B28 webCmd desired-temp

casoe

#22
Vor diesem Test hab ich meine alte Config wiederhergestellt.

Zitat von: Beta-User am 18 Oktober 2022, 09:41:00
Auf true oder auto (bzw. false => manual)? Soll wäre auto (nach der Asuwertung der Rückmeldung), sonst empfinde ich das nicht als "richtig". Der Code müßte das eigentlich bereits hergeben...?

Hast recht. Das reading mode geht beim Setzen über den setter auf auto oder manual. Wenn ich dann aber einen Moment warte und z. Bsp. die Temperatur über die Shelly-Weboberfläche setze, das das reading ganz kurz auf false, dann wieder auf manual und dann wieder auf false. Wenn ich dann noch mal Temperatur verändere, wechselt er kurz auf true, geht dann wieder auf manual und bleibt da. Irgendwie verwirrend.

Beta-User

Den "bad reading" Fehler dürfte ich eben gefixt haben. Das mit den wechselnden Werten dürfte damit zu tun haben, dass dazu in diesen Fällen was auf einem anderen Topic kommt, da solltest du ja jetzt wissen, wie es zu fixen wäre?
Das ist irgendwie allgemein etwas "speziell", dass dieselben Infos zu einem guten Teil auf verschiedenen Topics kommen, aber jeweils  etwas anders strukturiert.

Fühlt sich jetzt aber von FHEM aus jetzt schon deutlich runder an, die Sache, oder?

(Der Clou wäre, wenn man auch die Wochenprogramme irgendwie manipuliert bekäme, aber das ist ein sehr spezielles Thema).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

casoe

Jetzt sieht es gut aus. Der Fehler taucht nicht mehr aus. Ich hab alle Devices noch mal neu angelegt und alle Setter durchgetestet. Das mit dem Boost funktioniert auch wie erwartet.

Zitat von: Beta-User am 19 Oktober 2022, 21:14:48
Das mit den wechselnden Werten dürfte damit zu tun haben, dass dazu in diesen Fällen was auf einem anderen Topic kommt, da solltest du ja jetzt wissen, wie es zu fixen wäre?

Ehrlich gesagt nicht. Ich bin ein Noob. Aber so lange es funktioniert, ist mir das auch nicht so wichtig.

Zitat von: Beta-User am 19 Oktober 2022, 21:14:48
Fühlt sich jetzt aber von FHEM aus jetzt schon deutlich runder an, die Sache, oder?

Die Integration funktioniert schon seit einer Weile sehr gut. Aus meiner Sicht ist das rund so und auf jeden Fall nicht mehr experimentell. Vielen, vielen Dank für dein Engagement. Das war echt super.

Zitat von: Beta-User am 19 Oktober 2022, 21:14:48
(Der Clou wäre, wenn man auch die Wochenprogramme irgendwie manipuliert bekäme, aber das ist ein sehr spezielles Thema).

Ich möchte die Heizprogramme nicht über die Shellys, sondern zentral über FHEM steuern. Dazu will ich mir weekprofile als Nächstes ansehen. Ist das kompliziert? Meine Hoffnung war, dass damit dann einfach geht. Muss mich aber da noch einlesen und mich damit beschäftigen.



Beta-User

Zitat von: casoe am 23 Oktober 2022, 17:43:35
Jetzt sieht es gut aus. Der Fehler taucht nicht mehr aus. Ich hab alle Devices noch mal neu angelegt und alle Setter durchgetestet. Das mit dem Boost funktioniert auch wie erwartet.
Ok, dann sind wir wieder einen Schritt weiter :) .

Zitat
Ehrlich gesagt nicht. Ich bin ein Noob. Aber so lange es funktioniert, ist mir das auch nicht so wichtig.
Na ja, wenn wirklich zwischendurch noch ein true oder false zu sehen ist, kommt das von der MQTT-Seite, und zwar über einen anderen Topic als den mit unserem "umbenennen"-Code. Ergo müßte man entweder da auch nich etwas (entsprechenden) Code reinbasteln (um "falsche" Events zu verhindern), oder wir könnten überlegen, ob man den betreffenden Topic überhaupt braucht. Irgendwie ist ja sowieso alles doppelt und dreifach. Die Frage ist nur, ob das dann was an Info verwerfen würde, die uns doch interessiert, oder ob das so viel schneller geht wie die Status-Message.
Dazu habe ich aber kein Gefühl...

Zitat
Die Integration funktioniert schon seit einer Weile sehr gut. Aus meiner Sicht ist das rund so und auf jeden Fall nicht mehr experimentell. Vielen, vielen Dank für dein Engagement. Das war echt super.
Gerne! Den Text passe ich bei Gelegenheit noch an.

Zitat
Ich möchte die Heizprogramme nicht über die Shellys, sondern zentral über FHEM steuern. Dazu will ich mir weekprofile als Nächstes ansehen. Ist das kompliziert? Meine Hoffnung war, dass damit dann einfach geht. Muss mich aber da noch einlesen und mich damit beschäftigen.
Na ja, ohne direkte Umsetzung weekprofile => MQTT2_DEVICE (+Code, der passende payloads darauf generiert), braucht man dazwischen dann halt noch einen WeekdayTimer. Ist auch nicht allzu kompliziert, läuft aber halt nicht "autonom" auf dem Shelly. Manche legen da Wert drauf, dass das auch durchläuft, wenn/solange FHEM ggf. mal down wäre...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ReneR1986

Super! Danke euch!
Ich war schon länger auf der Suche nach einem Thermostat, der über WLAN eingebunden werden kann und auch in FHEM integriert werden kann.
Hab jetzt direkt mal einen Shelly TRV bestellt  :D Leider nicht ganz billig die Dinger..

casoe

#27
Joa, aber z. Bsp. die Dinger von Fritz sind gar nicht zu bekommen oder kosten mindestens das Gleiche. Für viele Alternativen bist du auf eine Bridge angewiesen und/oder wirst zwingend an eine Hersteller-Cloud gebunden. Insofern finde ich das Angebot von Shelly fair. Außerdem finde ich den eingebauten Akku gut. Bei sehr vielen anderen Modellen musst du mit Batterien herumtüddeln, was weder aus ökologischen noch aus Kostengründen aus meiner Sicht sinnvoll ist.

ReneR1986

Habe ich aber richtig verstanden, dass es ein Attribut Template für MQTT2_DEVICE ist, richtig?
Wie heißt es denn? Habe gerade ein Update gemacht aber kann es auf Anhieb gerade nicht finden oder ich hab Tomaten auf den Augen... :o

casoe

Das attrTemplate heißt shelly_TRV. Du bindest den Shelly über MQTT ein. Dann sollte das Device automatisch angelegt werden. Anschließend solltest du den Shelly steuern können.

casoe


ReneR1986

OK, nutze aber derzeit einen "externen" Broker.
Ich denke dort, muss ich dann neben dem MQTT2_CLIENT auch das MQTT2_DEVICE manuell anlegen, oder?

Beta-User

Zitat von: ReneR1986 am 26 Oktober 2022, 15:55:41
OK, nutze aber derzeit einen "externen" Broker.
Ich denke dort, muss ich dann neben dem MQTT2_CLIENT auch das MQTT2_DEVICE manuell anlegen, oder?
Das ist eigentlich kein spezielles Thema, das den TRV betrifft. Bitte einen gesonderten Thread aufmachen, falls du nicht alleine klarkommst bzw. die folgende Hinweise nicht helfen:
- Manuell anlegen "müssen" ist zu viel gesagt, man kann auch bei MQTT2_CLIENT autocreate nutzen. Ob das zielführend ist, hängt ab von
-- dem, wie viel Traffic über den externen MQTT-Server geht
-- eventuell gesetzten "subscriptions" am MQTT2_CLIENT (M2C)

- Man sollte dann (mAn.) das "Sortier-attrTemplate" für M2C anwenden, damit nicht alles im selben Device landet.

Paßt das, kann (!) man ggf. mit M2C fast genauso arbeiten wie mit M2-SERVER.

Wenn man manuell vorgehen will, sollte man sich den Quelltext des jeweiligen attrTemplate zu Gemüte führen. In den filter-und par-Anweisungen ist meistens recht gut zu erkennen, welche Attribute ggf. in einer Minimalform gefüllt sein müssen, damit das attrTemplate zu sehen ist und stressfrei durchläuft. Erfordert ggf. auch etwas Übung, ist aber auch nicht soooo schwer, wenn man mal verstanden hat, wie MQTT an sich tickt.

Wie gesagt: eigentlich kein Thema für hier!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ReneR1986

#33
Wie oft melden sich die TRVs per MQTT eigentlich?
Standardmäßig habe ich etwas von 60s gelesen.
Bei mir ist seit ca. 30 Minuten aber nichts passiert.

Edit: Ok, Änderungen werden wohl nur bei Statusänderungen übertragen, macht ja eigentlich auch Sinn..

ReneR1986

Die Integration in FHEM funktioniert wirklich super!
Evtl. sollte man das auch hier:
https://wiki.fhem.de/wiki/Modul_Shelly
bzw. hier:
https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele
mit aufführen.

Ich bin mehr oder weniger durch Zufall auf diesen Thread hier im Forum gestoßen.
Ich denke zusätzlich im Wiki wäre das auch gut aufgehoben  ;)

casoe

Sehr guter Vorschlag. Hab grad einen Account beantragt.

enno

#36
Moin zusammen,

habe gestern auch einen Shelly TRV bekommen. Einbinden über MQTT2 klappt ohne Probleme. Ich kann ihn regeln und bekomme die Temperatur. Was mir jetzt aber fehlt, ist das Reading "valve". Gibts noch irgendwo einen versteckten Schalter oder ist mit dem Update auf "20220811-152343/v2.1.8" wieder irgend etwas "kaputt" gegangen?

Gruss
  Enno

Edit: ok, der Wert kommt in "thermostats_1_pos" ich habe mir ein Userreading gebaut
Einfacher FHEM Anwender auf Intel®NUC

ReneR1986

Habt ihr noch andere valve Zustände außer 0 und 100%?
Das hat jetzt nichts mit der Implementierungen in FHEM zu tun aber ist ein bisschen merkwürdig..
Kalibrierung war eigentlich OK..

enno

T: 20.7 desired: 22.0 Valve: 50

Ist nicht so kleinschrittig wie bei HM aber ich bekomme schon 0, 30, 50 oder 100.
Einfacher FHEM Anwender auf Intel®NUC

Beta-User

Zitat von: enno am 05 November 2022, 16:18:43
Edit: ok, der Wert kommt in "thermostats_1_pos" ich habe mir ein Userreading gebaut
Solche Rückmeldungen brauche ich, um das ggf. zu verbessern. Sollte jetzt direkt via jsonMap passen ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

enno

Sehr schön, habe ich bei mir auch an jsonMap angehängt. Ich habe es allerdings "ValvePosition" genannt, da das so bei den 20 Homematic Teilen so heisst und ich damit in meinen Readingsgroup keine extra Klimmzüge mit Mapping etc. machen muss. Wenn du mir einen Tip gibst wie ich das als INT bekomme, weil Informationen über halbe Umdrehungen brauche ich nicht wirklich . Als Userreading geht es so: ValvePosition:thermostats_1_pos.* {int(ReadingsNum($name,"thermostats_1_pos",0))}
Wie das mit jsonMap geht habe ich leider nicht gefunden.

Wie ReneR1986 auch schon festgestellt hat passen die Wert die vom Shelly kommen gefühlt nicht so recht... das ist aber eine andere Baustelle.
Einfacher FHEM Anwender auf Intel®NUC

Beta-User

Zitat von: enno am 06 November 2022, 19:26:08
Wie das mit jsonMap geht habe ich leider nicht gefunden.
Rechnen get mit jsonMap nicht, das benennt nur um. Aber du könntest das in den Perl-Code mit aufnehmen, ähnlich wie das mit mode/auto/manual (falls es dieser Topic ist, sonst müßte halt beim passenden Topic was ähnliches gemacht werden).

Generell ist es unschön, dass man sich da seitens des Herstellers mal wieder was "spezielles" ausgedacht hat... Ventilstellungen in halben Prozent machen auch für mich keinen großen Sinn. (Hier im Thread war erst mal von 0/100 bzw. 10-er Schritten die Rede....)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

enno

mein Shelly regelt jetzt schon länger im Bad. Bisher ohne Probleme. Was mich stört, ist die Lautstärke des Motors. Im Vergleich zu Homematic und AVM ist das Teil doch deutlich zu hören. Das Regelverhalten unterscheidet sich auch deutlich vom HM. Ich hänge mal ein Plot an. Nicht wundern, bis 5 Uhr ist meine Heizung in der Nachtabsenkung, daher dreht das Ventil auf 100%.

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

flummy1978

Hallo zusammen,

ich wollte das Teilchen auch mal gern testen und bin bisher (bis auf die genannte Lautstärke) sehr zufrieden. Natürlich auch aufgrund der tollen Vorarbeit von Euch *thumbsup* .... Vielen Dank dafür  :)

Nun habe ich aber eine Frage:

Hat jemand von Euch herausbekommen wie man per MQTT dem Shelly mitteilen kann, dass ein Fenster offen ist?

Mit http://ip.ip.ip.ip/window?state=close bzw http://ip.ip.ip.ip/window?state=open kann man per http den Status mitteilen.

Die Alternative über FHEM mitzuteilen, dass das Ventil jetzt zufahren soll hab ich auch in Betracht gezogen, aber vielleicht hats jemand von Euch schon anders realisiert?

Vielen Dank im Voraus
VG
Andreas