Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Homoran]

Seit einiger Zeit funktionieren meine Blockly-gesteuerten Dimmer nicht mehr so wie es früher (und geplant) war.
Ich weiß nicht, ob es zu dem Zeitpunkt ein Update des hm-rpc oder des javascript Adapters gab oder gar die Firmware der HM-LC-Dim1TPBU-FM gab.

Symptom:
Ich habe Blocklys in denen ich eine hohe RAMP_TIME setze und anschließend den Ziellevel. Erwartet wird (und das war früher so) dass jetzt die Lampen ganz langsam herunterdimmen.
Seit Zeitpunkt x dimmen die Lampen sofort auf den Ziellevel.

Ich habe schon die Geräte gelöscht, neu eingelesen, zurückgesetzt - was auch immer alles half nichts.

Jetzt bin ich durch diesen Thread nochmal daran gegangen das Problem näher einzugrenzen.

Nochmals alles wie oben genannte probiert - keine Änderung.

• Manuell zuerst die RAMP-TIME und anschließend den Level geändert: funktioniert
• gedacht das war es - Pustekuchen, abends per Skript geschaltet: funktioniert nicht
• In den Objects wird der richtige Wert eingetragen, aber nicht übernommen, der Wert bleibt rot.

Habe dann den Wert für RAMP_TIME geändert. Beim nächsten Programmaufruf änderte er sich blieb wieder rot.

Jetzt habe ich analog zum verlinkten Thread den Wert manuell höher gesetzt als das Skript ihn setzt.
Ergebnis werde ich erst heute abend sehen.

Kann mir jemand (vielleicht @foxriver76 ) weiterhelfen, oder sagen was ich noch testen kann?

Danke!

[paul53]

@Homoran sagte:

In den Objects wird der richtige Wert eingetragen, aber nicht übernommen, der Wert bleibt rot.

Stimmt dann die Überschrift ?
Der Wert wird ja durch das Skript gesetzt, aber nicht von der CCU bestätigt.

[Homoran]

@paul53 Da hast du recht.
Habe die Überschrift jetzt mehrfach ändern müssen wegen der 50 Zeichen Begrenzung - da kam dann das bei raus ;-(
Ich versuche es nochmal

EDIT: hoffe es passt jetzt

[Homoran]

Und hier noch der Ausschnitt des Blockly:

"Nach Zahl" war noch ein hilfloser Versuch - könnte wieder raus

[foxriver76]

@Homoran man könnte mal schauen ob die RAMP_TIME überhaupt korrekt in der CCU übernommen wird. Auf meiner Seite fällt mir erst mal keine vorgenommene Änderung ein die dazu führen könnte.

[paul53]

@Homoran sagte:

Ausschnitt des Blockly:

Hast Du mal versucht, RAMP_TIME und LEVEL unmittelbar hintereinander (gemeinsames Timeout) anstelle mit 20 s Versatz zu senden ?

[Homoran]

@foxriver76
Manuelle Änderung unter Objects und anschließenden manuelle Änderung des Levels funktionieren.

@paul53
kann ich mal Probieren, aber auch das manuelle Ändern geht nicht in der selben Millisekunde.
Der Zeitunterschied war früher noch größer und hat geklappt

Soweit ich das noch von Homematic weiß wird eine geänderte RAMP_Time erst im nächsten LEVEL_Telegramm mitgeschickt.

[Homoran]

Neue Info:
Habe eben nochmal manuell die RAMP_TIME gesetzt und anschließend den LEVEL verändert.
Habe zwar nicht gestoppt ob die Rampe 90 Sekunden dauerte, aber es lief seeehr langsam.

Aber: Der Wert (90) blieb jetzt auch rot

@foxriver76
wie sehe ich, ob der Wert in der CCU übernommen wird?
Das ist kein "Bedienwert", kann ausschließlich über Programme gesetzt werden.

[Homoran]

Nächster Schritt:
Ich habe jetzt das folgende Scriptfragment auf meiner neuesten Testumgebung laufen gelassen:

Da hat es geklappt.
(Der Wert der RAMP_Time bleibt hier auch auf rot)

Auf der Produktiven läuft noch der Controller 1.5.4 - hier der 2.1.1
Alle anderen Versionen sind gleich (aktuelles stable)

[paul53]

@Homoran sagte:

Aber: Der Wert (90) blieb jetzt auch rot

Nicht alle Datenpunkte werden durch die CCU bestätigt. Bei MANU_MODE z.B. erfolgt die Bestätigung durch Übernahme des Wertes in SET_TEMPERATURE.

[Homoran]

und jetzt wird es richtig strange:
Ich habe die Skriptschnipsel auf die produktive Installation kopiert und da läuft es auch

[Homoran]

@paul53 das könnte hier auch gut passen, da dieser Wert ja nicht sofort von der CCU übernommen wird, sondern erst mit dem nächsten LEVEL-Telegramm geschickt wird

[paul53]

@Homoran sagte:

Skriptschnipsel auf die produktive Installation kopiert und da läuft es auch

Auch dann, wenn steuere LEVEL um 20 s verzögert wird ?

[foxriver76]

@Homoran sagte in CCU übernimmt hm-rpc State per Skript nicht:

Aber: Der Wert (90) blieb jetzt auch rot

@foxriver76
wie sehe ich, ob der Wert in der CCU übernommen wird?
Das ist kein "Bedienwert", kann ausschließlich über Programme gesetzt werden.

Mit nem Skript auf der CCU wie es zb der Rega Adapter bei Neustart ausführt. Da werden die Werte alle ausgelesen. Bzw als Einzeiler sowas (ungetestet):

WriteLine(dom.GetObject("idDeinesDps").Value())

[Homoran]

@paul53 sagte in CCU übernimmt hm-rpc State per Skript nicht:

@Homoran sagte:

Skriptschnipsel auf die produktive Installation kopiert und da läuft es auch

Auch dann, wenn steuere LEVEL um 20 s verzögert wird ?

gerade auch das getestet: ja!

[Homoran]

@foxriver76
Da merke ich erst wie lange ich aus der CCU-Programmierung raus bin

Ich habe es hiermit versucht:

m = (dom.GetObject("JEQ0201654:1.RAMP_TIME").Value());
dom.GetObject("Rampenzeit").State(m);

um es direkt in eine Systemvariable zu schreiben, aber das auslesen des Datenpunktes scheint schon nicht zu klappen.

Kannst du mir sagen ob die Schreibweise des DP korrekt ist?

Dann kann ich weiter suchen.

EDIT:
ich fürchte das wird nichts :

Parameter RAMP_TIME
Typ: float
Zugriffsart:  schreibend
Minimaler Wert: 0.0
Maximaler Wert: 85825945.6
Standardwert: 0.5
Einheit: s

der kann gar nicht ausgelesen werden

[paul53]

@Homoran sagte:

gerade auch das getestet: ja!

Dann wird wohl irgendetwas innerhalb der 20 s Differenz im Blockly dazwischen funken. Zeichne mal beide Datenpunkte per History auf (alles aufzeichnen).

[Homoran]

@paul53 sagte in CCU übernimmt hm-rpc State per Skript nicht:

Zeichne mal beide Datenpunkte per History auf

Das habe ich deswegen schon eingeleitet. ;-)

