Weihnachtsangebot 2025! 🎄

[liv-in-sky]

@s-bormann

ich hätte da mal ein problem - bzw - verständnis frage

ich probiere mit iqontrol mit einem datenpunkt-werteliste zu arbeiten, also etwas auswählen und im script wird dann das gewählte verarbeitet, irgend wie verwirrt mich die definition

die werteliste, die du auf github beschreibst ist etwas anders aufgebaut als der offizielle werteliste-datenpunkt

wie kommen die beiden richtig zusammen - eigentlich sollte der wertelisten-datenpunkt vom type number sein - du verwendest aber strings

mein datenpunkt sieht so aus - der type ist hier string - habe aber auch number probiert (dann steht statt CODE01 nur 1 usw):

{
  "common": {
    "name": "Unifi Wifi Vouchers_ValueCodeList",
    "role": "state",
    "type": "string",
    "states": "CODE01:5d7fa5ab97578401a0612f6e;CODE02:5d7fa5ab97578401a0612f6b;",
    "read": true,
    "write": true
  },
  "native": {},
  "type": "state",
  "from": "system.adapter.javascript.2",
  "user": "system.user.admin",
  "ts": 1568645584287,
  "_id": "javascript.2.WLANUnifi.Wifi_Vouchers_ValueCodeList",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

wie müssen die states genau aussehen, damit eine werteliste in iqontrol kommt (meistens zeigt er nur einen wert an und es kommt keine valueliste) - hatte auch mal kurz erfolg, aber jetzt bekomme ich es nicht mehr hin

die states sind bei mir flexibel - ein script beschreibt die (obj.common.states = ...) - es können also auch mal 5 codes drinstehen oder weniger - wird das dann ge-updatet in iqontrol ?

könntest du mir bitte einen tipp gehen, was da bei meinem beispiel drinstehen muss (unter states) und ob diese bei veränderung auch in iqontrol verändert werden

nachtrag 17.9.19: konnte problem lösen - frage hat sich erledigt

• einfach standard werte für datenpunkt werteliste nutzen - dann funktioniert es - mußte beim erstellen des datenpunktes im script alle werte des datenpunktes mitangeben und auch die states gleich mit "dummy-values" besetzen

createState(dpPrefix + "WLANUnifi.Wifi_Vouchers_ValueCodeList", { name: 'Unifi Wifi Vouchers_ValueCodeList', desc:"ValueCodeList", role: "", type:'number', states: "1:please wait ...;2:refresh webpage", def:1, min: 0, max: 20,  read:  true,  write: true,});

[zahnheinrich]

@s-bormann
Ich habe einen kleinen Bug gefunden:
Ich habe eine zweite Instanz von iqontrol installiert, um diese mit identischen Kacheln zu betreiben, jedoch in anderer Sprache zu beschriften.
In den Einstellungen mit dem Schraubenschlüssel kann ich auch für die zweite Instanz neue Bezeichnungen eingeben, jedoch werden in der Kachel immer die Bezeichnungen der ersten Instanz gezeigt.
Könntest Du das ändern?
Vielen Dank für diesen tollen Adapter!!!

[zahnheinrich]

@s-bormann
Das Problem ist sogar etwas umfangreicher:
Sobald eine zweite Instanz von iqontrol läuft, kann ich die Value List in den Eigenschaften BEIDER Instanzen ncht mehr ändern.
Das geht erst wieder, nachdem ich die zweite Instanz gelöscht habe.

iqontrol Vers. 0.2.4
node 8.16

[s.bormann]

Hi, zur Info: bin ein paar Tage ohne PC. Melde mich, sobald ich wieder online bin.

[RichieXX]

Hallo.
Ab Version 0.2.2 werden bei meinen Devolo Z-wave Thermostaten keine Temparaturwerte mehr angezeigt und man kann auch keinen Setpoint setzen. Bis V 0.2.1 alles OK. Bin wieder zurück zur 0.2.1 und alles OK.

[zahnheinrich]

@s-bormann
Danke für die Info.
Keinen Stress!

[mucki]

@s-bormann

Könntest du vielleicht bei Gelegenheit mal schauen, ob du das Nuki Schloss einpflegen könntest?

Anbei mal das RAW von nuki2.0.door__garage.action:

{
  "from": "system.adapter.nuki2.0",
  "ts": XXXXXXXXXXXXXXX,
  "common": {
    "name": "Trigger an action on Garage",
    "role": "value",
    "type": "number",
    "nukiId": XXXXXXXXX,
    "write": true,
    "states": {
      "0": "NO_ACTION",
      "1": "UNLOCK",
      "2": "LOCK",
      "3": "UNLATCH",
      "4": "LOCK_N_GO",
      "5": "LOCK_N_GO_WITH_UNLATCH"
    },
    "custom": {
      "iqontrol.0": {
        "enabled": true,
        "readonly": false,
        "invert": false,
        "confirm": false,
        "unit": "",
        "unit_zero": "",
        "unit_one": "",
        "min": "",
        "max": "",
        "step": "",
        "type": "number",
        "role": "state",
        "targetValueId": "",
        "states": {
          "0": "NO_ACTION",
          "1": "UNLOCK",
          "2": "LOCK",
          "3": "UNLATCH",
          "4": "LOCK_N_GO",
          "5": "LOCK_N_GO_WITH_UNLATCH"
        }
      }
    }
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "nuki2.0.door__garage.action",
  "type": "state"
}

[Bluefox]

@mucki Ich sehe jetzt schon, dass nuki falsch implementiert ist.
nukiId darf nicht in common drin sein

[s.bormann]

@mucki sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann

Könntest du vielleicht bei Gelegenheit mal schauen, ob du das Nuki Schloss einpflegen könntest?

Anbei mal das RAW von nuki2.0.door__garage.action:

{
  "from": "system.adapter.nuki2.0",
  "ts": XXXXXXXXXXXXXXX,
  "common": {
    "name": "Trigger an action on Garage",
    "role": "value",
    "type": "number",
    "nukiId": XXXXXXXXX,
    "write": true,
    "states": {
      "0": "NO_ACTION",
      "1": "UNLOCK",
      "2": "LOCK",
      "3": "UNLATCH",
      "4": "LOCK_N_GO",
      "5": "LOCK_N_GO_WITH_UNLATCH"
    },
    "custom": {
      "iqontrol.0": {
        "enabled": true,
        "readonly": false,
        "invert": false,
        "confirm": false,
        "unit": "",
        "unit_zero": "",
        "unit_one": "",
        "min": "",
        "max": "",
        "step": "",
        "type": "number",
        "role": "state",
        "targetValueId": "",
        "states": {
          "0": "NO_ACTION",
          "1": "UNLOCK",
          "2": "LOCK",
          "3": "UNLATCH",
          "4": "LOCK_N_GO",
          "5": "LOCK_N_GO_WITH_UNLATCH"
        }
      }
    }
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "nuki2.0.door__garage.action",
  "type": "state"
}

@DocGame hat mir mal folgenden RAW zu Nuki geschickt:

{
  "common": {
    "name": "Current door-state of the Nuki",
    "role": "value",
    "type": "number",
    "write": false,
    "states": {
      "0": "UNAVAILABLE",
      "1": "DEACTIVATED",
      "2": "DOOR_CLOSED",
      "3": "DOOR_OPENED",
      "4": "DOOR_STATE_UNKNOWN",
      "5": "CALIBRATING"
    }
  },
  "type": "state",
  "native": {},
  "from": "system.adapter.nuki2.0",
  "user": "system.user.admin",
  "ts": 1563554429834,
  "_id": "nuki2.0.door__haustür.status.doorState",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Sehe ich es richtig, dass NUKI zwei unterschiedliche Datenpunkte für den aktuellen Zustand und Befehle verwendet?

VG

[s.bormann]

@RichieXX sagte in [Neuer Adapter] Visualisierung iQontrol:

Hallo.
Ab Version 0.2.2 werden bei meinen Devolo Z-wave Thermostaten keine Temparaturwerte mehr angezeigt und man kann auch keinen Setpoint setzen. Bis V 0.2.1 alles OK. Bin wieder zurück zur 0.2.1 und alles OK.

Hi,

bitte mit F12 Entwicklerkonsole im Browser starten und mir posten, was im Fenster "Console" angzeigt wird, wenn der Fehler entsteht.

Danke und VG!

[s.bormann]

@zahnheinrich sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann
Das Problem ist sogar etwas umfangreicher:
Sobald eine zweite Instanz von iqontrol läuft, kann ich die Value List in den Eigenschaften BEIDER Instanzen ncht mehr ändern.
Das geht erst wieder, nachdem ich die zweite Instanz gelöscht habe.

iqontrol Vers. 0.2.4
node 8.16

Hi,
bitte schick mal den RAW den Datenpunktes. Habe es bei mir gerade versucht und konnte den Fehler nicht reproduzieren. Kommt wohl nur in bestimmten Konstellationen vor.
Was ich noch nicht ganz verstanden habe: Ist der Fehler schon auf der Schraubenschlüssel-Seite (also kannst Du gar nichts einstellen? - dann bitte die Seite mit geöffneter Entwicklerkonsole öffnen (F12) und hier die Meldungen posten) oder erst im Frontend? (Dann bitte hier ebenfalls die Fehler der Entwicklerkonsole posten).
VG!

[s.bormann]

@luder sagte in [Neuer Adapter] Visualisierung iQontrol:

Ich teste gerade meine Firtzdect Thermostate einzubinden.

Wie bekommt ihr denn die Parameter MANUAL - AUTO - BOOST nebeneinader zur direkten Auswahl?
bei mir stehen die Untereinander

Hi,
das nebeneinander ist nur im Homematic-Thermostat so implementiert. Das normale Thermostat ist universeller gehalten, deshalb gibt es da die Auswahlliste.
LG

[s.bormann]

@dslraser sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann sagte in [Neuer Adapter] Visualisierung iQontrol:

@dslraser Versuch mal die Value-List mit dem Schraubenschlüssel so anzupassen, dass Du als 3. Eintrag "BOOST-MODE" hast, min = 0, max = 2. Geht es dann?

Wenn . ich das so mache, also die Value-List von Control_MODE von 0-2, dann wird BOOST angezeigt.

Aber es wird dann in den Objekten einfach bei CONTOL_MODE auf 2 geschaltet, was aber nichts auslöst.

Es müßte für BOOST aber BOOST_Mode auf true gesetzt werden.

Ich dachte auch, das dafür eigentlich der BOOST_STATE verantwortlich ist ?

Für BOOST_TIME gibt es ja auch einen Datenpunkt, der wird automatisch gestartet, wenn BOOST_MODE auf true gesetzt wird. Dieser wird aber bisher auch nicht angezeigt.

Hi,
hast Du das mit der 0.2.4 probiert? Sollte seit dieser Version eigentlich so funktionieren. Wenn nicht... F12 u.s.w., kennst Du ja :)
LG!

[zahnheinrich]

@s-bormann
Das Problem ist nur im Frontend. Die Änderungen sind im RAW normal änderbar und sichtbar, werden in der Anzeige jedoch nicht umgesetzt.
Hat wohl nichts damit zu tun, dass ich wired Komponenten benutze?
Hier ein RAW einer einfachen Lichtschaltung:

Spoiler

{
 "type": "state",
 "common": {
   "def": false,
   "type": "boolean",
   "read": true,
   "write": true,
   "role": "switch",
   "name": "LaufLicht.STATE",
   "custom": {
     "iqontrol.1": {
       "enabled": true,
       "readonly": false,
       "invert": false,
       "confirm": false,
       "unit": "",
       "unit_zero": "",
       "unit_one": "",
       "min": "",
       "max": "",
       "step": "",
       "type": "boolean",
       "role": "switch",
       "targetValueId": "",
       "states": {
         "true": "on",
         "false": "off"
       }
     }
   }
 },
 "native": {
   "CONTROL": "SWITCH.STATE",
   "DEFAULT": false,
   "FLAGS": 1,
   "ID": "STATE",
   "MAX": true,
   "MIN": false,
   "OPERATIONS": 7,
   "TAB_ORDER": 0,
   "TYPE": "BOOL",
   "UNIT": ""
 },
 "_id": "hm-rpc.1.MEQ0279124.15.STATE",
 "from": "system.adapter.hm-rpc.1",
 "ts": 1568982340756,
 "user": "system.user.admin",
 "acl": {
   "object": 1638,
   "state": 1638
 }
}

Edit: Kein Fehler in der Konsole F12

[zahnheinrich]

@s-bormann
Hab´s gerade nochmal nachgestellt:

Änderungen in der Ersten Instanz werden in der Anzeige übernommen, in der zweiten Instanz ignoriert.
Ausprobiert mit Änderung der Schaltbezeichnungen EIN/AUS in ON/OFF.

[RichieXX]

@s-bormann

[mucki]

@s-bormann

Sehr gute Frage... Vielleicht war das ein RAW von einem alten Nuki?

Das aktuelle arbeitet IMHO immer mit den Werten:
"0": "NO_ACTION",
"1": "UNLOCK",
"2": "LOCK",
"3": "UNLATCH",
"4": "LOCK_N_GO",
"5": "LOCK_N_GO_WITH_UNLATCH"

Ich habe ein aktuelles Nuki im Einsatz, und in ioBroker sowohl den Nuki, als auch den Nuki 2.0 Adapter.
Die arbeiten aber meiner Meinung nach beide mit den o.a. Werten fürs Öffnen, Schließen etc...

Nuki 2.0 (von dem war das RAW aus meinem vorherigen Post):
https://github.com/Zefau/ioBroker.nuki2

Nuki Adapter (habe ich noch als Instanz, nutze aber nur noch den Nuki 2.0):
https://github.com/smaragdschlange/ioBroker.nuki

Nachtrag:
Der RAW vom Doc war doch nur für den aktuellen Zustand, oder sehe ich das falsch. Wie will man damit denn eine Aktion starten?

Also das Nuki nutzt in der Tat verschiedene Datenpunkte:

[s.bormann]

@zahnheinrich sagte in [Neuer Adapter] Visualisierung iQontrol:

Ausprobiert mit Änderung der Schaltbezeichnungen EIN/AUS in ON/OFF.

Ah, ich glaube, das liegt daran, dass "on" und "off" intern wieder zurückübersetzt werden!
Probier mal was anderes, wie z.B. "test an" und "test aus". Geht es damit?

[zahnheinrich]

@s-bormann
Ich hatte vorher andere Werte für true/false gesetzt (otvorene/zatvorene). Dabei ist es mir ja aufgefallen. Geht also nicht.

[s.bormann]

@mucki sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann

Sehr gute Frage... Vielleicht war das ein RAW von einem alten Nuki?

Das aktuelle arbeitet IMHO immer mit den Werten:
"0": "NO_ACTION",
"1": "UNLOCK",
"2": "LOCK",
"3": "UNLATCH",
"4": "LOCK_N_GO",
"5": "LOCK_N_GO_WITH_UNLATCH"

Ich habe ein aktuelles Nuki im Einsatz, und in ioBroker sowohl den Nuki, als auch den Nuki 2.0 Adapter.
Die arbeiten aber meiner Meinung nach beide mit den o.a. Werten fürs Öffnen, Schließen etc...

Nuki 2.0 (von dem war das RAW aus meinem vorherigen Post):
https://github.com/Zefau/ioBroker.nuki2

Nuki Adapter (habe ich noch als Instanz, nutze aber nur noch den Nuki 2.0):
https://github.com/smaragdschlange/ioBroker.nuki

Nachtrag:
Der RAW vom Doc war doch nur für den aktuellen Zustand, oder sehe ich das falsch. Wie will man damit denn eine Aktion starten?

Also das Nuki nutzt in der Tat verschiedene Datenpunkte:

Schick mal bitte den RAW vom lockState und lastAction.

Frage: Zeigt lastAction immer den letzt gewählten Zustand von action? Was passiert, wenn ein Fehler aufgetreten ist (z.B. Motorlauf blockiert)?