[alexa-fhem] Shelly1PM sendet unerwünscht temperature, verfälscht Raumtemperatur

Begonnen von vop, 14 Juli 2021, 01:09:10

Vorheriges Thema - Nächstes Thema

vop

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     :

supernova1963

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_") }

vop

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?

supernova1963

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.


Beta-User

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.
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

passibe

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.