@thomas-braun said in Roborock - Adapter stürzt ständig ab:

@almeda sagte in Roborock - Adapter stürzt ständig ab:

Kann einer weiterhelfen?

Ohne Log? Schwierig.

Sorry, vergessen anzuhängen. Es erscheint die Warnung:
Failed to execute get_fw_features on robot 4d98R7TEpn6C0ZcYPNY52Q Error: Local request with id 5 with method get_fw_features timed out after 10 seconds

@haselchen said in Roborock - Adapter stürzt ständig ab:

@almeda

Warum nicht den Mihome-Vacuum?
Der funktioniert völlig unkompliziert und macht meines Erachtens das Gleiche wie Dein Adapter.
Bei meinem weiß ich allerdings, dass er funktioniert

Den hatte ich bisher nicht auf dem Schirm. Ich danke dir für den Hinweis. Probiere ihn gerne mal aus!

@haselchen said in Roborock - Adapter stürzt ständig ab:

@almeda

Wird der Roboter in der Instanz gefunden ?
Werden Objekte angelegt ?
Was sagt das Log?

Da S8 und ich meine S10 unterstützt werden, warum sollte der S7 da nicht bei sein?
Hab noch nen S50 2. Gen.

So zurück aus dem Urlaub und Zeit fürs Hobby

Danke für deine Rückfrage:
Es geht ja schon damit los, dass der Mihome-Vacuum Adapter einen Xiaomi Login will, denn ich für den Roborock S7 ja nicht habe. Der Roborock wird ja über den Roborock eigenen Cloudserver verwaltet.
Darüber habe ich mich dann gewundert und im Logg nachgesehen. Da steht eindeutig drin, dass alle Roboter, ausgenommen S7, unterstützt werden. Liegt wohl daran, dass der S7 anders kommuniziert, als die anderen Roboter.

Zurück zu meinem eigentlichen Problem eines ständig abstürzenden Roborock-Adapters:
Seit dem letzten Update ist der Adapter nicht mehr abgestürzt. Aber ob er stabil läuft, kann ich auch nicht sagen, da ich nun gelbe Warnungen bekomme:

code_text
```2024-05-24 00:44:00.430 - warn: roborock.0 (508) Reconnecting mqtt client!
2024-05-24 00:44:00.485 - warn: roborock.0 (508) MQTT connection close.
2024-05-24 00:44:00.485 - warn: roborock.0 (508) MQTT connection reconnect.
2024-05-24 01:44:00.430 - warn: roborock.0 (508) Reconnecting mqtt client!
2024-05-24 01:44:00.445 - warn: roborock.0 (508) MQTT connection close.
2024-05-24 01:44:00.445 - warn: roborock.0 (508) MQTT connection reconnect.
2024-05-24 02:44:00.429 - warn: roborock.0 (508) Reconnecting mqtt client!
2024-05-24 02:44:00.446 - warn: roborock.0 (508) MQTT connection close.
2024-05-24 02:44:00.446 - warn: roborock.0 (508) MQTT connection reconnect.
2024-05-24 03:10:28.073 - warn: roborock.0 (508) Unable to decode message for 4d98R7TEpn6C0ZcYPNY52Q. The the device is most likely offline. data: {"version":"1.0","seq":74,"random":641679,"timestamp":1716513028,"protocol":500,"payload":{"type":"Buffer","data":[123,34,111,110,108,105,110,101,34,58,102,97,108,115,101,125]},"crc32":2579086837}
2024-05-24 03:11:07.991 - warn: roborock.0 (508) Unable to decode message for 4d98R7TEpn6C0ZcYPNY52Q. The the device is most likely offline. data: {"version":"1.0","seq":87,"random":721864,"timestamp":1716513067,"protocol":500,"payload":{"type":"Buffer","data":[123,34,111,110,108,105,110,101,34,58,116,114,117,101,125]},"crc32":3231908517}
2024-05-24 03:44:00.430 - warn: roborock.0 (508) Reconnecting mqtt client!
2024-05-24 03:44:00.445 - warn: roborock.0 (508) MQTT connection close.
2024-05-24 03:44:00.445 - warn: roborock.0 (508) MQTT connection reconnect.
2024-05-24 04:44:00.430 - warn: roborock.0 (508) Reconnecting mqtt client!
2024-05-24 04:44:00.445 - warn: roborock.0 (508) MQTT connection close.
2024-05-24 04:44:00.446 - warn: roborock.0 (508) MQTT connection reconnect.
2024-05-24 05:44:00.430 - warn: roborock.0 (508) Reconnecting mqtt client!
2024-05-24 05:44:00.446 - warn: roborock.0 (508) MQTT connection close.
2024-05-24 05:44:00.446 - warn: roborock.0 (508) MQTT connection reconnect.```
code_text

