NEWS
Log vom fhem adapter check channel [Device Name] > jsonlist2 [Device Name]
-
Hallo,
bei mir wird der log vom ioBroker vom FEHM Adapter zu gespamt. Leider habe ich jetzt auch nach längerem Suchen nicht herausfinden können, woran das liegt.
Im IoBroker kommt die Meldung check channel [Device Name] > jsonlist2 [Device Name] vom fhem.0 für verschiedene Geräte. Die Betroffenen Geräte sind:
SONOFF BASIC mit Temperatur/Luftfeuchtesonsor mit ESPEasy
2 SONOFF S20 Steckdose mit ESPEASY
Ich habe insgesamt 8 SONOFF S20 im Netz alle mit der selben FW. und alle über FHEM.0 angeschlossen. Von denen kommt keine Meldung. Die Meldung scheint immer dann zu kommen, wenn die ESP Easy FW. an das FHEM den aktuellen status übermittelt. Das machen sie alle 4 Minuten, um den present check zu bestehen. Im FHEM Server sind keine Log Einträge vorhanden. Die Readings etc sind im FHEM für alle Geräte gleich angelegt. Ich habe die Geräte im FHEM und im ioBroker schon gelöscht und neu anlegen lassen. Auf dem Temperatursensor hatte ich einen history adapter geschaltet. Das hatte ich zuerst im Verdacht. Den habe ich aber auf dem Steckdosen nicht. Zuerst war es nur eine Steckdose, die betroffen war. Ich habe jetzt zwei neue Steckdosen eingerichtet und eine von denen betrifft es wieder. Ich habe meines Wissens alles gleich gemacht bei der Einrichtung. Da der Temperatursensor sehr häufig neue states sende, ist mein Log nach kurzer Zeit sehr voll und ich finde gar nichts brauchbares mehr da drin.
Ich habe nicht mal im Ansatz eine Idee, was die Fehlermeldung bedeutet und auch im Netz nichts gefunden.
Wenn irgendwelchen detaillierten Informationen über Versionen oder Konfigurationen benötigt werden, reiche ich sie gerne nach.
-
check channel [Device Name] > jsonlist2 [Device Name] `
Hallo,
die Meldung bedeutet ein Event (mehere) aus FHEM konnte nicht verarbeitet werden.
Deshalb wird das Device neu eingelesen (jsonlist2 [Device]) und ist danach auf jeden Fall richtig.
Mögliche Ursache ist zB wenn ein state aus FHEM einen Doppelpunkt enthält
Kannst du ein jsonlist2 von dem betroffenen Device hier einstellen?
Gruß
LausiD
Doku FHEM Adapter kennst du? https://github.com/ioBroker/ioBroker.fh … /README.md
-
Vielen Dank für die Anwort. Das das jsonlist2 etwas ist, was man sich ausgeben lassen kann war mir nicht klar. Das habe ich dann dem Wiki entnommen, auf das du verwiesen hast. Dennoch scheint die Hauptursache sogar der Doppelpunkt im state zu sein. Der Temperatursensor gibt nähmlich Tem: -2 und HUM: 95 aus. DAs machen die Steckdosen allerdings nicht. Die geben nur on/off als state aus.
Ich habe mir das jsonlist2 für das erste betroffene Gerät ausgeben lassen und für ein nicht betroffenes. Ich konnte keine unerwarteten Unterschiede feststelle. Lediglich ip, name etc waren unterschiedlich. Bei den Readings war ein Eintrag mit REL und einer mit REL:. Ich habe die readings gelöscht aber FHEM hat sie sofort alle genau so neu angelegt. Aber die Log Einträge waren jetzt weg. Leider funktioniert das für die Steckdose zwei und ein Relay, welches am Sonoff Basic Temperatursensor ist nicht.
{ "Arg":"ESPEasy_Temperatur_1_Button", "Results": [ { "Name":"ESPEasy_Temperatur_1_Button", "PossibleSets":"on:noArg off:noArg off:noArg off:noArg buzzer candle:noArg clearreadings:noArg dmx dots erase:noArg event gpio help:buzzer,candle,clearreadings,dmx,dots,erase,event,gpio,help,inputswitchstate,irsend,lcd,lcdcmd,lights,longpulse,longpulse_ms,mcpgpio,mcplongpulse,mcppulse,motorshieldcmd,neopixel,neopixelall,neopixelline,nfx,oled,oledcmd,oledframedcmd,pcapwm,pcfgpio,pcflongpulse,pcfpulse,pulse,pwm,pwmfade,raw,reboot,reset,rtttl,serialsend,servo,status,statusrequest,tone inputswitchstate:noArg irsend lcd lcdcmd lights longpulse longpulse_ms mcpgpio mcplongpulse mcppulse motorshieldcmd neopixel neopixelall:colorpicker,HSVp neopixelline nfx oled oledcmd oledframedcmd pcapwm pcfgpio pcflongpulse pcfpulse pulse pwm pwmfade:colorpicker,HSVp raw reboot:noArg reset:noArg rtttl serialsend servo status statusrequest:noArg tone", "PossibleAttrs":"alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 allowedIPs authentication:1,0 autocreate:1,0 autosave:1,0 colorpicker:RGB,HSV,HSVp deniedIPs disable:1,0 displayTextEncode:1,0 displayTextWidth do_not_notify:0,1 httpReqTimeout IODev Interval adjustValue parseCmdResponse pollGPIOs presenceCheck:1,0 readingPrefixGPIO readingSuffixGPIOState readingSwitchText:1,0 setState:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,100 combineDevices rgbGPIOs maxQueueSize:10,25,50,100,250,500,1000,2500,5000,10000,25000,50000,100000 maxHttpSessions:0,1,2,3,4,5,6,7,8,9 resendFailedCmd:0,1 mapLightCmds colorpickerCTww colorpickerCTcw event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat:textField-long timestamp-on-change-reading oldreadings cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride userattr", "Internals": { "DEF": "192.168.2.70 80 espBridge Temperatur_1_Button", "ESP_BUILD": "20100", "ESP_BUILD_GIT": "mega-20180323", "ESP_BUILD_NOTES": " - Mega", "ESP_NODE_TYPE_ID": "17: ESP Easy Mega", "ESP_SLEEP": "0", "ESP_UNIT": "12", "ESP_VERSION": "2", "HOST": "192.168.2.70", "IDENT": "Temperatur_1_Button", "INTERVAL": "300", "LASTInputDev": "espBridge", "MSGCNT": "52", "NAME": "ESPEasy_Temperatur_1_Button", "NOTIFYDEV": "global", "NR": "33", "NTFY_ORDER": "50-ESPEasy_Temperatur_1_Button", "PORT": "80", "STATE": "off", "SUBTYPE": "device", "TYPE": "ESPEasy", "VERSION": "1.38", "espBridge_MSGCNT": "52", "espBridge_TIME": "2018-12-16 19:23:43" }, "Readings": { "Key": { "Value":"off", "Time":"2018-12-13 00:03:39" }, "Rel:": { "Value":"off", "Time":"2018-12-13 00:03:39" }, "Relay": { "Value":"off", "Time":"2018-12-16 19:23:43" }, "presence": { "Value":"present", "Time":"2018-12-16 19:25:33" }, "state": { "Value":"off", "Time":"2018-12-16 19:25:33" } }, "Attributes": { "IODev": "espBridge", "Interval": "300", "devStateIcon": "on:FS20.on off:FS20.off absent:10px-kreis-rot:statusRequest .*:ios-NACK:check", "eventMap": "/gpio 12 on:on/gpio 12 off:off/gpio 12 gpio:off/gpio 12 output:off/", "group": "ESPEasy Device", "presenceCheck": "1", "readingSwitchText": "1", "setState": "3", "stateFormat": "{ReadingsVal($name,\u0022presence\u0022,\u0022\u0022) eq \u0022absent\u0022 ? \u0022absent\u0022 : ReadingsVal($name,\u0022Relay\u0022,\u0022\u0022)}", "userReadings": "state {ReadingsVal($name,\u0022Relay\u0022,\u0022\u0022) }", "webCmd": ":" } } ], "totalResultsReturned":1 }
Nachdem ich aber das setState vom Temperatursensor auf 0 gesetzt habe und er im state nur noch "opened" ausgibt, gibt es daher schon mal keine Fehler mehr. Die Temperatur lese ich eh aus anderen states aus.
-
Eigentlich sind es ja keine Fehler, sondern nur eine Info das ein Event nicht verarbeitet werden konnte und deshalb mit jsonlist2 neu eingelesen wird
Problem sind die : im state. Bei der Häufigkeit natürlich nervig und muss weg….
Kurz nachgelesen:
setState macht nix anderes als die reading namen im state zu verkürzen. Aus dem Reading "Helligkeit" wird bei setState 3 "HEL" und bei setState 1 "H" im state.(3 ist default)
Ein setState = 0 bedeutet keine Readings im state und somit kein : im state und geht.
Wie kommen die betroffenen state's aus FHEM im ioBroker an?
Temperatur ist state zB "Tem: 15 Hum: 34"
Steckdose ist state?
Edit: Nach update FHEM Adapter über github sollte state mit "Tem:......" kein "adapter check channel....." mehr auslösen
-
Hallo,
mit Update FHEM Adapter heute von github sollten die Meldungen check adapter… bei : im state verschwunden sein.
Rückmeldung ob OK wäre super
Gruß
LausiD