Außerdem habe ich statt der Verzögerung ein 90 Sekunden Timeout genommen.
Mal sehen was daraus wird.
Weiß allerdings nicht wann ich das testen darf

Ich kenne es ja von der CCU, dass man Programme einfach neu schreiben muss, wenn man zu oft darin editiert hat. Aber bei ioBroker sollte das wohl nicht passieren.

Habe inzwischen nämlcih schon an allen möglichen Enden versucht zu schrauben.
Meine heutige Version sieht jetzt so aus:

Spoiler

var First_End, First_Start, timeout3, timeout, timeout2;


First_End = false;
First_Start = false;
on({id: "hm-rpc.0.JEQ0047574.1.DIRECTION"/*Leinwand:1.DIRECTION*/, change: "ne"}, function (obj) {
  var value = obj.state.val;
  var oldValue = obj.oldState.val;
  // Überprüfen, wie der Trigger ist
  console.log(('Die Direction ist: ' + String(getState("hm-rpc.0.JEQ0047574.1.DIRECTION").val)));
  if (getState("hm-rpc.0.JEQ0047574.1.DIRECTION").val == 2 && First_Start == false) {
    // Fernbedienung hinter Leinwand herausholen ;-)
    First_Start = true;
    // Harmony-Hub Activity
    setState("Systemvariablen.0.Rollladensteuerung.Kino_aktiv"/*Kino_aktiv*/, true, true);
    setState("harmony.0.Stube.activities.Kino_BluRay"/*activity:Kino_BluRay*/, 2);
    // Blu-Ray einlegen
    setStateDelayed("harmony.0.Stube.Sony-DVD-Player.Eject"/*Sony-DVD-Player:Eject*/, 1, 15000, false);
    // AV-Receiver - Monitor-Out auf Beamer stellen
    setStateDelayed("denon.0.settings.outputMonitor"/*Output monitor*/, 2, 45000, false);
    // Alle betroffenen Rollläden runter
    setState("hm-rpc.0.JEQ0112436.1.LEVEL"/*Rolladen_Stubentuer:1.LEVEL*/, 0);
    setState("hm-rpc.0.JEQ0112564.1.LEVEL"/*Rolladen Stubenfenster:1.LEVEL*/, 0);
    setState("hm-rpc.0.JEQ0114266.1.LEVEL"/*Rolladen_Kueche:1.LEVEL*/, 0);
    // Alle Lichter bis auf eins aus
    setState("hm-rpc.0.JEQ0201654.1.LEVEL"/*Licht_Stube_Kranz:1.LEVEL*/, 60);
    setState("hm-rpc.0.JEQ0202324.1.LEVEL"/*Licht_Stube_Decke:1.LEVEL*/, 0);
    setState("hm-rpc.0.JEQ0202330.1.LEVEL"/*Licht_Esszimmer.LEVEL*/, 0);
    // restliches Licht langsam runterdimmen
    timeout = setTimeout(function () {
      setState("hm-rpc.0.JEQ0201654.1.RAMP_TIME"/*Licht_Stube_Kranz:1.RAMP_TIME*/, 60);
      setState("hm-rpc.0.JEQ0201654.1.LEVEL"/*Licht_Stube_Kranz:1.LEVEL*/, 0);
    }, 90000);
    // Steh- und Tischlampe aus
    setStateDelayed("hm-rpc.0.LEQ0242145.1.STATE"/*Steckdose_Stube_hinten_rechts:1.STATE*/, false, 12000, false);
    setStateDelayed("hm-rpc.0.LEQ0242152.1.STATE"/*Steckdose_Stube_hinten_links:1.STATE*/, false, 10000, false);
    timeout2 = setTimeout(function () {
      First_Start = false;
    }, 120000);
    // Wenn Leinwand wieder hoch
  } else if (getState("hm-rpc.0.JEQ0047574.1.DIRECTION").val == 1 && First_Start == false && First_End == false) {
    // Licht an
    setState("hm-rpc.0.JEQ0201654.1.LEVEL"/*Licht_Stube_Kranz:1.LEVEL*/, 60);
    First_End = true;
    // AV-Ausgang wieder auf "Auto"
    setStateDelayed("denon.0.settings.outputMonitor"/*Output monitor*/, 0, 200, false);
    // Bluray auswerfen
    setStateDelayed("harmony.0.Stube.Sony-DVD-Player.Eject"/*Sony-DVD-Player:Eject*/, 1, 2000, false);
    // AV-Lautstärke wieder auf "eher leise"
    setStateDelayed("denon.0.zoneMain.volume"/*Main Volume*/, 45, 100, false);
    // Harmony Acivity beenden
    setStateDelayed("harmony.0.Stube.activities.currentStatus"/*activity:currentStatus*/, 0, 8000, false);
    // Beamer separat aus klappt in Acivity nicht immer
    setStateDelayed("harmony.0.Stube.Epson-Projektor.PowerOff"/*Epson-Projektor:PowerOff*/, 1, 5000, false);
    setState("Systemvariablen.0.Rollladensteuerung.Kino_aktiv"/*Kino_aktiv*/, false, true);
    // Wenn es noch Tag ist wieder die Rolläden hoch
    if (getState("hm-rega.0.17606").val == 1) {
      setState("hm-rpc.0.JEQ0114266.1.LEVEL"/*Rolladen_Kueche:1.LEVEL*/, 100);
      setState("hm-rpc.0.JEQ0112436.1.LEVEL"/*Rolladen_Stubentuer:1.LEVEL*/, 100);
      setState("hm-rpc.0.JEQ0112564.1.LEVEL"/*Rolladen Stubenfenster:1.LEVEL*/, 100);
    }
    timeout3 = setTimeout(function () {
      First_End = false;
    }, 300000);
  }
});

