Die Kommunikation wird immer vom Master initialisiert. Der Master/Client ist immer in der Holschuld, also muss der "Chef" selber dafür sorgen die Daten zu bekommen. Gruß Daniel

@Chris0706 sagte in Sungrow Wallbox AC011E-01 erfolgreich mit Modbus eingebunden: Habs beim überfliegen nicht gefunden.. man kann auch dieselbe Modbus Instanz des Wechselrichters nehmen, um die Werte der Wallbox zu pullen. Man muss nur 'Mehrere Geräte-IDs' auswählen und in den Registern entsprechend die 'deviceId' ergänzen. Wechselrichter natürlich die 1, Wallbox findet man im WiNet-2 -> Geräte -> Geräteliste -> Weiterleiten der Modus-ID. Ja das geht theoretisch, es hat sich aber beim Betrieb herausgestellt (zumindest bei einigen Leuten und ich kann das auch bestätigen), dass der Wi-NET Adapter nicht gerade eine schnelle CPU inne hat. Was stabil läuft ist eine Auftrennung der beiden Instanzen. Eine Instanz mit Modbus auf den Ethernet Anschluss des Wechselrichters und eine Instanz mit Modbus auf den Wi-NET Adapter für die Wallbox.

Danke. Werde es zeitnah testen und melde mich.

@Homoran oh,das wusste ich nicht, ich gelobe Besserung. Wollte eigentlich nur einen Denkanstoß setzen. Etwas hat es ja schon gebracht. Ich wusste nicht das es einen Menüadapter dafür gibt. Und schon wieder was dazu gelernt. Beim nächsten mal besser.

Hallo zusammen, ich habe herausgefunden, warum die allerneuesten Modelle im Adapter aktuell komplett ignoriert werden und localDevices: {} zurückliefern. Roborock hat die API-Struktur für neue Modelle geändert! > Die neuen Geräte tauchen im JSON nicht mehr unter "devices": [] auf (dieses Array ist bei mir komplett leer). Stattdessen liegen sie jetzt unter "products": [...] und nutzen ein neues RPC-Schema für die Datenpunkte. Da der Adapter nur in devices sucht, übersieht er den Sauger, anstatt ein 'unknown model' zu melden. Mein Modell: roborock.vacuum.ss09 (Roborock Q10 Series) Hier ist der komplette HomeData-String: {"id":1234567,"name":"My Home","lon":null,"lat":null,"geoName":null,"products":[{"id":"XXXXXXXXXXXXXXXXXXXXXX","name":"Roborock Q10 Series","model":"roborock.vacuum.ss09","iconUrl":null,"attribute":null,"capability":0,"category":"robot.vacuum.cleaner","schema":[{"id":101,"name":"RPC Request","code":"rpc_request","mode":"rw","type":"RAW","property":"null"},{"id":102,"name":"RPC Response","code":"rpc_response","mode":"rw","type":"RAW","property":"null"},{"id":120,"name":"错误代码","code":"error_code","mode":"ro","type":"ENUM","property":"null"},{"id":121,"name":"设备状态","code":"state","mode":"ro","type":"VALUE","property":"null"},{"id":122,"name":"设备电量","code":"battery","mode":"ro","type":"ENUM","property":"null"},{"id":123,"name":"吸力档位","code":"fan_power","mode":"rw","type":"ENUM","property":"null"},{"id":124,"name":"拖地档位","code":"water_box_mode","mode":"rw","type":"RAW","property":"null"},{"id":125,"name":"主刷寿命","code":"main_brush_life","mode":"ro","type":"ENUM","property":"null"},{"id":126,"name":"边刷寿命","code":"side_brush_life","mode":"ro","type":"ENUM","property":"null"},{"id":127,"name":"滤网寿命","code":"filter_life","mode":"ro","type":"ENUM","property":"null"},{"id":135,"name":"离线原因","code":"offline_status","mode":"ro","type":"ENUM","property":"null"},{"id":136,"name":"清洁次数","code":"clean_times","mode":"rw","type":"ENUM","property":"null"},{"id":137,"name":"扫拖模式","code":"cleaning_preference","mode":"rw","type":"ENUM","property":"null"},{"id":138,"name":"清洁任务类型","code":"clean_task_type","mode":"ro","type":"ENUM","property":"null"},{"id":139,"name":"返回基站类型","code":"back_type","mode":"ro","type":"ENUM","property":"null"},{"id":140,"name":"基站任务类型","code":"dock_task_type","mode":"ro","type":"ENUM","property":"null"},{"id":141,"name":"清洁进度","code":"cleaning_progress","mode":"ro","type":"ENUM","property":"null"},{"id":142,"name":"窜货信息","code":"fc_state","mode":"ro","type":"RAW","property":"null"},{"id":201,"name":"启动清洁任务","code":"start_clean_task","mode":"wo","type":"ENUM","property":"null"},{"id":202,"name":"返回基站任务","code":"start_back_dock_task","mode":"wo","type":"ENUM","property":"null"},{"id":203,"name":"启动基站任务","code":"start_dock_task","mode":"wo","type":"ENUM","property":"null"},{"id":204,"name":"暂停任务","code":"pause","mode":"wo","type":"RAW","property":"null"},{"id":205,"name":"继续任务","code":"resume","mode":"wo","type":"RAW","property":"null"},{"id":206,"name":"结束任务","code":"stop","mode":"wo","type":"RAW","property":"null"},{"id":207,"name":"用户改善计划","code":"ceip","mode":"rw","type":"ENUM","property":"{\"range\": [\"0,1\"]}"}]}],"devices":[],"receivedDevices":[],"rooms":[]}