So geht das jede Stunde in der 44. Minute der Stunde einmal durch...

@haselchen said in Roborock - Adapter stürzt ständig ab:

@almeda

Gib dann mal bitte Feedback….

Eben versucht und in der Dokumentation festgestellt, dass der S7 nicht funktioniert. Damit ist die Option leider auch raus

@thomas-braun said in Roborock - Adapter stürzt ständig ab:

@almeda sagte in Roborock - Adapter stürzt ständig ab:

Kann einer weiterhelfen?

Ohne Log? Schwierig.

Sorry, vergessen anzuhängen. Es erscheint die Warnung:
Failed to execute get_fw_features on robot 4d98R7TEpn6C0ZcYPNY52Q Error: Local request with id 5 with method get_fw_features timed out after 10 seconds

@haselchen said in Roborock - Adapter stürzt ständig ab:

@almeda

Warum nicht den Mihome-Vacuum?
Der funktioniert völlig unkompliziert und macht meines Erachtens das Gleiche wie Dein Adapter.
Bei meinem weiß ich allerdings, dass er funktioniert

Den hatte ich bisher nicht auf dem Schirm. Ich danke dir für den Hinweis. Probiere ihn gerne mal aus!

@ticaki said in Roborock - Adapter stürzt ständig ab:

Das abschalten der Maperzeugung, so das diese Fehlerbehandlung nicht mehr aufgerufen wird, ist sicher ein Weg.

Hallo zusammen,
ich möchte mich an dieses Thema kurz mit anhängen. Nutze den Roborock Adapter seit ca. 4 Wochen und habe seit Anbeginn, trotz ausgeschalteter Map Erstellung, das Problem, dass der Adapter laut dem Host ständig abstürzt und er ihn daher regelhaft nach 1-2 Tagen aus dem Rennen nimmt und den Neustart verhindert.

Tatsächlich hat die Einrichtung nach der Installation problemlos geklappt und auch die Anbindung an Node-Red zum Ausspielen der Stati über Telegramm hat sofort funktioniert.

Eine De- und Neuinstallation des Apdaters hat nichts gebracht. Ich habe dann auf das aktuelle Update gewartet, weil ich es für ein vllt. bekanntes Problem hielt. Das Update von vor einigen Tagen hat jedoch keine Besserung gebracht.
IoB läuft auf einem Synology 918+ mit ausreichend RAM. Kein anderer Adapter macht Probleme.

Kann einer weiterhelfen?

Vielen Dank
Almeda

@schneidy76
Vielen Dank für deinen Beitrag.
Das mit dem Kamin ist kein Problem, wir haben nämlich keinen.
Ansonsten hast du recht, mir ist das zu trivial. Im Grunde hast du ja die Lüftung hinter einen Zeitschaltuhr gehängt, der du einen Aus-/Ein-Knopf verpasst hast. Das habe ich jetzt auch schon so ähnlich. Nur dass mein Ein-/Aus-Knopf ein Sommer-/Winter-Knopf ist.
Ich denke ja schon ne ganze Weile darüber nach und meine oben genannten Kriterien sind ja genau aus solchen Überlegungen gewachsen.
Mir ging es mehr darum, dass ich nicht wusste, wie ich meine Ideen in Node-Red umsetzen und zusammenbauen soll. Aber wie sagt man immer: "Wenn du es dir vorstellen kannst, kannst du es auch tun."
Was mir bei dir z. B. im Sommer schon fehlen würde: Oft ist es ja in heißen Sommern manchmal bis 3 Uhr nachts draußen immer noch >Raumtemperatur. Dann saugst du dir also von Sonnenuntergang von z. B. 22Uhr - 3 Uhr die warme Luft rein.
Am Beispiel von mickym sieht man ja, dass es logsicher/smarter geht.

@mickym
WOW! Vielen Dank für deinen Input. Du hast recht, es ist meinerseits stellenweise zu komplex gedacht.
Aber mit deinen Ausführungen, glaube ich, aktuell alles nötige zu haben und werde mich am Wochenende mal raussetzen und versuchen, das umgesetzt zu bekommen.
Es werden dabei sicherlich weitere Fragen auftauchen, daher werde ich mich bald mit dem Ergebnis wieder melden

