Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20)

[dslraser]

@Mic sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):

Was wäre denn die Lösung für eure Hardware, im Adapter auch 'false' abfangen?

Also sobald "false", dann startet der Timer?

Eigentlich sollte das für alle Arten von Bewegungsmeldern funktionieren und fände ich auch "logischer".

Da Dein Adapter ja mit möglichst jeder Hardware funktionieren soll (und es gibt z.B. fast 12.000 rpc (HM oder HMIP) Installationen, wird die Frage bestimmt wieder kommen.

Im Moment gibt es als Auslöser (Bewegungsmelder) und andere Auslöser und zusätzliche Bedingungen. Das ist auch okay.
Wenn es keine Reaktion auf false vom BWM im Adapter gibt, dann sollte das besser "Einschalter" anstatt Bewegungsmelder heissen, und andere Auslöser könnten Ein/-Ausschalter sein/heissen.

[rudiraz]

@Mic
@dslraser

Ich bin etwas verwirrt, da auch ich einen HmIP-SMO besitze.
Wenn man aber hier die Zeit von "Zeit, nach der erkannte Bewegung zuückgesetzt wird" runter nimmt und in der Instanz die Zeit beim Bewegungsmelder setzt (bsp 45 Sek) dann Leuchtet die Lampe doch sowieso nicht Länger als diese Zeit (hier 45Sek) plus die Zeit, die im Homematic steht. Oder?

Dann wäre das doch geregelt oder nicht

[dslraser]

@rudiraz
wenn Du im Raum bleibst und Dich bewegst, dann wechselt der BWM nicht erneut von false auf true, sondern er bleibt die ganze Zeit true. Der Adapter würde dann aber trotzdem das Licht (oder was auch immer) nach der im Adapter eingestellten Zeit ausschalten. (weil der Timer vom Adapter bei einem true startet)

Kannst es ja gern ausprobieren, vielleicht habe ich ja auch einen Denkfehler...

Eigentlich macht ein Timer für mein Empfinden nur nach dem false Sinn. (dann ist es auch egal was im BWM eingestellt ist. Wenn während des Adapter Timer läuft wieder ein true vom BWM kommt, dann Timer stoppen und das ganze Spiel von vorn)

[rudiraz]

@dslraser
Achso, dann habe ich etwas falsch verstanden:

Ich dachte, der Sekundenwert startet sowieso erst bei False und solange True ist, wird der Timer erst gar nicht gestartet

Muss ich echt mal testen...

[dslraser]

@rudiraz
Mit bestimmten Einstellungen im BWM (vielleicht auch mit Deiner gezeigten) könnte es ja funktioneren, aber warum unnötig den BWM von false/true/false usw. wechseln lassen und Datenpunkte somit zu aktualisieren/ändern.

Und in Deinem Screenshot steht auch das Zauberwort.

keiner weiteren zwischendurch erkannten Bewegung
(wenn also der Bewegungsmelder während dieser Zeit nicht von true auf false und wieder zurück auf true wechselt, dann gibt es keine erneute Bewegung und es wird ausgeschaltet, obwohl der BWM vielleicht noch immer true ist)

[rudiraz]

@dslraser

Ok hab getestet und gebe dir Recht.
Der Timer sollte erst starten, wenn der BWM auf false geht und bei true der TImer wieder neu gesetzt werden.

War bei meiner Konfiguration momentan nicht der Fall

[Mic]

Zunächst mal noch ein Update

Version 0.2.2

• (Mic-M) New feature: In '3. TRIGGERS', 'Other Triggers', you can now easily create own states as triggers under 'smartcontrol.x.

Das bedeutet:

Ich habe beim Ablösen von Scripts durch diesen Adapter festgestellt, dass man eigene Datenpunkte zur Auslösung braucht (z.B. bei mir 0_userdata.0.Wohnzimmer.Heimkino.anschalten. Also müsste ich jetzt manuell noch zur Script-Ablösung Datenpunkte anlegen.
Der Adapter nimmt uns das nun ab:

Damit wird dann angelegt:

Mit diesem Datenpunkt kann dann entsprechend auch ausgelöst werden.

Details sind wie gewohnt in der Doku der Adapter-Optionen.

[Mic]

@crunchip @dslraser @rudiraz

Vielen Dank für euren Input
Mein Ziel ist natürlich, alle möglichen Bewegungsmelder abzubilden, insbesondere auch HomeMatic natürlich.

Was mich noch interessieren würde:
Wird der HomeMatic-Bewegungsmelder-Datenpunkt immer auf {val:true, ack:true} gesetzt, sobald dieser eine Bewegung registriert?
Ist es also so?

• 20:00:00 Bewegung -> State - {val:true, ack:true}
• 20:00:10 Bewegung -> State - {val:true, ack:true}
• 20:00:15 Bewegung -> State - {val:true, ack:true}
• 20:01:00 keine Bewegung mehr -> State - {val:false, ack:true}
• 20:01:03 Bewegung -> State - {val:true, ack:true}

Oder ist es so:

• 20:00:00 Bewegung -> State - {val:true, ack:true}
• 20:00:10 Bewegung -> State - nichts ändert sich
• 20:00:15 Bewegung -> State - nichts ändert sich
• 20:01:00 keine Bewegung mehr -> State - {val:false, ack:true}
• 20:01:03 Bewegung -> State - {val:true, ack:true}

Diese Info bräuchte ich noch, dann schaue ich mir das im Detail an.

[dslraser]

@Mic
ich mach morgen mal ein Debug Log, wenn Dir das reicht ?

[Mic]

@dslraser sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):

@Mic
ich mach morgen mal ein Debug Log, wenn Dir das reicht ?

Danke, aber ich fürchte das Log gibt das so nicht her.

Kannst du bitte mal folgendes testen:
Lass den Bewegungsmelder auslösen. Datenpunkt wird dann sicherlich {val:true, ack:true} machen.

Dann noch mal eine Bewegung, z.B. nach 30 Sekunden (je nach dem wie halt wohl der HM-BWM eingestellt ist auf Bewegungserkennung) - setzt er dann wieder {val:true, ack:true} ?

Das jeweilige Ergebnis siehst du in den Objekten, wenn du mit der Maus darüber gehst.
Im Beispiel ist val:false (=Wert: false) und ack:true (=Bestätigung: true)

Falls das viel zu umständlich: dann schreibe ich gerne ein JavaScript zum testen, dann bekommen wir das in der Log-Ausgabe
Ist ja auch vom Timing her tricky....

[dslraser]

@Mic
das wäre z.B. ein Präsenzmelder für Dein Test Script

hm-rpc.0.000C18A996B41F.1.PRESENCE_DETECTION_STATE

RAW

{
 "type": "state",
 "common": {
   "def": false,
   "type": "boolean",
   "read": true,
   "write": false,
   "name": "Präsenzmelder Küche.PRESENCE_DETECTION_STATE",
   "role": "sensor.motion"
 },
 "native": {
   "MIN": false,
   "OPERATIONS": 5,
   "MAX": true,
   "FLAGS": 1,
   "ID": "PRESENCE_DETECTION_STATE",
   "TYPE": "BOOL",
   "DEFAULT": false,
   "CONTROL": "MOTIONDETECTOR_TRANSCEIVER.MOTION_DETECTION_STATE"
 },
 "from": "system.adapter.hm-rega.0",
 "user": "system.user.admin",
 "ts": 1596734876061,
 "_id": "hm-rpc.0.000C18A996B41F.1.PRESENCE_DETECTION_STATE",
 "acl": {
   "object": 1636,
   "state": 1636,
   "owner": "system.user.admin",
   "ownerGroup": "system.group.administrator"
 }
}

So läuft dieser Präsenzmelder aktuell per Blockly

Hier die JS Ansicht vom Blockly

JS vom Blockly

on({id: new RegExp('hm-rpc\\.0\\.000C18A996B41F\\.1\\.PRESENCE_DETECTION_STATE' + "|" + 'hm-rpc\\.0\\.000C18A996B41F\\.1\\.PRESENCE_DETECTION_ACTIVE'), change: "ne"}, function (obj) {
   if (getState("hm-rpc.0.000C18A996B41F.1.PRESENCE_DETECTION_STATE").val && getState("hm-rpc.0.000BD5699D4868.1.ILLUMINATION").val <= getState("0_userdata.0.Helligkeit.Helligkeit_Grenzwert").val) {
   setState("hue.0.Küche.scene_orange"/*Scene orange*/, true);
 } else if (!getState("hm-rpc.0.000C18A996B41F.1.PRESENCE_DETECTION_STATE").val && getState("hm-rpc.0.000C18A996B41F.1.PRESENCE_DETECTION_ACTIVE").val) {
   setState("hue.0.Küche.command"/*Küche.command*/, '{"on":false,"transitiontime":100}');
 }
});

[Mic]

@dslraser
Danke, aber hat das jetzt mit der derzeitigen Problematik zu tun? Verstehe ich grad nicht
Präsenz-Melder-Datenpunkte sollten in die Tabelle "2. ZUSÄTZLICHE BEDINGUNGEN", also "wer anwesend", etc.

[dslraser]

@Mic
ähm, wie ?

Präsenzmelder ist auch ein "Bewegungsmelder", nur genauer. Oder was meinst Du ?
(Ich kann Dir aber auch einen Bewegungsmelder testen, das Prinzip ist das Gleiche)
Ich habe hier 18 Bewegungsmelder (innen und aussen am Haus---verschiedene Sorten von HMIP, aber das Prinzip ist bei Allen das Gleiche)

Diese hier hätte ich hier zum testen...

[Mic]

@dslraser
Ich habe die Vermutung wir schreiben aneinander vorbei
Die Homematic-Welt ist mir relativ fremd, auch wenn bei mir eine CCU2 in Betrieb ist wegen der Heizungsthermostate Aber ich komme nicht aus der Homematic-Ecke, im Gegensatz zu wohl einigen hier Daher auch meine Fragen...
Ich dachte bei "Präsenzmelder" an "ist wer anwesend: ja/nein"...

Wie gesagt, für mich für den Adapter wäre noch wichtig zu wissen, wie das Verhalten bezüglich {val:true, ack:true} bei Bewegung ist.

[dslraser]

@Mic sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):

