NEWS

@Xandar31
Intervalle (auch noch verschachtelt) sind keine gute Idee. Als Trigger würde ich die aktuelle Fritz-Temperatur verwenden, da sich diese am häufigsten ändert. Den Sollwert (targettemp) würde ich um die Temperaturdifferenz Fritz - Aqara gegenüber dem Comfort-Wert erhöhen:
Sollwert = Comfort-Wert + Fritz-Temperatur - Aqara-Temperatur

Blockly_temp.JPG

Betragen die Sollwert-Stufen beim DECT 301 auch 0,5 K (wie bei HomeMatic) ?

@paul53
Dann baue ich da eben noch ein, ist auch die bessere Lösung als drauf zu vertrauen, dass es irgendwann passen wird.

Der verantwortliche Trigger wird dann eben ein Mysterium bleiben, da der Anwesenheits- DP selbst beim Abmelden erst mit 2 Minuten Verzögerung schaltet um ungewollte Aktionen bei kurzen WLAN Unterbrechungen zu vermeiden. Somit hat der DP definitiv nie auch nur kurz sein Staus geändert, was der Zeitstempel auch bestätigt.
Wie ich das hasse, wenn was anders läuft als geplant und ich kein Plan habe warum das so ist 🙂

Danke für die Hilfe.

ja daran dachte ich auch schon, dann kann ich aber auch direkt den bildpfad in einen datenpunkt schreiben so wie ich es aktuell vorbereitet habe.

Bildschirmfoto 2020-03-01 um 17.51.34.png

Dachte nur das geht vieleicht einfacher.

@Dom-Sch sagte:

(cloudly, cloudly_with_rain, ... , usw. ) das passende wetter symbol im vis anzeigen zu lassen ?

Da das nichts mit der Windrichtung zu tun hat, solltest Du ein neues Thema eröffnen.

@nox sagte in Steckdosen sollten/können sich selbst abschalten:

Cool wäre es, wenn man nicht für jede Steckdose ein Script braucht.

Da ja alleine die von dir in Variablen festgehaltenen Werte von denen an der Steckdose angeschlossenen Geräten abhängt wird das nichts (o einfach)!

@nox sagte in Steckdosen sollten/können sich selbst abschalten:

Bekommt man sowas auch dynamischer hin?

Was ist für dich dynamisch?

@nox sagte in Steckdosen sollten/können sich selbst abschalten:

Das läuft auch soweit. Er schaltet ab nach 30 min. Wenn ich das Gerät wieder starte, wird der Timeout gelöscht.
Alles gut.

Dann ist doch gut.

Zu meinem 2ten Problem:

Ich habe gestern ein Update des Adapters gemacht und die Backupzeit von 2Uhr auf 3Uhr gestellt und siehe da jetzt geht es wieder

Okay verstehe 👍

Ihr braucht nur die History beim "Befehl" sprechen beobachten, dann seht Ihr wie die Dame etwas schreibt.

@liv-in-sky
Super danke.

Mein Ziel ist es, zum Zeitpunkt HH:MM zu checken, ob ein Gerät läuft, d.h. der Stromverbrauch entsprechend hoch ist. Telegram, Stromverbrauchscheck funktioniert; nur die Zeitabfrage halt nicht...

Ich habe es selbst hinbekommen 🙂

mit zwei Kommandos die man nach belieben verändern kann...
Das ganze sieht in Blockly folgendermaßen aus:
68009eb9-0447-4be3-a0fc-4fe974d37bb7-image.png

@Asgothian

Ah klasse, vielen Dank, das kannte ich noch garnicht 👌

@mawi1986 gerne!

Hallo, ich habe es jetzt mal probiert, wie beschrieben, allerdings funktioniert das auch nicht!

Ich bin am verzweifeln, in den Objekten sehe ich bei der Eingetragen ID definitiv eine Änderung, sie springt von Ready auf Run und wieder auf Ready, der Zeitstempel ändert sich dabei natürlich auch!

Ich weiss nicht mehr weiter !

So sieht es jetzt bei mir aus :
e2f4b5d2-41be-4ebd-af2b-7998f81ed0f8-image.png

Vielen Dank.

Ich hatte den Timeout Stop nie beachtet.

@Atifan sagte in wie Skript für Stromverbrauch der letzten Tage?:

Ah, habe den Fehler gefunden.
Ich hatte im Datenpunkt manuell die Einheit "m³" eingetragen.
Im Sourceanalytics Adapter heisst die Einheit aber "m3".
Wenn die beiden unterschiedlich sind funktioniert es nicht. 🙂
Thx für den Tipp mit der Unit 🙂

@Semie1 sagte:

wollte ich das script für die Thermostate verwenden, geht das

Nein, das ist ein 2-Punkt-Regler-Script (für Schaltaktoren). Die HKT enthalten einen PI-Regler, bei dem man nur den Sollwert vorgeben kann.

Super Danke!!!

@CruziX sagte in Deconz Adapter schaltet bei Neustart:

@Asgothian Aber der Trigger größer als vorher verhindert ja z.B. die Erkennung von Events die eine kleinere Nummer haben als die Jetzige, bsp. 1003 -> 1001

Lesen hilft. Ich habe oben beschrieben wie der Datenpunkt arbeitet:

@Asgothian sagte in Deconz Adapter schaltet bei Neustart:

Das wird nicht gehen. Der Datenpunkt bekommt fuer eine kurze Zeit einen Zahlenwert aus dem der auf dem Schalter gedrueckte Knopf (und die Art) erkennbar ist, und faellt dann auf 0 zurueck.

Im Normalfall steht der Datenpunkt auf 0. Nur wenn eine Taste erkannt wurde wird kurzzeitig ein Wert > 0 eingetragen, danach wieder 0.

Es ist theoretisch denkbar das ein schneller Wechsel von verschiedenen Schaltzuständen nicht erkannt wird, mir ist das aber nie in versuchen gelungen. Zumeist erkennen die Schalter selber diese Zustände. (bsp.: die Aquara Doppel-Schalter geben einen eigenen Wert für "beide Schalter gedrückt", wenn (fast) gleichzeitig beide gedrückt werden.

@CruziX sagte in Deconz Adapter schaltet bei Neustart:

@Jey-Cee
Also kann man auf die Objekte von Deconz keine Trigger mit aktualisiert verwenden, ohne sicherzustellen, dass die Uptime groß genug ist?
Wäre es nicht auch möglich beim Füllen der Datenpunkte abzufragen, ob diese bereits den Wert enthalten?
Das passiert an dieser Stelle ja nur beim Neustart des Adapters, also wenn die meisten Datenpunkte schon befüllt sind.

Das wurde bereits weitgehend diskutiert. Es macht durchaus Sinn das der Adapter die States bei Beginn aktualisiert, dann ist am Zeitpunkt der letzten Anpassung erkennbar wann der Wert das letzte mal gesetzt wurde. Des weiteren schützt eine Abfrage auf "ist der wert schon da" nur bedingt, und man riskiert das Anpassungen seitens der Quelle nicht sauber eingetragen werden. Genau deswegen gibt es ja für Taster 2 Datenpunkte - buttonpressed und buttonevent. Einer wird immer nur kurz auf den aktuellen Taster-Wert gesetzt, der andere beinhaltet den letzten erkannten Taster-Wert.

Ich nutze beide seit dem sie eingeführt wurden ohne das ich Probleme mit selbst schaltenden Lampen beim Start des Adapters habe.

A.