Ich hab ein Update für den Adapter geschrieben. Dummerweise hat die App des Herstellers einen BUG. Wenn ein Kanal über 540 kommt, dann wird er zurück gesetzt auf 0 und auch der Gesamtertrag sinkt. https://homematic-forum.de/forum/viewtopic.php?f=47&t=87237 Um das zu korrigieren hab ich einen Datenpunkt hinzugefügt, der das egalisieren soll. Er summiert auf den aktuellen Gesamtertrag nun 540. Ein Counter checkt wie oft das passiert ist. Bei 2 Rücksetzungen 2* 540 usw. Beim erstmaligen installieren oder Update des Adapters muss der Counter einmal manuell gesetzt werden. Danach wird er hoch gezählt, wenn eine Rücksetzung erkannt wird. https://github.com/hefegraphie/ioBroker.apsystemsez1

uff, vielen Dank für die vielen, wertvollen Beiträge. Hab den Datenpunkt einfach unter "userdata.0.xxx" angelegt - und die Programmierung in Blockly angepasst - nun gibt es keine Fehlermeldungen mehr und der Code funktioniert - wie er soll - naja - ist ja nun auch nicht so komplex. Somit ist für mich das Thema "erledigt" - Wer noch gerne weiter diskutieren möchte kann dies gerne tun - ich sage an dieser Stelle aber erst einmal vielen Dank für alle so wertvollen beiträge. lg Goudi

Also wenn ich nun das ganze Matter geraffel richtig verstehe müsste ich es schaffen die BridgeX von tado mit dem Matter system von Iobroker zu verbinden. Das geht aber leider nicht. Grund hierfür ist das ich keinen Pairing code dafür erhalte sondern nur für das thread gerät selbst in meinem Fall das Thermosthat X. Somit sieht es für mich aktuell so aus das ich um einen eigenen thread border router nicht herum komme den ich dann in den iobroker einbinde. Kann das wer bestätigen?

@homecineplexx Probier doch einfach mal, den mit der Smartlife App zu koppeln. Wir haben auch einen NoName Saugroboter mit eigener App, den hab ich einfach testhalber versucht, mit der Smartlife App zu koppeln, und siehe da, das ging. Somit konnte ich den über den Tuya-Adapter in ioB bringen.

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.

@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.

@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. :-)

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.

@Urs sagte in Adapter: ebus: Ich vermute jetzt fast ein Problem mit der Firmware des Adapters, oder der ebusd-Version oder sowas in die Richtung, kann mich aber komplett täuschen. Die Versionen sehen so aus: Das kann unter umständen sein. Wie es aber mit dem Autoload der csv sich verhält kann ich dir nicht sagen da bei Vaillant alles Out of the box läuft. @Urs sagte in Adapter: ebus: Wie äussert sich das? Fehler im Logbuch? Heizungsstörungen? Bei mit stirbt der ganze Bus also mein Controller(Regler) im Flur ist dann Tot mein Internet-modul sagt nichts angeschlossen. Das Problem ist bei mir das sich das Internet-Modul auch als "Abfrage" Teilnehmer unterwegs ist und treffen diese Abfragen auf die Abfragen des EBUS Moduls dann crasht der Bus und kommt nicht mehr in Leben. Dann muss ich den Regler aus und einstecken und des I-Modul neu starten. Ich habe einen Intervall von 10 Minuten, da es mir reicht da ich es in erster Linie für WW Starten und Vorhersagebedingte Steuerung der Heizkurve nutze. Ich nutze den https://esera.de/Produkte/12001/EBC-100-eBus-Koppler-USB? War aber noch damals für 60€ zu haben autark an einem Pi 3. Deshalb kann ich dir keinen "internen" Werte sagen zu den Latenzen etc. Wenn der Schafft die csv zu laden brauchst du auch keine manuellen Abfrage machen, da die meisten dann sowieso im IOBroker stehen. Sorry das ich dir nicht bei allem helfen kann. Vielleicht mal dem Kontakt john30 aus dem Git schreiben ob es ne möglichkeit gibt das laden der csv zu forcen. Gruß Daniel