NEWS
CCU übernimmt hm-rpc State per Skript nicht
-
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!
-
@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.@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 nochmalEDIT: hoffe es passt jetzt
-
Und hier noch der Ausschnitt des Blockly:

"Nach Zahl" war noch ein hilfloser Versuch - könnte wieder raus
-
Und hier noch der Ausschnitt des Blockly:

"Nach Zahl" war noch ein hilfloser Versuch - könnte wieder raus
-
Und hier noch der Ausschnitt des Blockly:

"Nach Zahl" war noch ein hilfloser Versuch - könnte wieder raus
-
@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 geklapptSoweit ich das noch von Homematic weiß wird eine geänderte RAMP_Time erst im nächsten LEVEL_Telegramm mitgeschickt.
-
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. -
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) -
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. -
und jetzt wird es richtig strange:
Ich habe die Skriptschnipsel auf die produktive Installation kopiert und da läuft es auch -
@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.
@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
-
und jetzt wird es richtig strange:
Ich habe die Skriptschnipsel auf die produktive Installation kopiert und da läuft es auch -
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 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 sagte:
Skriptschnipsel auf die produktive Installation kopiert und da läuft es auch
Auch dann, wenn steuere LEVEL um 20 s verzögert wird ?
@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 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())@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: sder kann gar nicht ausgelesen werden
-
@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 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).
@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 darfIch 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:
Vielleicht siehst du ja noch etwas. (Wenn du magst)
-
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.538da ich diesmal ohne Verzögerung gearbeitet habe

Danke erst einmal an eure Hilfe.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden