ESPDevice; Probleme mit Readings

[FHEm2005]

Ich weiß nicht ob es ein Fehler ist oder ob es ein gewolltes Verhalten ist. Ich versuche mein Problem mal zu beschreiben:

Mit einem WEMOS und ESPEasy wird eine Entfernungsmessung durchgeführt. Der Name des Messwertes in ESPEasy ist Entfernung. Dieser Name erschein auch als Reading mit dem dazugehörenden Messwert in fhem. Jetzt das Problem: Ob dieses Reading aktualisiert wird, hängt davon ab welchen Wert das attr setState hat. Der Name 'Entfernung' ist 10 Zeichen lang. Solange setState einen Wert hat, der kleiner als die Anzahl der Zeichen des Wortes 'Entfernung' ist, wird der Wert aktualisiert. Ist setState aber >= 10, wird der Messwert nur noch unter state aktualisiert und der Wert unter Entfernung nicht mehr.

Fehler oder Feature?

Gruß Eberhard

[dev0]

Kann ich nicht nachvollziehen, weder in der Praxis (ausprobiert) noch im Quelltext.

Code Auswählen Erweitern


    READINGS:
     2018-07-30 08:04:29   RSSI_RSSI_RSSI_RSSI -82
     2018-07-30 08:04:29   state           RSSI_RSSI_R: -82
Attributes:
   setState   11


Vielleicht das globale Attribut event-on-(change|update)-reading ungeschickt gesetzt?

[FHEm2005]

Hallo dev0,
ich habe weiter getestet. Dieses Phänomen tritt nur im Zusammenhang mit Readingsnamen auf, deren Anzahl von Zeichen exakt 10 ist. Darüber oder darunter ist alles wieder normal.

Damit wir uns nicht missverstehen: Das Reading state wird immer aktualisiert, lediglich die anderen Readings haben bei einer Länge von 10 Probleme.

Ich habe das ganze Gerät gelöscht und es noch einmal neu anlegen lassen: Es funktioniert jetzt. Wieso - keine Ahnung. Tut mir leid hier die Pferde scheu zu machen.
Schönen Tag!

Sch....e! Tritt doch wieder auf.

Gruß Eberhard

[dev0]

Das Reading state wird immer aktualisiert, lediglich die anderen Readings haben bei einer Länge von 10 Probleme.

Auch das kann ich nicht vollziehen:

Code Auswählen Erweitern


Internals:
   DEF        192.168.30.152 80 eb ESP_BL
   ESP_BUILD  147
   ESP_SLEEP  0
   ESP_UNIT   99
   ESP_VERSION 9
   HOST       192.168.30.152
   IDENT      ESP_BL
   INTERVAL   300
   IODev      eb
   LASTInputDev eb
   MSGCNT     187
   NAME       BL
   NOTIFYDEV  global
   NR         63
   NTFY_ORDER 50-BL
   PORT       80
   STATE      RSSIRSSI00: -72
   SUBTYPE    device
   TYPE       ESPEasy
   VERSION    2.00_RC3
   eb_MSGCNT  187
   eb_TIME    2018-07-30 12:19:53
   .attraggr:
   .attrminint:
   OLDREADINGS:
   READINGS:
     2018-07-30 12:19:53   RSSIRSSI00      -72
     2018-07-30 12:19:53   presence        present
     2018-07-30 12:19:53   state           RSSIRSSI00: -72
   helper:
     fpc        1532945993
     mapLightCmds:
       ct         lights
       off        lights
       on         lights
       pct        lights
       rgb        lights
       toggle     lights
     pm:
       Encode     1
       JSON       1
     received:
       RSSIRSSI00 1532945993
Attributes:
   IODev      eb
   Interval   300
   colorpicker RGB
   colorpickerCTcw 6000
   colorpickerCTww 2000
   devStateIcon { ESPEasy_devStateIcon($name) }
   group      ESPEasy Device
   mapLightCmds Lights
   parseCmdResponse lights
   presenceCheck 1
   readingSwitchText 1
   room       ESPEasy
   setState   10
   verbose    3
   webCmd     ct:pct:rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off


Bei der Fehleranalyse könnte ein list von Bridge und betroffenen Device und ein verbose 5 Log (nur Bridge + betroffenes Device) von __EINER__ betreffenden Datenübertragung vom ESP -> FHEM helfen.