on({id: 'dp.OPEN', change: 'any'}, obj => { log(JSON.stringify(obj)); });

ok, danke, schon mal eingespielt, nun nur noch warten bis es wieder passiert

on({id: 'dp.OPEN', change: 'any'}, obj => {
        log(JSON.stringify(obj));
});

Das als JavaScript im Skript Engine Adapter anlegen, die id natürlich austauschen. Dann sollte bei jeder Aktualisierung/Änderung das komplette Objekt geloggt werden. Alternativ könntest du auch mit einem der history Adapter den DP aufzeichnen und dann schauen wenn sich die Tür vom Geisterhand geöffnet hat ob der Wert zu dem Zeitpunkt geändert wurde. Hatte vor einiger Zeit mal ein ähnliches Phänomen, habe dann meine Keymatic neu kalibriert mach folgender Anleitung, seitdem nie wieder aufgetreten.. war trotzdem bedenklich.. aber gibt noch zusätzliche Sicherheitsmaßnahmen ;-)

Kannst Du mir kurz schildern wie Du das genau meinst mit dem trigger und obj.from?

Klingt nach einen JS ein on... und dann schreibt das weg woher der trigger kommt?

Danke
Gruß Jens

Nachdem du auch bislang der einzige bist der etwas derartiges meldet, habe ich aktuell nicht den Adapter unter Verdacht.

ich würde das Thema gern noch mal aufnehmen, da ich in letzter Zeit wieder des Öfteren
Geisteröffnungen der Haustür hatte.

da ich nicht wirklich die Ursache feststellen kann und es sehr danach aussieht, dass ioBroker
den Datenpunkt nur aktualisiert, sprich es wurde kein konkreter Befehl ausgeführt den Datenpunkt
auf true zu setzen.

Wäre es möglich, dass Du das im Adapter verhinderst, auch wenn die API das so nicht vorsieht?

Also das nur beim Wechsel von false auf true des Datenpunktes der Befehl über die API zur CCU
gesendet wird?
Und evtl. der Datenpunkt dann wieder auf false geht?

Wäre Super, da ich echt keine Ahnung habe wie ich das verhindern kann, dass die CCU einfach
die Tür öffnet.

Danke
Gruß Jens

Da wäre jetzt nur die Frage ob OPEN true im verschlossenen Zustand ach vorher aufschließt- Ich habe mit der Keymatik schon lange nicht mehr gearbeitet, denke aber dass je nach Zustand der Datenpunkte bestimmte Winkel angefahren werden.

Kann es allerdings aktuell nicht validieren, da ich hier ausm WLAN kein VPN mit meinem neuen DynDNS aufgebaut bekomme .

Ist jetzt auch eher Off-Topic für hier.

Über die API ist es wie gesagt keine Liste.

Du hast anscheinend recht!

Habe gerade nochmal ein ALTES Programmierhandbuch angesehen (Neues zum Dowload nicht gefunden):

Auch habe ich gestern frisch die Meta-Daten eingepflegt von meiner HM-Sec-Key-S.KEYMATIC, respektive:

            'OPEN': {
                'CONTROL': 'LOCK.OPEN',
                'DEFAULT': false,
                'FLAGS': 1,
                'ID': 'OPEN',
                'MAX': true,
                'MIN': false,
                'OPERATIONS': 2,
                'TAB_ORDER': 1,
                'TYPE': 'ACTION',
                'UNIT': ''
            },

            'STATE': {
                'CONTROL': 'LOCK.STATE',
                'DEFAULT': false,
                'FLAGS': 1,
                'ID': 'STATE',
                'MAX': true,
                'MIN': false,
                'OPERATIONS': 7,
                'TAB_ORDER': 0,
                'TYPE': 'BOOL',
                'UNIT': ''
            },

Man kann sich gerne bei Eq3 über die Unterschiede zw. Web-Ui und API beschweren, finde es allerdings nicht so tragisch.

n der HM Oberfläche selbst -- keine Ahnung

Darum gehts ja - da ist es Werteliste (war es zumindest früher)

Nagel mich jetzt nicht auf die Zuordnung 0-1-2 fest aber so in etwa

Value Lists liefert die API so:

'CONTROL_MODE': {
                'CONTROL': 'HEATING_CONTROL.CONTROL_MODE',
                'DEFAULT': 0,
                'FLAGS': 1,
                'ID': 'CONTROL_MODE',
                'MAX': 3,
                'MIN': 0,
                'OPERATIONS': 5,
                'TAB_ORDER': 0,
                'TYPE': 'ENUM',
                'UNIT': '',
                'VALUE_LIST': [
                    'AUTO-MODE',
                    'MANU-MODE',
                    'PARTY-MODE',
                    'BOOST-MODE'
                ]
}

Siehe TYPE: 'ENUM'

{
  "type": "state",
  "common": {
    "def": false,
    "type": "boolean",
    "read": true,
    "write": true,
    "role": "switch.lock",
    "name": "Schloss_Haustuer:1.STATE"
  },
  "native": {
    "CONTROL": "LOCK.STATE",
    "DEFAULT": false,
    "FLAGS": 1,
    "ID": "STATE",
    "MAX": true,
    "MIN": false,
    "OPERATIONS": 7,
    "TAB_ORDER": 0,
    "TYPE": "BOOL",
    "UNIT": "",
    "LOCK_VALUE": false
  },
  "from": "system.adapter.hm-rpc.0",
  "ts": 1564216379593,
  "_id": "hm-rpc.0.JEQ0466320.1.STATE",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Muss das nicht angepasst werden?

IMHO müsste der Typ von State eine Werteliste mit 3 Zuständen sein.
verriegelt - entriegelt - öffnen

ich habe gesehen, dass Du die letzten Updates zum hm-rpc erstellt hast, daher die Frage an
dich, kann es sein, dass da im Adapter etwas nicht richtig läuft zu meinem Problem?

Wäre mir ziemlich wichtig, da ich ab und an einfach mal eine offene Tür habe und bislang
noch keine wirklich Ursache gefunden habe.
Somit bleibt mir nur so ran zu gehen, alles mögliche auszuschließen was es nicht die Ursache ist.

Wenn es ganz blöde läuft ist es ein keymatic Problem, aber zumindest könnte ich mich dann an
ELV wenden...

Könntest Du da bitte mal schauen, ob es am adapter liegt das der Datenpunkt OPEN egal ob setzen, nicht setzen
False, True, ändern oder nicht die Tür öffnet....

Danke
Gruß Jens