Vielleicht siehst du ja noch etwas. (Wenn du magst)

[Homoran]

Heute abend hat es geklappt!

Gut - wieder drei Schritte auf einmal gemacht.
Abgesehen von den zwei Änderungen im Skript (statt Verzögerung ein Timeout und die Reihenfolge der Befehle geändert) hatte ich wegen des anderen Threads (siehe link im 1. Post) auch vorher manuell die RAMP-Time auf 90 gesetzt und per Programm auf 60.
Grund: In dem anderen Thread funktionierte das Setzen der Behanghöhe auch nur nach unten, nicht nach oben.

jetzt steht dieser State auf 60 und wird beim nächsten Mal auf 90 gesetzt.
Mal sehen wie das wird.

Das log hat nicht allzuviel gezeigt. der Wert des Timestamps der Helligkeiten beim runterdimmen:

0	true		2019-12-30 17:47:21.611	
25.5	true		2019-12-30 17:47:18.360	
59.5	true		2019-12-30 17:46:44.707	
60	true		2019-12-30 17:45:27.024	
60	true		2019-12-30 17:45:23.822	
60	true		2019-12-30 17:45:17.922

(die 60 stammt aus dem Schritt vor dem 90 Sekunden Timeout!)

und des Setzens der RAMP_TIME unmittelbar davor

60	false		2019-12-30 17:46:44.538

da ich diesmal ohne Verzögerung gearbeitet habe

Danke erst einmal an eure Hilfe.