@longbow sagte in Neuer Adapter für Roborock-Staubsauger:

Wo finde ich die Dev Version….. ?

Ist oben irgendwo verlinkt

Ja scheint wohl seit letztem Monat "normal" zu sein. Kommt weiter oben schon vor... Man kann wohl entweder auf die vorherige Version zurück oder auf die dev...

@dk43 Das ist ja komisch, bei mir funktioniert diese livestream URL und zeigt bei mir eben die letzte Aufnahme an. Dafür habe ich diese filestore URL nicht. Liegt vlt daran, dass du ein Abo hast, ich habe nämlich keines. Evtl sind deswegen unsere URLs zu den letzten Aufnahmen unterschiedlich.

Aber gut, dann weiß ich jetzt immerhin, dass man selbst mit Abo, keinen wirklichen live link im iobroker hat, also auch immer nur die letzte Aufnahme sehen kann. Das macht für mich den Ring Adapter in Verbindung mit iQontrol dann uninteressant.

Ich danke dir für die Aufklärung.

@DK43 Hmm seltsam, bei mir ist der DP leer und das auch schon seit Wochen.

Einen filestore link habe ich in keinem der DP. Ich nutze aber mittlerweile die livestream url, das ist aber ne lokale URL vom Raspi und auch keine filestore url:

Die zeigt aber eben nur die letzte Aufnahme, ich hätte aber gerne ein Livebild... Ist dein filestore link ein livebild? Hast die ein ring abo aktiv?

Super. Vielen Dank euch

Ok prima, also ist es nicht schlimm, mehrere Falls Blöcke ineinander zu bauen. Solche Blöcke kommen nämlich bei mir öfter vor.

@codierknecht sagte in Diskussionsthread zu "Blockly für Dummies":

in diesem Fall ist Lesbarkeit wichtiger als noch das letzte Quentchen Performance rauszuquetschen.

Aber bedeutet das dann, dass die aufgeräumte, zweite Variante mehr Ressourcen/Zeit verbraucht als die erste? In diesem Fall geht es ja um das Einschalten eines Lichts per Bewegungsmelder und das soll so schnell wie möglich passieren...

@paul53 sagte in Diskussionsthread zu "Blockly für Dummies":

was mittels Timer-Variable eleganter geht:

Ach cool, das ist ja noch besser. Danke. Der grüne "Verzögerung timeout" Block oben gibt also immer an, ob dieser timeout gerade läuft, richtig?

Hallo. Ich bin gerade, bei der Suche nach der Antwort auf eine Frage, auf den Blockly für Dummies Thread gestoßen und würde die Frage einfach mal hier stellen, vielleicht wäre dieser Punkt evtl. auch für andere im Dummies Thread hilfreich.

Und zwar geht es um den "Falls Block". Ich habe in einigen meiner Skripte, bei den Falls Blöcken, mehrere Bedingungen mit den selben Variablen Abfragen und frage mich, welche Variante in diesem Fall ressourcenschonender und auch schneller ist. Bisher habe ich es immer, soweit es geht, vermieden, Falls Blöcke in Falls Blöcke zu bauen, weil ich meine mal gelesen zu haben, dass das nicht so gut sei. Ich habe dann immer mehrere Bedingungen mit "und" oder "oder" Blöcken zusammen gebaut und manche Variable so mehrfach überprüft, was ja, nach meinem Verständnis, aber eigentlich mehr Ressourcen benötigt. Deshalb frage ich mich mittlerweile, ob es nicht doch besser ist, in so einem Fall dann doch mehrere Falls Blöcke ineinander zu setzen, da so die jeweilige Variable nur einmal abgefragt werden muss und nicht mehrfach.

Hier mal Screenshots beider Varianten, dann ist es leichter zu verstehen, was ich meine. Als erstes, wie ich es bisher gemacht habe, hier wurden zb die Variablen Entpreller, AlexaImBett, BWM_HS mehrfach in Bedingungen gesetzt und mehrfach überprüft:

