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
Kann ich nicht nachvollziehen, weder in der Praxis (ausprobiert) noch im Quelltext.
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?
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
Zitat von: FHEm2005 am 30 Juli 2018, 11:08:20
Das Reading state wird immer aktualisiert, lediglich die anderen Readings haben bei einer Länge von 10 Probleme.
Auch das kann ich nicht vollziehen:
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.