Ich habe das Licht im Badezimmer durch ein hinter dem Lichtschalter eingebauten Shelly 1PM steuerbar gemacht. Das Shelly-Device ist via MQTT2_DEVICE in FHEM eingebunden (die Shelly-Cloud, die ja selbst eine Alexa-Integration hätte, sowie das Shelly-Modul möchte ich nicht nutzen - ich nutze noch diverse andere Devices per MQTT und mag es, wenn es weitgehend einheitlich ist, wo es geht).
Um das Badlicht per Alexa steuern zu können, ist für das Device ein alexaName gesetzt, ein/ausschalten funktioniert problemlos.
Nun zum Problem: das Shelly-Device hat neben Schalter und Verbrauchsmesser auch einen eingebauten Temperatursensor (Schutz vor Überhitzung), der im Reading temperature verfügbar ist. Obwohl für das Device genericDeviceType = light gesetzt ist, wird die Temperatur offenbar trotzdem durch alexa-fhem verarbeitet, was auch im alexa-fhem-log ersichtlich ist:
[7/13/2021, 7:53:06 AM] [FHEM] bz_badlicht has
[7/13/2021, 7:53:06 AM] [FHEM] On [state;on,off]
[7/13/2021, 7:53:06 AM] [FHEM] CurrentTemperature [temperature]
[7/13/2021, 7:53:06 AM] [FHEM] bz_badlicht will not send proactive events
[7/13/2021, 7:53:06 AM] [FHEM] bz_badlicht uses ID: 604d0e89-f33f-6bab-011d-8ccd41854f18c797
2021-07-13 07:53:06 caching: bz_badlicht-state: off
2021-07-13 07:53:06 caching: bz_badlicht-temperature: 40.09
Die interne Shelly-Temperatur ist natürlich immer deutlich höher als die Raumtemperatur.
Im Badezimmer befinden sich zwei weitere Devices, die die Temperatur messen:
- ein über alexa-fhem eingebundener Lacrosse-Temperatur-und-Feuchtigkeits-Sensor
- ein via Homematic IP Access Point in Alexa eingebundes Wand- & Heizkörperthermostat, letzteres wird als ein Temperaturdevice an Alexa übermittelt (bisher nicht in FHEM eingebunden)
In der Alexa-App sind Shelly-Licht, Lacrosse-Sensor und Thermostat in einem Raum "Badezimmer" eingefügt. Frage ich nun Alexa "wie ist die Temperatur im Badezimmer", so kommt als Antwort z.B.:
"Die durchschnittliche Temperatur im Badezimmer beträgt 28,3 Grad"
Bei folgenden drei Temperaturwerten:
- Shelly-Licht: 40.46
- Lacrosse: 21.7
- Homematic: 22.8
Kurz nachgerechnet: (40,46+21,7+22,8) / 3 = 28,32
Alexa berechnet also den Durchschnitt der 3 Devices, von denen eins eine Lampe bzw. deren Shelly-Device ist, dessen Temperatur für die Frage nach der Raumtemperatur völlig irrelevant ist bzw. diese massiv verfälscht.
Nun zu meiner Frage: wie unterdrücke ich die Übertragung des Werts temperature des Shelly-Devices durch alexa-fhem? Gibt es sowas wie "alexaForceGenericDeviceTypeLightOnly" oder "alexaSuppressReading temperature" oder sowas, so dass das Reading temperature ignoriert und nicht an alexa übertragen wird? Ich möchte via Alexa ausschließlich die Lampe ein- und ausschalten und keinen Temperaturwert liefern.
Generell ist es toll, wie so vieles automatisch erkannt wird und bei zahlreichen Standard-Devices wenig Aufwand entsteht, aber die Shelly-Devices (ich habe noch ein paar mehr davon, das Problem besteht mittlerweile in 4 verschiedenen Räumen, die Shelly 2.5 sind am schlimmsten, da sie doppelt zählen und ohnehin Temperaturen um 60 Grad erreichen - da hat es dann im Schlafzimmer auf einmal angeblich 40 Grad statt 20 Grad) bereiten mir Kopfzerbrechen.
Im MQTT-Device möchte ich die Temperatur nicht schon unterdrücken, denn in FHEM möchte ich sie schon verfügbar haben. Ich möchte das Badlicht auch nicht aus dem Alexa-App-Raum "Badezimmer" entfernen, da ich ja komfortabel dem Bad-Echo-Dot sagen können möchte "Alexa, Licht an" und dieses Licht mit eingeschaltet werden soll.
Ich freue mich über Lösungsansätze und hoffe, ich habe mein Problem verständlich beschrieben.
Vollständigkeitshalber noch ein List von bz_badlicht:
Internals:
CID shelly1pm_8CAAB542E78E
DEF shelly1pm_8CAAB542E78E
DEVICETOPIC bz_badlicht
FUUID 604d0e89-f33f-6bab-011d-8ccd41854f18c797
IODev myBroker
LASTInputDev myBroker
MSGCNT 1137
NAME bz_badlicht
NR 863
STATE off
TYPE MQTT2_DEVICE
myBroker_MSGCNT 1137
myBroker_TIME 2021-07-14 00:35:50
READINGS:
2021-07-13 23:25:32 IODev myBroker
2021-03-13 20:17:28 actions_stats_skipped 0
2021-03-13 20:17:25 attrTemplateVersion 20200831
2021-03-13 20:17:28 cfg_changed_cnt 25
2021-03-13 20:17:28 cloud_connected false
2021-03-13 20:17:28 cloud_enabled false
2021-07-13 23:39:19 event S
2021-07-13 23:39:19 event_cnt 80
2021-03-13 20:17:28 fs_free 141564
2021-03-13 20:17:28 fs_size 233681
2021-07-13 23:26:38 fw_ver 20210415-131256/v1.10.3-g23074d0
2021-03-13 20:17:28 has_update false
2021-07-13 23:26:38 id shelly1pm-8CAAB542E78E
2021-07-14 00:35:49 input0 0
2021-03-13 20:17:28 inputs_1_event S
2021-03-13 20:17:28 inputs_1_event_cnt 100
2021-03-13 20:17:28 inputs_1_input 0
2021-07-13 23:26:38 ip 192.168.178.52
2021-07-13 23:39:19 longpush_0 0
2021-07-13 23:26:38 mac 8CAAB542E78E
2021-03-13 20:17:28 meters_1_counters_1 0.000
2021-03-13 20:17:28 meters_1_counters_2 0.000
2021-03-13 20:17:28 meters_1_counters_3 0.000
2021-03-13 20:17:28 meters_1_is_valid true
2021-03-13 20:17:28 meters_1_overpower 0.00
2021-03-13 20:17:28 meters_1_power 0.00
2021-03-13 20:17:28 meters_1_timestamp 1615666646
2021-03-13 20:17:28 meters_1_total 5733
2021-07-13 23:26:38 model SHSW-PM
2021-03-13 20:17:28 mqtt_connected true
2021-07-13 23:26:38 new_fw true
2021-07-13 23:26:37 online true
2021-07-14 00:35:50 overtemperature 0
2021-03-13 20:17:28 ram_free 36972
2021-03-13 20:17:28 ram_total 50296
2021-07-14 00:35:49 relay0 off
2021-07-14 00:35:50 relay_0_energy 10790
2021-07-14 00:35:50 relay_0_energy_total 185132
2021-07-14 00:35:50 relay_0_kWh 0.18
2021-07-14 00:35:49 relay_0_power 0.00
2021-03-13 20:17:28 relays_1_has_timer false
2021-03-13 20:17:28 relays_1_ison false
2021-03-13 20:17:28 relays_1_overpower false
2021-03-13 20:17:28 relays_1_source http
2021-03-13 20:17:28 relays_1_timer_duration 0
2021-03-13 20:17:28 relays_1_timer_remaining 0
2021-03-13 20:17:28 relays_1_timer_started 0
2021-03-13 20:17:28 serial 4863
2021-07-14 00:35:49 state off
2021-07-14 00:35:50 temperature 40.46
2021-07-14 00:35:50 temperature_f 104.83
2021-07-14 00:35:50 temperature_status Normal
2021-03-13 20:17:28 time 20:17
2021-03-13 20:17:28 tmp_is_valid true
2021-03-13 20:17:28 tmp_tC 38.19
2021-03-13 20:17:28 tmp_tF 100.75
2021-03-13 20:17:28 unixtime 1615663046
2021-03-13 20:17:28 update_beta_version 20210312-134711/v1.10.0-rc5-g1c546b5
2021-03-13 20:17:28 update_has_update false
2021-03-13 20:17:28 update_new_version 20210115-103820/v1.9.4@e2732e05
2021-03-13 20:17:28 update_old_version 20210115-103820/v1.9.4@e2732e05
2021-03-13 20:17:28 update_status idle
2021-03-13 20:17:28 uptime 276456
2021-03-13 20:17:28 wifi_sta_connected true
2021-03-13 20:17:28 wifi_sta_ip 192.168.178.52
2021-03-13 20:17:28 wifi_sta_rssi -68
2021-03-13 20:17:28 wifi_sta_ssid rittweg1-2.4GHz
2021-03-13 20:17:25 x_mqttcom set announce
helper:
bm:
MQTT2_DEVICE_Get:
cnt 3
dmx -1000
dtot 0
dtotcnt 0
mTS 14.07. 00:04:11
max 6.31809234619141e-05
tot 0.000182151794433594
mAr:
HASH(0x58ab8f0)
bz_badlicht
?
MQTT2_DEVICE_Set:
cnt 3722
dmx -1000
dtot 0
dtotcnt 0
mTS 14.07. 00:00:00
max 0.0325348377227783
tot 2.6172034740448
mAr:
HASH(0x58ab8f0)
bz_badlicht
off
Attributes:
IODev myBroker
alexaName Badlicht
alexaProactiveEvents 0
alias Badlicht
comment To get appropriate loadState values: Change the default limit "100" in readingList to your needs.
devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen"; my $light = ReadingsVal($name,"state","off"); my $cons = ReadingsVal($name,"relay_0_power","unknown"); my $total = ReadingsVal($name,"relay_0_kWh","unknown"); my $temp = ReadingsVal($name,"temperature","-100"); "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch: $cons / Total: $total/ Temp: $temp °C</div>"}
genericDeviceType light
group Licht
icon light_ceiling
model shelly1_w_energy_measuring
readingList shellies/shelly1pm-8CAAB542E78E/relay/0:.* state
shellies/shelly1pm-8CAAB542E78E/relay/0:.* relay0
shellies/shelly1pm-8CAAB542E78E/input/0:.* input0
shellies/shelly1pm-8CAAB542E78E/online:.* online
shellies/announce:.* { $EVENT =~ m,..id...shelly1pm-8CAAB542E78E...mac.*, ? json2nameValue($EVENT) : return }
shellies/shelly1pm-8CAAB542E78E/announce:.* { json2nameValue($EVENT) }
shellies/shelly1pm-8CAAB542E78E/relay/0/power:.* relay_0_power
shellies/shelly1pm-8CAAB542E78E/relay/0/power:.* { my $compare = $EVTPART0 < 100 ? "off":"on"; ReadingsVal($NAME,"loadState","off") ne $compare ? { 'loadState' => $compare } : return }
shellies/shelly1pm-8CAAB542E78E/temperature:.* temperature
shellies/shelly1pm-8CAAB542E78E/temperature_f:.* temperature_f
shellies/shelly1pm-8CAAB542E78E/input_event/0:.* { json2nameValue($EVENT) }
shellies/shelly1pm-8CAAB542E78E/overtemperature:.* overtemperature
shellies/shelly1pm-8CAAB542E78E/relay/0/energy:.* relay_0_energy
shellies/shelly1pm-8CAAB542E78E/relay/0/energy:.* {'relay_0_kWh' => sprintf("%.2f",$EVENT/60/1000)}
shellies/shelly1pm-8CAAB542E78E/longpush/0:.* longpush_0
shelly1pm_8CAAB542E78E:shellies/shelly1pm-8CAAB542E78E/info:.* { json2nameValue($EVENT) }
shelly1pm_8CAAB542E78E:shellies/shelly1pm-8CAAB542E78E/temperature_status:.* temperature_status
room 00b_Alle_Schalter,03_Bad,Amazon_alexaFHEM,MQTT2_DEVICE,Shelly,ioB_OUT
setList relay0:on,off,toggle shellies/shelly1pm-8CAAB542E78E/relay/0/command $EVTPART1
toggle:noArg shellies/shelly1pm-8CAAB542E78E/relay/0/command toggle
off:noArg shellies/shelly1pm-8CAAB542E78E/relay/0/command off
on:noArg shellies/shelly1pm-8CAAB542E78E/relay/0/command on
x_update:noArg shellies/shelly1pm-8CAAB542E78E/command update_fw
x_mqttcom shellies/shelly1pm-8CAAB542E78E/command $EVTPART1
setStateList on off toggle
userReadings relay_0_energy_total:relay_0_energy:.* monotonic {ReadingsNum("$name","relay_0_energy",0)}
userattr room_map structexclude
webCmd :
Hallo @vop,
vielleicht hilft es den "Automatismus zu unterbrechen" und das reading temperature im Attribut readingList umzubenennen, z.B. in device_temperature
shellies/shelly1pm-8CAAB542E78E/temperature:.* device_temperature und das "alte" reading temperature zu löschen.deletereading bz_badlicht temperature
Ich bin mir aber derzeit nicht ganz sicher, ob temperature nicht doch z.B. über das info topic wieder erzeugt wird. Dann müsste dieses im readingList Attribut ebenfalls angepasst werden.
shelly1pm_8CAAB542E78E:shellies/shelly1pm-8CAAB542E78E/info:.* { json2nameValue($EVENT,"info_") }
Zitat von: supernova1963 am 14 Juli 2021, 05:52:48
Hallo @vop,
vielleicht hilft es den "Automatismus zu unterbrechen" und das reading temperature im Attribut readingList umzubenennen, z.B. in device_temperature
Cool, danke, auf die Idee war ich nicht gekommen!
Hab das gerade bei diesem einen Device umgestellt:
[7/14/2021, 10:58:39 AM] [FHEM] bz_badlicht is light
[7/14/2021, 10:58:39 AM] [FHEM] bz_badlicht has
[7/14/2021, 10:58:39 AM] [FHEM] On [state;on,off]
[7/14/2021, 10:58:39 AM] [FHEM] bz_badlicht will not send proactive events
[7/14/2021, 10:58:39 AM] [FHEM] bz_badlicht uses ID: 604d0e89-f33f-6bab-011d-8ccd41854f18c797
2021-07-14 10:58:39 caching: bz_badlicht-state: off
Noch ein set alexa restart, und schon hat's im Bad nur noch 20 Grad :)
War jetzt natürlich Glück, dass es ein MQTT-Device ist, wo man ein Reading einfach umbenennen kann. Interessant wäre es daher trotzdem, wie es in einem anderen solchen Fall möglich wäre, einen device-Type zu erzwingen bzw. ein konkretes Reading zu unterdrücken. Ich gebe zu, homebridge-mapping bisher nicht verstanden zu haben - aber von der Doku her liest es sich so, als ob man da eher nur in die andere Richtung arbeitet, also fehlende Werte hinzufügt? Aber keine entfernen kann?
Schön, dass das Ergebnis jetzt stimmt.
Generell glaube ich nicht, dass "allzuviele" fhem Module zu solchen Problemen führen.
Es gibt, - meine ich gelesen zu haben -, einen Ansatz zur Festlegung von Readings-Namensgebung für Modulautoren in fhem.
Bei allen anderen allgemeinen "Importmodulen" (MQTTT, httpmod, ...) sollte man "Einfluss" auf die Namensgebung haben.
Vielleicht in dem Zusammenhang noch zwei Aspekte:
a) Man kann den "Hauptkanal" z.B. per readingsProxy im Bad lassen, und den ganzen Rest halt in einen anderen Raum verschieben (und/oder gDT am "Großgerät" löschen);
b) Nach meinem (evtl. sehr unvollständigen) Verständnis kann man auch einen "reset" der von praktisch allen "großen" Sprachsteuerungen "verstandenen" Readings erzwingen, wenn man ein "clear" im homeBridgeMapping vorausschickt und dann nur die Werte dort mappt, die man auch haben will.
Zitat von: vop am 14 Juli 2021, 11:09:21
Interessant wäre es daher trotzdem, wie es in einem anderen solchen Fall möglich wäre, einen device-Type zu erzwingen bzw. ein konkretes Reading zu unterdrücken. Ich gebe zu, homebridge-mapping bisher nicht verstanden zu haben - aber von der Doku her liest es sich so, als ob man da eher nur in die andere Richtung arbeitet, also fehlende Werte hinzufügt? Aber keine entfernen kann?
Siehe Wiki: https://wiki.fhem.de/wiki/Alexa_und_Mappings#homebridgeMapping
Zitat
Das optionale Schlüsselwort clear hat eine besondere Bedeutung: Es löscht Standardmappings
Wenn man also clear ganz an den Anfang des homebridgeMappings setzt, kann man verhindern, dass Alexa das "temperature" Reading ausliest. Dann muss man natürlich im Gegenzug das homebridgeMapping wieder so füllen, dass man das Licht noch schalten kann, da sollte aber eine einfaches On=state reichen, insgesamt also:
clear
On=state
Wenn man – warum auch immer – im state-Reading z.B. nicht "on" oder "off" benutzt, dann kann man das natürlich noch weiter spezifizieren, z.B.:
clear
On=state,valueOn=an,valueOff=aus,cmdOn=an,cmdOff=aus
Ist aber in der Dokumentation von homebridge-fhem nochmal ausführlicher erklärt: https://github.com/justme-1968/homebridge-fhem
Edit: Ist im Prinzip das was Beta-User unter b) schon gesagt hat.