@albert-k
Vielen Dank für deinen hilfreichen Input.
Das Wetter abholen ist nicht das Problem. Ich hatte schon vor geraumer Zeit das äußerst umfangreiche Thema von mickym dazu durchgelesen, wo er über Wochen hinweg immer mal mit dem einen, mal dem anderen Anbieter und entsprechender API die Daten abholt, um am Ende dann beides zu nutzen.
Aber wie du sagst, so dezidiert brauche ich es vllt. gar nicht. Ich habe überlegt, ob mir entweder Temp-Max und Temp-Minimum reichen. Oder ob ich vllt. 24 Temperaturwerte für einen Tagesverlauf brauche, um dann automatisiert den besten Abschnitt der Lüftung bestimmen zu lassen.

Solche Temperaturunterschied von 15° innerhalb weniger Stunden haben wir hier nicht. Und die Verschattung läuft bei mir bereits vollautomatisch sonnenstandsgeführt nativ in KNX.

@mickym
Vielen Dank auch dir für deinen Input. Ich schätze deine Expertise immer sehr. Wenn man hier so quer durchs Forum liest, ist es schon immer beeindruckend, wie du das Thema durchdrungen hast. Sicherlich bin ich davon weit entfernt und werde es auch dauerhaft bleiben. Dennoch lese ich mir das meiste selbst an und experimentiere, bis ich das Ergebnis habe.

Dein umfangreiches Thema zum Abholen der Wetterdaten habe ich schon vor 3-4 Wochen gelesen. Aus dem Topic ist mir am Ende nur nicht klar geworden, was für mich nun das richtige ist. Das liegt sicherlich auch daran, dass ich nicht weiss, was ich überhaupt an Input benötige, dass die Flows am Ende dann auch den richtigen Lüftungszeitraum bestimmen.

Was genau meinst du "die Logik mit Triggern definieren"?

Scheduler Todes und Chronosnodes schau ich mir dieser Tage mal an.
Ansonsten war schon bei Erstellung dieses Themas meine Idee, zunächst mal Temp-Max und Minimum abzuholen und in eine Contextvariable zu schreiben. Zuerst habe ich überlegt, z. B. mit einem Big-Timer zu arbeiten, welcher ja den Vorteil hat, auch einen Input zu haben, womit man den Timer überschreiben und auf Off setzen kann. Wenn ich es aber streng einfach nach Winter- u. Sommerzeit unterteile, kann es in den Übergangszeiten (Frühjahr/Herbst) ja trotzdem dazu kommen, dass das System zu ungenau ist.

Am Ende fehlt mir die Vorstellung, was ich brauche oder wie ich es am besten umsetze, dass ich z. B. einmal die Wetterdaten um 23Uhr Abends für den Folgetag abhole, dann z. B. 24 Temperaturwerte habe und dann automatisiert entscheide, welcher Zeitraum der beste für die Lüftung auf True ist.
Dazu kommt, dass ich eine vollwertige KNX Wetterstation am Dach habe und tatsächlich auch noch auf Echtzeitdaten zugreifen kann, diese jedoch im Sommer bei direktem Sonnenlicht auf die Wetterstation (weil auf dem Dach) wohl zu hohe Temperaturen liefert. Also auch nicht ganz optimal.

VG
Almeda

Hallo zusammen,

mir fehlt es gerade so an der richtigen Idee, wie ich meine Lüftung automatisieren kann. Vllt. gibt es hier ja jemanden, der Ähnliches schon umgesetzt hat oder zumindest eine schlaue Idee hat.

Zur Ausgangssituation:
Ich habe eine banale Wohnraumlüftung, die leider ohne Energierückgewinnung banal die Luft wie ein Staubsauger in den Schlafzimmern/Küche absaugt und nach draußen befördert. Gleichzeitig strömt dann frische Luft (aufgrund des Unterdrucks in den Zimmern) über Lüftungsschlitze in den Fensterlaibungen nach. Problem: Im Sommer saugt man sich bei kühler Innentemperatur die heiße Luft rein. Im Winter genau umgekehrt, saugt man sich die kalte Luft rein und muss ständig dazu heizen. Zudem merkt man insbesondere im Winter, wie die kalte Luft förmlich in den Raum "fällt".

