Test Adapter iQontrol 2.0.x Vis (Entwicklungs-Thread)
-
0.2.4 ist raus.
@dslraser Ich denke, damit geht auch der CONTROL_MODE für HM-IP einschließlich BOOST. Bin man gespannt auf Eure Rückmeldung. Der Teufel steckt ja bekanntlich im Detail
VG -
@s-bormann sagte in [Neuer Adapter] Visualisierung iQontrol:
0.2.4 ist raus.
@dslraser Ich denke, damit geht auch der CONTROL_MODE für HM-IP einschließlich BOOST. Bin man gespannt auf Eure Rückmeldung. Der Teufel steckt ja bekanntlich im Detail
VGja, der Teufel steckt wie immer im Detail, deshalb zwischendurch auch von mir ein herzliches Dankeschön für Deinen klasse Adapter und deine hartnäckige Arbeit und Zeit, diesen fehlerfrei zu machen ! Es funktioniert jetzt auch bei mir. Sämtliche Modi werden über den FHEM-Datenpunkt controlMode durchgeschaltet.
Zum Thema Partymodus beim Homematic-Thermostat HM-CC-RT-DN habe ich ein kleines Demo-Script geschrieben, wie über einen separaten Datenpunkt der Command-String in der Notation "PARTY_MODE_SUBMIT" zu "controlParty" umgeschrieben werden kann und damit den Party-Modus steuert. Das Script lässt sich natürlich beliebig und allgemeingültig ausbauen, z.B. um sämtliche Party-Modes aller Thermostate zu steuern, usw.
/*Umschreiben des IQontrol PARTY_MODE_SUBMIT String in Homematic controlParty String PARTY_MODE_SUBMIT = "partyModeTemperature,StartTime,StartDay,StartMonth,StartYear,StopTime,StopDay,StopMonth,StopYear" Bsp: PARTY_MODE_SUBMIT=27,1170,15,9,19,1410,15,9,19 controlParty Grad StartDay StartTime StopDay StopTime Bsp: controlParty 16 06.12.13 16:30 09.12.13 05:00 */ createState('javascript.0.Heizungssteuerung.IQontrolThermostatStudioPartyModus.PARTY_MODE_SUBMIT',false); on({id:'javascript.0.Heizungssteuerung.IQontrolThermostatStudioPartyModus.PARTY_MODE_SUBMIT',change:'ne'}, function (obj) { PartyModeSubmit2ControlParty(); }); function PartyModeSubmit2ControlParty () { var state = getState('javascript.0.Heizungssteuerung.IQontrolThermostatStudioPartyModus.PARTY_MODE_SUBMIT').val; var PARTY_MODE_SUBMIT = state.split(','); var degrees = PARTY_MODE_SUBMIT[0]; var StartDay = PARTY_MODE_SUBMIT[2]+"."+PARTY_MODE_SUBMIT[3] + "."+ PARTY_MODE_SUBMIT[4]; var StartTime = Math.floor(PARTY_MODE_SUBMIT[1]/60) + ":" + PARTY_MODE_SUBMIT[1] % 60; var StopDay = PARTY_MODE_SUBMIT[6]+"."+PARTY_MODE_SUBMIT[7] + "." + PARTY_MODE_SUBMIT[8]; var StopTime = Math.floor(PARTY_MODE_SUBMIT[5]/60) + ":" + PARTY_MODE_SUBMIT[5] % 60; var controlParty = degrees + " " + StartDay + " " + StartTime + " " + StopDay + " " + StopTime; console.log("Umrechnung IQontrol Partytime: PARTY_MODE_SUBMIT= " + getState('javascript.0.Heizungssteuerung.IQontrolThermostatStudioPartyModus.PARTY_MODE_SUBMIT').val + " --> controlParty= " + controlParty); setState('fhem.0.Thermostat_Studio_1_Clima.controlParty', controlParty); }VG,ok
-
@s-bormann sagte in [Neuer Adapter] Visualisierung iQontrol:
@dslraser Wie ist der RAW von CONTROL_MODE?
CONTOL_MODE funktioniert bei mir. BOOST funktioniert nicht.
-
@dslraser sagte in [Neuer Adapter] Visualisierung iQontrol:
@s-bormann sagte in [Neuer Adapter] Visualisierung iQontrol:
@dslraser Wie ist der RAW von CONTROL_MODE?
CONTOL_MODE funktioniert bei mir. BOOST funktioniert nicht.
Hi, sag noch mal, was genau bei Boost nicht klappt.
-
@s-bormann sagte in [Neuer Adapter] Visualisierung iQontrol:
Diese Konstellation hatte ich vorher noch nicht - habe aber mal eine Anpassung der Zeile in diese Richtung vorgenommen.
Wenn das so ist, dann wird der Fehler aber auch an anderer Stelle auftreten, denn Zeilen mit exakt diesem Aufbau gibt es in iQontrol haufenweise...genau das in einer anderen Zeilennummer. (die habe ich aber nicht mehr parat, da ich diese Kachel dann nicht mehr bearbeiten konnte, ging nur noch zu löschen und neu anlegen)
Hat aber immer noch so ausgesehen, also kein Boost zu sehen.
-
@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?
-
@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.
-
Hallo, ist aber nur bei HMIP so, oder?
-
@sigi234 sagte in [Neuer Adapter] Visualisierung iQontrol:
Hallo, ist aber nur bei HMIP so, oder?
keine Ahnung, ich habe nur HMIP. Aber da sind wir je gerade dabei die Unterschiede raus zu arbeiten.
-
@dslraser sagte in [Neuer Adapter] Visualisierung iQontrol:
@sigi234 sagte in [Neuer Adapter] Visualisierung iQontrol:
Hallo, ist aber nur bei HMIP so, oder?
keine Ahnung, ich habe nur HMIP. Aber da sind wir je gerade dabei die Unterschiede raus zu arbeiten.
Ich habe nur HM Geräte, bei mir geht es. Wenn ich testen soll, einfach sagen.
-
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
-
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,}); -
@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!!! -
@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, zur Info: bin ein paar Tage ohne PC. Melde mich, sobald ich wieder online bin.
-
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. -
@s-bormann
Danke für die Info.
Keinen Stress! -
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" } -
@mucki Ich sehe jetzt schon, dass nuki falsch implementiert ist.
nukiId darf nicht in common drin sein -
@mucki sagte in [Neuer Adapter] Visualisierung iQontrol:
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