Wie gesagt, für mich für den Adapter wäre noch wichtig zu wissen, wie das Verhalten bezüglich {val:true, ack:true} bei Bewegung ist.

Du hast ein Testscript dafür angeboten und ich habe Dir den Datenpunkt des Bewegungsmelders/Präsenzmelders für das Testscript hier rein geschrieben

Ich dachte bei "Präsenzmelder" an "ist wer anwesend: ja/nein"...

Das ist quasi ein Bewegungsmelder, der nur noch feiner reagiert (tippen auf der Tastatur reicht für die Bewegungserkennung schon aus)

[Mic]

@dslraser
Sehe ich mir gerne die Tage an.

Eine große Bitte: Du scheinst nach dem posten hier im Nachhinein Änderungen an deinen Beiträgen zu machen, das ist gut so aber macht es mir sehr schwer zu folgen.
Bitte daher am besten Beitrags-Änderungen irgendwie kennzeichnen.
Kommt sicherlich daher, weil wir jetzt grad simultan geschrieben haben, aber macht mir das ganze nicht einfacher, wenn dann plötzlich darüber noch Screenshots, Infos, etc. folgen, nachdem ich schon darunter genatwortet habe oder dabei bin. Und damit stehe ich irgendwie auch "doof" da mit meiner Antwort, wenn darüber danach aktualisiert wird.

