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

[AingTii]

@Knallochse
dass ist nett, danke Dir

[Knallochse]

Hier mal das github Issues zum nachlesen:
https://github.com/ioBroker/ioBroker.hm-rpc/issues/210

[Knallochse]

@foxriver76 hat schon eine Änderung im rpc Adapter vorgenommen.
Es wurde der OPEN Datenpunkt von Taster auf Schalter geändert, so das jetzt nur noch true die Aktion „öffnen“ auslösen sollte.

[foxriver76]

@Knallochse Jein, der State wurde in einen Button geändert. Wie man einen Button in einem Skript anspricht muesste allerdings egal sein. Allerdings wird er im Admin, insofern Expertenmodus deaktiviert ist nun als Knopf angezeigt und sollte so nicht mehr die oben genannte Verwirrung stiften.

[Homoran]

@foxriver76
Aber der Datenpunkt STATE ist in HM doch eine Werteliste 0,1,2 und in ioB ein boolean:

{
  "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?

[foxriver76]

@Homoran Also laut API ist es ein Bool wie ja auch in den von dir geposteten Daten zu sehen. In der HM Oberfläche selbst -- keine Ahnung ;-)

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'

[Homoran]

@foxriver76 sagte in Bug? Adapter hm-rpc - Keymatic OPEN Problem:

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

[foxriver76]

@Homoran Dann macht die CCU da aber irgendwelche Späße intern. Über die API ist es wie gesagt keine Liste. Kann mir auch nicht vorstellen, dass es in ioB jemals eine war. Ich habe diesbezüglich nix geändert.

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.

[Homoran]

@foxriver76 sagte in Bug? Adapter hm-rpc - Keymatic OPEN Problem:

Ü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):

[foxriver76]

@Homoran Allerdings kommt mir beim drüberschauen über die Metas, dass TYPE: 'ACTION' evtl immer einen Button darstellen müsste. Sprich es keinen Unterschied macht ob man true oder false in den Dp schreibt.

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.

[Homoran]

Dann müsste man also -korrekte Einrichtung der Keymatic vorausgesetzt- über den Datenpunkt STATE verschließen <-> aufschließen und mit dem Datenpunkt OPEN entriegeln.

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.

[foxriver76]

@Homoran Ja. Open öffnet 'immer' die Türe, egal ob verriegelt oder entriegelt.

[AingTii]

Also erst mal danke an Euch, dass Ihr da so schnelle reagiert und anpasst.

[AingTii]

@foxriver76 ,

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

[foxriver76]

@AingTii hi der Adapter ignoriert alles mit ack true gesetzte. Ich würde an deiner Stelle mal ein trigger auf den Open wert machen und schauen ob da überhaupt was passiert wenn sich die Tür von Geisterhand öffnet. Der Adapter macht wie gesagt nichts ohne dass der DP geändert wird. Hm-Rega schreibt die DPs immer mit ack weshalb dass auch keine Ursache sein kann. Am besten mal trigger drauf und obj.from loggen falls es überhaupt von iob kommt..

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

[AingTii]

@foxriver76
ich habe schon extra alles was den Datenpunkt anspricht an scripte mit
log schreiben ausgestatet, sprich wenn irgendwas ausgeführt wird welche das Open setState
macht wird geloggt.
im Log war bislang noch nichts....

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

[foxriver76]

@AingTii

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 ;-)

[AingTii]

@foxriver76 sagte in Bug? Adapter hm-rpc - Keymatic OPEN Problem:

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

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