Weil ich hierzu gerade eine Frage per Mail bekommen habe: true und false auf die Art zurück zu geben ist redundant. Der Vergleich liefert ja bereits genau das, was man sucht. Aktuell wäre es also: "falls Ergebnis gleich true gib true zurück, sonst gib false zurück": val == 22 ? true : false Es reicht: val == 22 Mit ? : (also if else) würde man ja nur arbeiten, wenn man daraus wieder andere Datentypen / Wert machen möchte. z.B. val == 22 ? 'jau' : 'nö'

@liv-in-sky Hi, danke nochmals für deine Hilfe; soweit läuft es aktuell. Ich arbeite weiter. Werde vermutlich über die Ostertage weiter machen :)

@mathias-winkelmann Ich hatte das bei mir auch beobachtet, aber der DeepSleep funktioniert trotzdem. Die Meldung taucht bei mir im Log auch immer nur ein einziges Mal auf, wenn ich die DeeepSleepTime ändere und danach nicht wieder. Vielleicht hilft dir der Hinweis weiter, dass der Parameter DeepSleepTime nicht ganz intuitiv ist: DeepSleepTime 300 heisst zum Beispiel nicht, dass sich der Wemos ab dem Zeitpunkt des Setzens (sagen wir mal 09:02) für 300sec schlafen legt, sondern dass er sich schlafen legt und um 09:05 das nächste mal aufwacht, dann um 09:10... usw. Wenn der Wemos aufwacht und dann beispielsweise eine Minute lang damit beschäftigt ist, Sensoren zu lesen, sich mit dem WLAN zu verbinden, alle MQTT-Nachrichten zu lesen und zu schreiben oder ähnliches, dann wirkt sich diese Zeit nicht auf die DeepSleep Dauer aus, d.h. nach getaner Arbeit legt er sich z.B. um 10:32 schlafen und wacht um 10:35 wieder auf.

@spaceduck sagte in Discovery Adapteraktualisierung schlägt fehl: Hab NPM aktualisiert. Hat aber nix gebracht Genau DAS solltest du eben nicht tun. Schau ob das alles senkrecht ist: sudo ln -s /usr/bin/node /usr/bin/nodejs which nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs

@swisslizard sagte in CPU Last auf +-100% nach Crash und anschliessendem Restore: Wo das Problem genau lag weiss ich leider immer noch nich denke zum einen, war es dein Script und zum anderen, warst du zu ungedultig beim backup zurück spielen( das kann sich paar Stunden hinziehen)

@apollon77 Das bekomme ich hin. Konnte auch keine Fehler oder Probleme feststellen. Allerdings habe ich sicherheitshalber noch einmal einen Fix laufen lassen. Vorher wollte der Admin die Instanzen nicht richtig anzeigen. Oder ich war zu ungeduldig... Danke für Eure Hilfe. Nun läuft mein System wieder und ich kann mich um die Erweiterungen kümmern. In den letzten zwei Jahren sind ja einige IOT Geräte hinzugekommen bei uns im Haus...

@damrak2022 sagte in Aufzeichnung der Windgeschwindigkeit korrekt: Wie bekomme ich hier korrekte Werte? mit einer eigenen Wetterstation. Und dann hiermit in ioBroker einbinden. Kann dann so ausschaun. [image: 1649830478877-6012d087-4ace-4397-aefd-78641a6f5d96-image-resized.png]

ich habe nun das iobroker original image genommen, nun läuft alles, nachdem er das backup genommen und sehr lange geladen hat, super!

@mickym Ok super danke für die Info, werde es gleich mal versuchen

@berges01 ich dachte Du hast unter MQTT bereits einen Datenpunkt mit dem JSON String? Es würde Dir das Pollen ersparen. Ansonsten Glückwunsch..

@lustig29 sagte in Rolladensteuerung mit vis über homematic: dass die Tür aussieht wie eine Glastür? indem du dem Fenster sagst es sei eine Tür :-)

Ich habe es gelöst bekommen mit dem Tipp aus https://forum.iobroker.net/post/427775

@homoran sagte in im iOBrocker HMIP funk Tasterzustand abfragen?: @ofbeqnpolkkl6mby5e13 ich denke auch, dass eher der Status des mit dem Taster gesteuerten Aktors angezeigt wurde. Ja, so läuft z.B. mein Garagentor und meine Einfahrt - über den Aktor, nicht über die HmIP-FB. Das läuft schon so lang, das ich jetzt erst mal schauen musste, wie ich das überhaupt gemacht hatte Mein erster Eintrag hier, funktioniert tatsächlich nur mit meinen Hue Tastern. - sorry, mein Fehler

Weil ich grade drüber gestolpert bin -> Hier noch ein kleiner Input: https://github.com/DomiStyle/esphome-dlms-meter