Siehe https://github.com/iobroker-community-adapters/ioBroker.shelly/issues/1355 Bitte ergänze im Issue: Output of http://ip-der-lampe/rpc/Shelly.GetStatus Und da das Ding wahrscheinlich virtuelle Komponenten benutzt bitte auch um folgendes: Bitte folgende Befehle absetzen und den Output posten - am besten im oben genannten Issue http:/ip-des-shellies/rpc/Shelly.GetComponents?offset=0 http:/ip-des-shellies/rpc/Shelly.GetComponents?offset=5 http:/ip-des-shellies/rpc/Shelly.GetComponents?offset=10 http:/ip-des-shellies/rpc/Shelly.GetComponents?offset=15 http:/ip-des-shellies/rpc/Shelly.GetComponents?offset=20 etc. Der Befehl liefert immer nur ca 10 Komponenten. Ganz am Ende steht aber eine Totals Zahl. Bitte daher ein oder meherere Abfragen mit ansteigendem Offset absetzen. Der Abstand von 5 im obigen Beispiel wird wahrscheinlich überlappungen liefern. Wer will kann auch zählen und den Offset dann geeignet anpassen :-) DANKE VIELMALS für die Unterstützung.

Moin ! Es gibt seit heute eine Version 1.6.0 - alpha. Wer mag ist gerne zum ausprobieren eingeladen. A guide to install alpha versions can be found here https://forum.iobroker.net/post/1263819 (please replace heyyl by spotify-premium :-) )

@paul53 Hat sich erledigt, danke. Hab mir mit AI aus dem physischen Handbuch alle Meldetexte mit Ursache und Abhilfe lesen lassen und mir ein State angelegt wo alle Texte strukturiert als JSON liegen. Anhand der Meldenummer die vom Modbus kommt mach ich dann via Blockly ein Lookup und ziehe mir den entsprechenden Meldetext zur Nummer und verarbeite sie entsprechend weiter.

(delete)

Problem gelöst. Die App ioBroker Visu kommt mit dem Energieflussadapter-erweitert gut zurecht, auch mit den anderen Views.

Da hast du das wohl missverstanden. Es war rein informativ gemeint. Ich habe nicht erwartet, dass der Adapter das fixed, denn gefixed habe ich es ja schon über Blockly. Selbst ein Rücksetzen eines Zählers auf 0 durch Stromausfall o.ä. hat eigentlich nichts mit dem Adapter zu tun sondern ist ein "good will".

Ich habe jetzt die 3.1.5 installiert , jetzt funktioniert die Watt anzeige . werde das erstmal so lassen , bis es behoben ist danke für die info

@Kapitaen31 Swap erhöhen ist aber auch nur eine hilfskrücke um den Absturz zu verhindern. Für die Performance ist es katastrophal. Insbesondere Datenbanken arbeiten stark mit RAM. Wenn dein Datenbestand größer wird und du das System noch weiter ausbauen willst, wirst du neue Hardware benötigen.

Den manuellen Prozess (nicht "suchen" lassen, sondern über "iobroker setup custom" mit Angabe der beteiligten IPs) habe ich natürlich benutzt. Sonst hätte ich die Slaves ja gar nicht verbunden bekommen. Meinst Du, daß die alive-Erkennung in dem Fall eben grundsätzlich nicht funktioniert und das Verhalten wie bei mir daher normal ist? Aber ok, damit kann ich leben. :-)

Bei mir läuft auf dem Venus 3.0 eine Firmware V147.117.112 leider nicht ohne Probleme so dass ich deshalb auch Firmware-Fehler / API-Fehler vermute. Mal sehen was mit den Support für einen Version kommt. Und auch mit Pausen waren noch nicht erfolgreich.

Link zu Issue https://github.com/ioBroker/ioBroker.history/issues/470

@mcm1957 sagte in {gelöst} Maxcul Adapter veraltet, bitte aktualisieren.: @ESP8266 sagte in {gelöst} Maxcul Adapter veraltet, bitte aktualisieren.: Wie sie hier im Thread beschrieben ist. Kannst du bitte genauer verlinken. In diesem Thread sind einige Vorgangsweisen beschrieben. Welches ist denn die von dir benutzte? Post 28 iob upgrade maxcul@1.3.1 --debug Rebuild

Bzgl. logrotate. Ich hab die Bude mal neu gestertet und jetzt läuft der Service. Danke für deine DIAG Prügung!

@Qlink sagte in Nuki Ultra per MQTT received pubrec for unknown messageId 0: jetzt heißts nur noch abwarten und teetrinken, bis es der PR in eine neue Adapterversion schafft, verstehe ich das richtig ? Du kannst dir die von mir angepasste Version installieren (Expertenmodus --> Adapter --> Katze --> Benutzerdefiniert --> "https://github.com/Marc-Berg/ioBroker.mqtt/tree/fix/qos-retry-reliability") Bei noch genauerer Betrachtung führten zwei Fehler in deiner Konstellation zum Fehler: Der Adapter/Broker verwirft Messages einfach, nachdem der Client 11x nicht geantwortet hat. (nicht MQTT Protokoll konform) Kommt der Client mit den nun unbekannten Message-IDs vorbei, reagiert der Broker nicht adäquat und schickt den Client in einen Endlos-Loop. (ebenfalls nicht MQTT Protokoll konform) Ich nehme an, dass die Nuki-Stromsparmaßnahmen (WLAN würde sonst die Batterien in kurzer Zeit leersaugen) der Trigger des Ganzen sind. Der Broker sollte nun aber in meiner Version besser damit umgehen können.