Daher Updates am besten als neuen Beitrag oder sehr gut gekennzeichnet.
Danke

[dslraser]

@Mic sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):

Daher Updates am besten als neuen Beitrag oder sehr gut gekennzeichnet.
Danke

okay.
(ich habe eben einiges am Handy geschrieben, da ist das zitieren nicht ganz so leicht, weil ich dann Dein geschriebenes nicht sehe, es sei denn, ich zitiere den ganzen Beitrag (Vollzitat), was auch nicht gewünscht ist im Forum)

[Christoph1337]

@Mic said in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):

Was wäre denn die Lösung für eure Hardware, im Adapter auch 'false' abfangen? Also sobald "false", dann startet der Timer?

Hey @Mic,

danke für die Antwort.

Genau der PIR ist der Bewegungsmelder.

Ich denke eigentlich dürfte sich ja jeder Bewegungsmelder so verhalten. Wenn durchgängig Bewegung (Party und alle tanzen). Dann bleibt der Wert durchgängig auf TRUE.

In meinem Aktuellen Script läuft der Timer erst los, wenn der Wert zurück auf FALSE fällt und wird gestoppt, wenn er wieder TRUE wird.

Beste Grüße

[rudiraz]

@Mic sagte in Test Adapter SmartControl 0.2.x GitHub (ab 18.08.20):

Was wäre denn die Lösung für eure Hardware, im Adapter auch 'false' abfangen? Also sobald "false", dann startet der Timer?

Ich glaube, damit würden dann so gut wie alle Bewegungsmelder funktionieren

[BoehserWolf]

@dslraser Hätte mal ne kurze Offtopic Frage: Wie schaffst du es mit so vielen BWM und Präsenzmeldern den DutyCycle im Griff zu behalten? Bei mir machen 2 BWM, je nach Durchgangshäufigkeit, ca. 10% DC + aus.
Evtl. könntest du deine Empfehlungen in einem anderen Thread zur Verfügung stellen?
Danke