NEWS
Shelly: Keine HTTP-Werte
-
Hallo zusammen,
ich habe eine Reihe von Shellys über Iobroker eingebunden, aber bei einigen von ihnen werden keine Daten per HTTP gezogen, der Eintrag shelly.0.shellyplusplugs#ID#1.name ist bei einigen (null), bei anderen (vermeintlich?) identisch konfigurierten funktioniert es problemlos. Es betrifft Plus 1, Plus 2 PM und Plus Plugs, also alles Gen 2.
Beispiel aus den Shelly-Logs eines Plugs, bei dem es funktioniert:
shelly_notification:162 Status change of switch:0: {"id":0,"aenergy":{"by_minute":[15.253,15.253,15.253],"minute_ts":1733655240,"total":27543.247}} 11:54:00 shos_rpc_inst.c:242 Shelly.GetStatus via HTTP_in GET 192.168.188.22:49934 11:54:14 shos_rpc_inst.c:242 Shelly.GetDeviceInfo via HTTP_in GET 192.168.188.22:49936 11:54:14 shos_rpc_inst.c:242 Sys.GetConfig via HTTP_in GET 192.168.188.22:49938 11:54:14 shos_rpc_inst.c:242 WiFi.GetConfig via HTTP_in GET 192.168.188.22:49940 11:54:14 shos_rpc_inst.c:242 Mqtt.GetConfig via HTTP_in GET 192.168.188.22:49942 11:54:14 shos_rpc_inst.c:242 Cloud.GetConfig via HTTP_in GET 192.168.188.22:49944 11:54:14 shos_rpc_inst.c:242 Switch.GetConfig via HTTP_in GET 192.168.188.22:49946 11:54:14 shos_rpc_inst.c:242 Shelly.GetStatus via HTTP_in GET 192.168.188.22:50020 11:54:29 shos_rpc_inst.c:242 Shelly.GetDeviceInfo via HTTP_in GET 192.168.188.22:50022 11:54:29 shos_rpc_inst.c:242 Sys.GetConfig via HTTP_in GET 192.168.188.22:50024 11:54:29 shos_rpc_inst.c:242 WiFi.GetConfig via HTTP_in GET 192.168.188.22:50026 11:54:29 shos_rpc_inst.c:242 Mqtt.GetConfig via HTTP_in GET 192.168.188.22:50028 11:54:29 shos_rpc_inst.c:242 Cloud.GetConfig via HTTP_in GET 192.168.188.22:50030 11:54:29 shos_rpc_inst.c:242 Switch.GetConfig via HTTP_in GET 192.168.188.22:50032 11:54:29 shos_rpc_inst.c:242 Shelly.GetStatus via HTTP_in GET 192.168.188.22:50106 11:54:45 shos_rpc_inst.c:242 Shelly.GetDeviceInfo via HTTP_in GET 192.168.188.22:50108 11:54:45 shos_rpc_inst.c:242 Sys.GetConfig via HTTP_in GET 192.168.188.22:50110 11:54:45 shos_rpc_inst.c:242 WiFi.GetConfig via HTTP_in GET 192.168.188.22:50112 11:54:45 shos_rpc_inst.c:242 Mqtt.GetConfig via HTTP_in GET 192.168.188.22:50114 11:54:45 shos_rpc_inst.c:242 Cloud.GetConfig via HTTP_in GET 192.168.188.22:50116 11:54:45 shos_rpc_inst.c:242 Switch.GetConfig via HTTP_in GET 192.168.188.22:50118 11:54:45 shelly_notification:162 Status change of switch:0: {"id":0,"aenergy":{"by_minute":[15.253,15.253,15.253],"minute_ts":1733655300,"total":27543.262}} 11:55:00 shos_rpc_inst.c:242 Shelly.GetStatus via HTTP_in GET 192.168.188.22:50192 11:55:00 shos_rpc_inst.c:242 Shelly.GetDeviceInfo via HTTP_in GET 192.168.188.22:50194 11:55:00 shos_rpc_inst.c:242 Sys.GetConfig via HTTP_in GET 192.168.188.22:50196 11:55:00 shos_rpc_inst.c:242 WiFi.GetConfig via HTTP_in GET 192.168.188.22:50198 11:55:00 shos_rpc_inst.c:242 Mqtt.GetConfig via HTTP_in GET 192.168.188.22:50200 11:55:00 shos_rpc_inst.c:242 Cloud.GetConfig via HTTP_in GET 192.168.188.22:50202 11:55:00 shos_rpc_inst.c:242 Switch.GetConfig via HTTP_in GET 192.168.188.22:50204 11:55:00 shos_rpc_inst.c:242 Shelly.GetStatus via HTTP_in GET 192.168.188.22:50290 11:55:15 shos_rpc_inst.c:242 Shelly.GetDeviceInfo via HTTP_in GET 192.168.188.22:50292 11:55:15 shos_rpc_inst.c:242 Sys.GetConfig via HTTP_in GET 192.168.188.22:50294 11:55:15 shos_rpc_inst.c:242 WiFi.GetConfig via HTTP_in GET 192.168.188.22:50296 11:55:15 shos_rpc_inst.c:242 Mqtt.GetConfig via HTTP_in GET 192.168.188.22:50298 11:55:15 shos_rpc_inst.c:242 Cloud.GetConfig via HTTP_in GET 192.168.188.22:50300 11:55:15 shos_rpc_inst.c:242 Switch.GetConfig via HTTP_in GET 192.168.188.22:50302
Und der Bruder, bei dem es nicht geht:
shelly_notification:162 Status change of switch:0: {"id":0,"aenergy":{"by_minute":[457.062,457.499,456.625],"minute_ts":1733655120,"total":85.416}} 11:52:00 shelly_notification:162 Status change of switch:0: {"id":0,"aenergy":{"by_minute":[456.625,457.062,457.499],"minute_ts":1733655180,"total":85.873}} 11:53:00 shelly_notification:162 Status change of switch:0: {"id":0,"aenergy":{"by_minute":[456.625,456.625,457.062],"minute_ts":1733655240,"total":86.330}} 11:54:00
Wenn ich die Device Data runterlade erkenne ich nur einen Eintrag (abgesehen von den IDs), der unterschiedlich ist
"config": { "sys": { "debug": { "level": 2, "file_level": null, "mqtt": { "enable": false
Hier steht beim korrekt arbeitenden enable:true
Kann mich jemand auf die richtige Fährte führe, was hier schief läuft?
-
@selle sagte in Shelly: Keine HTTP-Werte:
shelly.0.shellyplusplugs#ID#1.name ist bei einigen (null)
Der ist immer null, wenn keine Name vergeben wurde. Das ist erstmal normal. Den Wert kann man entsprechend setzen, damit dann ein neuer Name übermittelt wird. Und der steht dann auch in dem Datenpunkt.
-
@haus-automatisierung
Sorry, schlecht formuliert, das war nur ein Beispiel (Name ist auch vergeben). Betrifft beim Plug z.B. auch model, version, rssi und uptime. Relay0.Current (z.B.) und natürlich vor allem Relay0.Switch funktioniert problemlos -
@selle Dann sollte ein Log im Debug-Modus alle nötigen Infos liefern.
Ansonsten fehlen Infos zu den verwendeten Versionen. Also Adapter, Shelly-Firmware, usw.
-
@haus-automatisierung
Du meinst vom Adapter?Adapter-Version ist 8.2.1, ioBroker 7.1.5, Node.js 20.18.0 und NPM 10.8.2
Die Shellys sind 1.4.4 oder 1.4.2 -
Hat noch jemand eine Idee?
-
Bei mir steht null bis ich einen Namen setze, in deinem Log sehe ich auch nur Namesabfragen mit ergebnissen
-
@ticaki
Danke für deine Antwort, so ganz verstehe ich sie aber nicht. Die Shellys haben alle einen Namen, der auch angezeigt wird (sowohl über die IP als auch die Shelly Cloud), ich bin davon ausgegangen dass das einer der Werte ist, der nicht korrekt übertragen wird? -
@ticaki sagte in Shelly: Keine HTTP-Werte:
Bei mir steht null bis ich einen Namen setze
Das ist auch völlig korrekt so
-
@haus-automatisierung
Aber Namen setzen bedeutet hier in der Shelly-Umgebung, korrekt? -
@selle Geht auch über den ioBroker Datenpunkt. Sowohl für das Gerät, als auch für alle Kanäle
-
@haus-automatisierung
Okay, ich greife nach jedem Strohhalm und hab testweise direkt Namen vergeben, hat leider nichts geändert.Ich hab mir das Debug-Log nochmal angeschaut. Direkt am Anfang kommen 5 Einträge [onlineCheck] für die IPs, bei denen der Abruf funktioniert. Das könnte ein Ansatzpunkt sein, nach welchen Kriterien werden diese 5 abgefragt? Für einen der nicht funktionierenden gibt es kurz darauf zwei [MQTT] Publish die u.a. seine IP 192.168.188.35 enthalten, die wird aber nicht geschrieben und bleibt (null). Woran könnte das liegen?
Um das ausschließen zu können: Wenn es ein Authentifizierungsproblem gäbe, würde das gelogged werden, oder?