Und so habe ich den Block jetzt mal umgestellt mit mehreren Falls Blöcken ineinander:

Welche Variante ist denn jetzt tatsächlich die bessere, was den code, die Ressourcen und die Geschwindigkeit angeht? (Die Übersichtlichkeit ist eher zweitrangig)

@tombox Top, läuft wieder! Vielen Dank für die schnelle Reaktion

Guten Morgen,

ich habe seit heut morgen das Problem, dass der Adapter nur noch gelb bleibt. Auch im Log wirft er einige Fehler raus, u.A. AxiosError: Request failed with status code 418. Den Fehler gab es hier wohl letztes Jahr im November schon mal und konnte dort wohl durch ein Update behoben werden. Mein Adapter scheint mit Version v0.1.3 aber aktuell zu sein.
Der iobroker läuft bei mir seit zwei Wochen auf einem frisch aufgesetzten und aktuellem Raspberry Pi OS, bisher ohne Probleme.

Hier mal die Fehler die der Adapter auswirft, das waren die ersten Fehler heute morgen:

2023-12-14 08:46:08.685 - info: mercedesme.0 (139217) Lost WebSocket connection. Reconnect WebSocket
2023-12-14 08:46:10.866 - error: mercedesme.0 (139217) Websocket parse error
2023-12-14 08:46:10.867 - error: mercedesme.0 (139217) Error: Failure: Invalid wire type: %s (at position %s)
2023-12-14 08:46:16.038 - error: mercedesme.0 (139217) Websocket parse error
2023-12-14 08:46:16.039 - error: mercedesme.0 (139217) Error: Failure: Invalid wire type: %s (at position %s)
2023-12-14 08:46:21.188 - error: mercedesme.0 (139217) Websocket parse error
2023-12-14 08:46:21.189 - error: mercedesme.0 (139217) Error: Failure: Invalid wire type: %s (at position %s)
2023-12-14 08:47:26.343 - info: mercedesme.0 (139217) Lost WebSocket connection. Reconnect WebSocket
2023-12-14 08:47:28.515 - error: mercedesme.0 (139217) Websocket parse error
2023-12-14 08:47:28.516 - error: mercedesme.0 (139217) Error: Failure: Invalid wire type: %s (at position %s)
2023-12-14 08:47:33.665 - error: mercedesme.0 (139217) Websocket parse error
2023-12-14 08:47:33.665 - error: mercedesme.0 (139217) Error: Assertion failed

Das steht so alle ein bis zwei Minuten im Log. Und wenn ich den Adapter neustarte bzw. den Token erneuere:

2023-12-14 09:47:20.255 - error: mercedesme.0 (156851) AxiosError: Request failed with status code 418
2023-12-14 09:47:20.256 - error: mercedesme.0 (156851) ""
2023-12-14 09:47:20.261 - info: mercedesme.0 (156851) Start Websocket Connection
2023-12-14 09:48:20.457 - info: mercedesme.0 (156851) Lost WebSocket connection. Reconnect WebSocket
2023-12-14 09:49:22.627 - info: mercedesme.0 (156851) Lost WebSocket connection. Reconnect WebSocket
2023-12-14 09:49:24.797 - error: mercedesme.0 (156851) Error: Assertion failed

@martink said in [Tutorial] Xiaomi BWM HW Hack / 120s -> 5s Takt:

Also die Aqara Modelle RTCGQ11LM scheinen alle noch für das umlöten geeignet zu sein. Ab dem Model RTCGQ12LM scheint es nicht mehr zu klappen

Der thread ist zwar ein bisschen älter, aber ich habe aktuell auch zwei neue RTCGQ11LM gelötet und die gehen auch bei mir nicht auf 5 Sekunden, es bleibt leider bei der Minute.
Gibt es da vlt mittlerweile neue Infos zu? Evtl andere Lötpunkte oder ähnliches, um die eine Minute reduzieren zu können?