Also habe ich mir folgende Anforderung an eine Automatisierung überlegt:
Abhängig von der Wettervorhersage für den Folgetag soll bei einer Maximaltemperatur <= Heizschwelle (19°) nur zwischen 11 und 16 Uhr gelüftet werden. Bei Temperaturen zwischen 19° und 25° soll die Lüftung 8 Stunden am Tag laufen, jedoch nur bis zu der Zeit wo die Außentemperatur maximal 23° hat. Bei prognostizierten Temperaturen >25° soll gelüftet werden, wenn die Außentemperatur < Innentemperatur - sonst nicht.

Es soll dann noch Flows geben, die quasi die o.g. Basiseinstellung überschreiben und eine Zwangsbelüftung darstellen. Diese habe ich bereits in Benutzung.

1. Beim Duschvorgang/längerer Toilettennutzung im Bad
2. Bei Wama/WT-Aktivität im Waschraum und gleichzeitig geschlossener Türe
3. Beim Kochvorgang in der Küche
4. Bei schlechtem VOC-Wert in den Schlafräumen

Im Moment fehlt mir die Idee der Umsetzung, dass ich "heute" den Wetterbericht für "morgen" auswerte (z. B. Openweathermap) und dann für "morgen" dann den Lüftungskorridor festlege.
Ich denke nämlich, dass wenn ich nur simple auf die aktuelle Temperatur, die ich ja stündlich auslesen könnte, reagieren lasse, könnte es ja sein, dass ich entweder zu früh oder zu spät lüfte. Auch MUSS ja jeden Tag gelüftet werden, sprich würde z.B. in einem heißen Sommer die Außentemperatur nie unter die Innentemperatur fallen, würde das System niemals lüften. Eine gute Planung würde hier dann vllt. die 6 Stunden Nachts wählen, wo z. B. die Temperatur zwar nicht niedriger, aber vllt. = Innentemperatur wäre (z. B. Nachts zwischen 2Uhr und 8 Uhr).

Ich hoffe ich habe mein komplexen Gedankengang transportieren können und bin auf zahlreiche Ideen und Input gespannt.

Vielen Dank
Almeda

@glasfaser said in Dashboard - "Can't GET /ui":

https://forum.iobroker.net/post/533169

Dann sollte ich es vllt. konkretisieren: Dieses Topic hatte ich gefunden, jedoch sind darin einen Haufen Probleme beschrieben, die ich alle samt nicht habe und dementsprechend auch die Lösungswege mir nichts nutzen.
Ich habe tatsächlich nur isoliert das Problem, dass sich die UI nicht aufrufen lässt.

Ich habe auch keine Fehlermeldungen in den Protokollen.

EDIT 09.10.2023:
Da ich einfach keine andere Möglichkeit sah, bzw. nicht wusste, wo ich ansetzen soll, habe ich sämtliche Flows zunächst aus dem IoBroker Ordner gesichert. Anschließend habe ich den Adapter innerhalb des IoBrokers komplett gelöscht und neu installiert.
Siehe da: Die UI geht wieder.
Überraschend: Die Flows wurden auch erhalten bzw. wieder direkt übernommen.

Guten Abend zusammen,

der Titel des Themas, wozu ich nichts wirklich passendes in der Suche finden konnte, beschreibt das Problem bereits.

Ich betreibe Node-Red unter IoBroker auf einem Syno-NAS in einem Docker Container. Sowohl der Container, als auch der IoBrocker funktionieren tadellos. Alle Adapter sowie der NODE/JS-Controller sind auf dem aktuellsten Stand.
Innerhalb Node-Red kann ich mit vollem Funktionsumfang arbeiten, meine Flows funktionieren tadellos, auch mit der gesamten Peripherie (KNX bzw. andere Adapter).

Einzig das Dashboard lässt sich nicht aufrufen. Egal ob aus Node-Red heraus oder auch direkt über http://localhost:1880/ui - ich bekomme immer eine weiße Error Seite mit dem Hinweis "Can't GET /ui".

Das Dashboard und die passenden Notes sind natürlich über die Paletten installiert. Zudem habe ich bereits eine gewisse Gliederung der UI durchgeführt und einzelne Nodes auch einzelnen Tabs/Links zugeordnet.

Ein Neustart des Adapters im IoBroker brachte keine Änderung.

Vielen Dank für eure Ratschläge

Almeda

@mickym
Absolut sicher.
Hab es jetzt auch so eingestellt und eben mal am lebenden Objekt getestet, funktioniert so einwandfrei.