HmIP-BSM - nicht per Programm in CCU2

[coolsurfer]

Hallo,

ich habe heute an eq-3 folgenden Fehler berichtet. Kann das von Euch mal jemand nachvollziehen ob es bei Euch auch so ist, oder ob meine CCU2 nen Hau weg hat.

Einfach ein HMIP-BSM als WENN Bedingung (Kanal 4). Dann ein DANN (geloggte Variable "EIN") SONST (geloggte VARIABLE "AUS")

bedauerlicherweise hat die Version 2.25.15 der CCU2 einen Fehler bezüglich der Programme. Ich habe einen HmIP-BSM (Version 1.4) eingebunden und ein Programm, welches den Kanal 4 auf "Schaltzustand: EIN" überwacht (hier ise_id 39447:1 (Parent ist 39443 - siehe unten). Das Programm wird bei jedem Schalten des Tasters (Channel 4) aufgerufen, jedoch ist der aufrufende nicht die obige ise_id sondern das erste Child mit der ise_id 39445 wodurch die entsprechenden Prüfungen immer fehlschlagen und das Programm niemals im SONST Zweig landet.

Wenn Geräteauswahl "SCHALTER" bei "Schaltzustand: EIN" "bei Aktualisierung auslösen" (das letzte nur ein Test, normalerweise Änderung)

gestartet/getriggert wird das Programm dann aber bei einem Tastendruck mit HmIP-RF.000855xxxxxxxx:4.PROCESS = 0

Der Unterschied zwischen Homematic und Homematic IP Geräten ist vermutlich der, dass bei Homematic STATE und LEVEL immer das erste Child sind. Bei Homematic IP jedoch nicht, so dass vermutlich der Trigger auf den falschen ChildIndex zugreift.

<channel name="SCHALTER" ise_id="39443" visible="true" operate="true">
<datapoint name="HmIP-RF.000855xxxxxxxx:4.PROCESS" type="PROCESS" ise_id="39445" value="0" valuetype="16" valueunit="" timestamp="1485157571" operations="5"/>
<datapoint name="HmIP-RF.000855xxxxxxxx:4.SECTION" type="SECTION" ise_id="39446" value="0" valuetype="16" valueunit="" timestamp="1485157571" operations="5"/>
<datapoint name="HmIP-RF.000855xxxxxxxx:4.STATE" type="STATE" ise_id="39447" value="false" valuetype="2" valueunit="" timestamp="1485157571" operations="7"/>
</channel>

[HMside]

Schonmal so probiert?

Wenn Aktor ein
Dann Variable true
Sonst Wenn Aktor aus
Dann Variable false

Alternativ mal mit dem Kanal 3 (Statusmitteilung Relais) Probieren.

[Gluehwurm]

Dürfte ein ähnliches Problem sein, wie hier
http://homematic-forum.de/forum/viewtop ... 19&t=35140

Gruß
Bruno

[coolsurfer]

Schonmal so probiert?

Wenn Aktor ein
Dann Variable true
Sonst Wenn Aktor aus
Dann Variable false

Alternativ mal mit dem Kanal 3 (Statusmitteilung Relais) Probieren.

Klar, habe auch nur geloggt, ohne das was passiert ist. Kanal 4 reagiert auf Änderung überhaupt nicht, und auf Aktualisieren regelmäßig aber eben nur mit dem WENN Zweig (immer).
Kanal 3 geht, aber der geht leider zu oft Wenn ein bisschen Stromschwankungen sind (oder was auch immer) dann sendet der kurz EIN und direkt danach wieder AUS, das nervt auf Dauer.

Unfreiwillige Disko an der zweiten Lampe

[HMside]

@coolsurfer

ich habe es gerade mal bei meinem Aktor mit FW 1.4 getestet und folgendermaßen funktioniert es bei mir.

Wenn -> Aktor Kanal 3 AUS -> bei Änderung
Dann -> Skript -> Push Aktor ist AUS
Sonst Wenn -> Aktor Kanal 3 EIN -> bei Änderung
Dann -> Skript -> Push Aktor ist EIN

drehe ich das ganze um, also oben EIN und unter aus, geht es nicht. Nehme ich den Kanal 4 wird die Push Nachricht häufig mehrfach gesendet.

EDIT:
Das folgende Programm läuft aus welchen Gründen auch immer nicht, obwohl der Status sauber bei der CCU ankommt und sogar der Zeitstempel des Programms aktualisiert, wird die Aktivität nicht ausgeführt. Ich werde das verhalten morgen mal eQ-3 melden.

Wenn -> Aktor Kanal 3 EIN -> bei Änderung
und Systemzustand Anwesend nur prüfen
Dann -> Skript -> Push Aktor ist EIN

EDIT 2:
Erstellt man ein Programm mit einem null pointer, also ohne eine Aktion in der ersten Aktivität, dann arbeitet das Programm. Es müssen somit scheinbar immer beide Zustände im Programm stehen und AUS muss zwingen oben stehen. Very confusing stuff

Wenn -> Aktor Kanal 3 AUS -> bei Änderung
Dann -> bleibt leer
Sonst Wenn -> Aktor Kanal 3 EIN -> bei Änderung
Dann -> Skript -> Push Aktor ist EIN

[coolsurfer]

Und jetzt versuch das ganze nochmal mit Kanal 4 - da erlebst du noch mehr Wunder

Wenn du $src$ und $val$ loggst, dann siehst du auch dass der Trigger des Programmes eben nicht STATE sondern PROCESS ist
(ein ganz anderer Knotenpunkt, der eigentlich gar nichts zur Verfügung steht und auch nicht von Bedeutung ist an der Stelle).

Ich hab das ganze jetzt erstmal mittels "bei Aktualisierung" gelöst und prüfe dann alles in einem eigenen Skript. Dort sind die
Werte dann richtig. Ich denke hier hat jemand bei der CCU den Array-Zähler durcheinander gebracht (das soll aber eq-3 klären)

Richtig toll wird es, wenn du auf dem Aktor bei Channel 3 die Verzögerungszeit von 1 Sekunde (Standard) auf "keine" setzt.
Dann hast du nen Verhalten, was wohl kaum irgendwie reproduzierbar ist... Dann schaltet sich das Ding ständig selbst an und
aus und schickt Zustände, die mit dem realen Zustand nicht mehr zu tun haben...

[zautrix]

Darf ich mal fragen, was ihr mit

Wenn -> Aktor Kanal 3 AUS -> bei Änderung
Dann -> Skript -> Push Aktor ist AUS
Sonst Wenn -> Aktor Kanal 3 EIN -> bei Änderung
Dann -> Skript -> Push Aktor ist EIN

vorhabt?

Der Kanal 3 ist ja entweder AUS oder EIN.
Also triggert jedes Umschalten ein
"AUS" geändert und ein "EIN geändert".

Das obige Programm müßte also zweimal hintereinander aufgerufen werden, wenn das System richtig funktioniert.

Ich habe bei mir grundsätzlich in meinen Programmen mit dem BSM
am Anfang ein
Wenn -> Aktor Kanal 3 AUS -> bei Änderung
Dann -> xyz
Sonst Wenn -> Aktor Kanal 3 EIN -> nur prüfen
Dann -> abc

zu stehen und keinerlei Probleme.

[coolsurfer]

Darf ich mal fragen, was ihr mit [...] vorhabt?

"Push Aktor" ist ein ANDERER Aktor, nicht der dessen Kanal 3 / 4 wir abfragen.
Und ja ich habe festgestellt, wenn man das Programm mit "beim Einschalten" anlegt funktioniert es nicht. Geht man in das Programm ändert von EIN auf AUS geht es, ändert man es wieder zurück geht es auch. Es scheint also nur ein Problem beim ERSTEN abspeichern eines neuen Programmes zu sein Da muss man auch erstmal drauf kommen. <ironie> Evtl. sind die HmIP Entwickler so unerfahren mit den Programmen, dass sie die mindestens zweimal ändern müssen und haben den Fehler deswegen nie gemerkt </ironie>