Test Adapter iQontrol 2.0.x Vis (Entwicklungs-Thread)

s.bormann

@mucki sagte in [Neuer Adapter] Visualisierung iQontrol:

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

ype auf booelan fest. Nicht invertieren. D

Also nur so? Damit erscheint leider ebenfalls immer das Symbol mit der schwachen Batterie (ob invertiert oder nicht).

Habe in der neuen 0.2.3 ein Handling für diesen seltsamen states-string eingebaut. Vielleicht lag es daran?
Deaktiviere bitte noch mal den custom-dialog und speichere. Dann versuche noch einmal den type auf boolean festzulegen.
Klappt es jetzt?

s.bormann

@ok1 So neue Version 0.2.3 ist online - nächster Versuch mit dem CONTROL_MODE.... Ich hoffe, es klappt! Sorry für dieses try'n'error.

dslraser

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

CONTROL_MODE.

bei mir funktioniert es nun. Es wird umgeschaltet.

Bildschirmfoto 2019-09-15 um 09.50.54.png

Jetzt eine neue Frage. Wenn ich den BOOST_STATE hinzufüge, dann geht der Dialog nicht auf ?
(HMIP)

{
 "type": "state",
 "common": {
   "def": false,
   "type": "boolean",
   "read": false,
   "write": true,
   "role": "switch.boost",
   "name": "Heizung Wohnzimmer INT0000001:1.BOOST_MODE"
 },
 "native": {
   "MIN": false,
   "OPERATIONS": 6,
   "MAX": true,
   "FLAGS": 1,
   "ID": "BOOST_MODE",
   "TYPE": "BOOL",
   "DEFAULT": false,
   "CONTROL": "HEATING_CONTROL_HMIP.BOOST_MODE"
 },
 "from": "system.adapter.hm-rpc.2",
 "user": "system.user.admin",
 "ts": 1568532780430,
 "_id": "hm-rpc.2.INT0000001.1.BOOST_MODE",
 "acl": {
   "object": 1636,
   "state": 1636,
   "owner": "system.user.admin",
   "ownerGroup": "system.group.administrator"
 }
}

dslraser

@s-bormann
hier noch aus der Console.

Mit hinzugefügten Boost_Staate

Bildschirmfoto 2019-09-15 um 10.03.13.png

ohne Boost_State, aber nach dem aktualisieren der Seite (automatik und manuall schalten funktioniert, es wird anscheinend nach boost_state gesucht, aber nicht gefunden ? )

Bildschirmfoto 2019-09-15 um 10.13.39.png

ok1

@s-bormann
ja, bei mir wird der Datenpunkt auch geschrieben ! Allerdings nur wenn er auch exakt CONTROL_MODE heisst.

Bei dem von mir selbst ausserhalb von FHEM angelegten Datenpunkts (weiter oben im Thread unter Szenario 1)

funktioniert es. Dort habe ich den Datenpunkt genauso benannt.
Bei Wahl des entsprechenden vom FHEM-Adapter erzeugten Datenpunkts in FHEM (Szenario 2 == Normalfall)

liest IQontrol nicht den tatsächlichen Namen des Datenpunktes aus der IQontrol-Config, sondern überschreibt den Namen. Aus "controlMode" wird dann "CONTROL_MODE", was zu einem "undefined" Fehler im Javascript führt.

Also nur noch eine Kleinigkeit und dann sollte es funktionieren .... VG, ok

dslraser

@s-bormann

ich habe eben eine ganze Weile gesucht, warum ein neuer Button (Knopf) plötzlich anders funktioniert als alle anderen die ich bisher erstellt habe.

das steht bei allen "alten" Button die ich bisher erstellt habe.

javascript.0.01Heiko.Eigene_Datenpunkte.05Telegram.Eingangskamera: true --> true
index.js:720        converted state to boolean. New value is: true

Bisher habe ich alle Button auf wurde aktualisiert in Blockly getriggert. Bisher habe ich auch nur Button gesehen die immer true sind und quasi nur aktualisiert werden.

In einem neuem Blockly (wo der Button exakt genau so erstellt wurde wie alle anderen vorher auch)
macht iQontol plötzlich das hier

javascript.0.01Heiko.Eigene_Datenpunkte.05Telegram.Standort_Heiko: true --> 
index.js:720        converted state to boolean. New value is: false

Warum ist das jetzt so ?

Wenn ich jetzt auf wurde aktualisiert im Blockly triggere, dann wird zweimal aktualisiert, weil einmal von false auf true (converted) und dann wieder auf false.

Bug oder gewollt ?

s.bormann

@dslraser sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann

ich habe eben eine ganze Weile gesucht, warum ein neuer Button (Knopf) plötzlich anders funktioniert als alle anderen die ich bisher erstellt habe.

das steht bei allen "alten" Button die ich bisher erstellt habe.
javascript.0.01Heiko.Eigene_Datenpunkte.05Telegram.Eingangskamera: true --> true
index.js:720        converted state to boolean. New value is: true
Bisher habe ich alle Button auf wurde aktualisiert in Blockly getriggert. Bisher habe ich auch nur Button gesehen die immer true sind und quasi nur aktualisiert werden.

In einem neuem Blockly (wo der Button exakt genau so erstellt wurde wie alle anderen vorher auch)
macht iQontol plötzlich das hier
javascript.0.01Heiko.Eigene_Datenpunkte.05Telegram.Standort_Heiko: true --> 
index.js:720        converted state to boolean. New value is: false
Warum ist das jetzt so ?

Wenn ich jetzt auf wurde aktualisiert im Blockly triggere, dann wird zweimal aktualisiert, weil einmal von false auf true (converted) und dann wieder auf false.

Bug oder gewollt ?

Bug

gewollt

Wird in der nächsten Version gefixed

s.bormann

@dslraser sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann
hier noch aus der Console.

Mit hinzugefügten Boost_Staate

ohne Boost_State, aber nach dem aktualisieren der Seite (automatik und manuall schalten funktioniert, es wird anscheinend nach boost_state gesucht, aber nicht gefunden ? )

Hi,
kannst Du mal bitte in der Console bei der Fehlermeldung auf das index.js:1223 klicken und schauen, wo genau in der Zeile der Fehler ist? Im Moment sehe ich noch nicht, wo genau der Fehler steckt.

dslraser

@s-bormann

function updateState(stateId, ignorePreventUpdate){
	//Invert (ioBroker -> iQontrol - the opposite way is inside setState-Function)
	if(usedObjects[stateId]  && typeof usedObjects[stateId].common !== udef && typeof usedObjects[stateId].common.custom !== udef && typeof usedObjects[stateId].common.custom[namespace] !== udef && typeof usedObjects[stateId].common.custom[namespace].invert !== udef && usedObjects[stateId].common.custom[namespace].invert == true) {
		if(states[stateId] && typeof states[stateId].val !== udef && !states[stateId].isInverted) switch(typeof states[stateId].val){
			case "boolean":
			console.log("Inverting boolean state " + stateId + " from " + states[stateId].val + "...");
			states[stateId].val = !states[stateId].val;
			states[stateId].isInverted = true;
			console.log("...to " + states[stateId].val);
			break;
			
			case "number":
			console.log("Inverting number state " + stateId + " from " + states[stateId].val + "...");
			if(typeof usedObjects[stateId] !== udef && typeof usedObjects[stateId].common.min !== udef) var min = usedObjects[stateId].common.min;
			if(typeof usedObjects[stateId] !== udef && typeof usedObjects[stateId].common.custom !== udef && typeof usedObjects[stateId].common.custom[namespace] !== udef && typeof usedObjects[stateId].common.custom[namespace].min !== udef && usedObjects[stateId].common.custom[namespace].min !== "") result.min = usedObjects[stateId].common.custom[namespace].min;
			if(typeof usedObjects[stateId] !== udef && typeof usedObjects[stateId].common.max !== udef) var max = usedObjects[stateId].common.max;
			if(typeof usedObjects[stateId] !== udef && typeof usedObjects[stateId].common.custom !== udef && typeof usedObjects[stateId].common.custom[namespace] !== udef && typeof usedObjects[stateId].common.custom[namespace].max !== udef && usedObjects[stateId].common.custom[namespace].max !== "") result.max = usedObjects[stateId].common.custom[namespace].max;
			if(typeof min !== udef && typeof max !== udef){
				states[stateId].val = max - (states[stateId].val - min);
				states[stateId].isInverted = true;
				console.log("...to " + states[stateId].val);
			} else {
				console.log("...aborted inverting, because min or max is missing");
			}
			break;
			
			case "string":
			console.log("Inverting string state " + stateId + " is not supported!");
			break;	

			default:
			console.log("Inverting state " + stateId + " is impossible - type not known: " + typeof states[stateId].val);
		}
	}
	if(preventUpdate[stateId]){
		console.log(">> ack: " + states[stateId].ack + " val: " + states[stateId].val + " newVal: " + preventUpdate[stateId].newVal);
	}
	if (preventUpdate[stateId] && states[stateId].ack && typeof states[stateId].val != udef && states[stateId].val != null && states[stateId].val.toString() == preventUpdate[stateId].newVal.toString()) { //An ack-true value has reached the new value - preventUpdate can be cancelled
		console.log("<< ack-val reached new val: preventUpdate regular ended.");
		$("[data-iQontrol-Device-ID='" + preventUpdate[stateId].deviceId + "'] .iQontrolDeviceLoading").removeClass("active");
		clearTimeout(preventUpdate[stateId].timerId);
		delete preventUpdate[stateId];
	}
	if(viewUpdateFunctions[stateId]) for (i = 0; i < viewUpdateFunctions[stateId].length; i++){
		if(!preventUpdate[stateId] || ignorePreventUpdate) {
			viewUpdateFunctions[stateId][i](stateId);
		}
	}
	if(dialogUpdateFunctions[stateId]) for (i = 0; i < dialogUpdateFunctions[stateId].length; i++){
		if(!preventUpdate[stateId] || ignorePreventUpdate == "ignorePreventUpdateForDialog") {
			dialogUpdateFunctions[stateId][i](stateId);
		}
	}
}

s.bormann

@dslraser Mach mal bitte einen Screenshot, statt das raus zu kopieren, denn eigentlich müsste der Fehler rot unterstrichen sein (aktuell weiß ich nur, dass der Fehler in Zeile 1223 steckt, aber nicht, an welcher Stelle in dieser Zeile)

dslraser

@s-bormann
geht nicht alles drauf, aber hier ist es unterstrichen

Bildschirmfoto 2019-09-15 um 22.03.13.png

s.bormann

@ok1 sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann
ja, bei mir wird der Datenpunkt auch geschrieben ! Allerdings nur wenn er auch exakt CONTROL_MODE heisst.

Bei dem von mir selbst ausserhalb von FHEM angelegten Datenpunkts (weiter oben im Thread unter Szenario 1)

funktioniert es. Dort habe ich den Datenpunkt genauso benannt.
Bei Wahl des entsprechenden vom FHEM-Adapter erzeugten Datenpunkts in FHEM (Szenario 2 == Normalfall)

liest IQontrol nicht den tatsächlichen Namen des Datenpunktes aus der IQontrol-Config, sondern überschreibt den Namen. Aus "controlMode" wird dann "CONTROL_MODE", was zu einem "undefined" Fehler im Javascript führt.

Also nur noch eine Kleinigkeit und dann sollte es funktionieren .... VG, ok

Alles klar, stimmt, werde ich in der nächsten Version anpassen.

s.bormann

@dslraser sagte in [Neuer Adapter] Visualisierung iQontrol:

@s-bormann
geht nicht alles drauf, aber hier ist es unterstrichen

Hmm, seltsam. Wenn ich es richtig verstehe, dann ist das Objekt xxx.common.custom zwar definiert (!== "undefined") aber null. 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...

Naja, fixen wir dann alles nach und nach weg

Neue Version folgt gleich, dann schauen wir mal, ob es dann geht.

s.bormann

@dslraser sagte in [Neuer Adapter] Visualisierung iQontrol:

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

CONTROL_MODE.

bei mir funktioniert es nun. Es wird umgeschaltet.

Bildschirmfoto 2019-09-15 um 09.50.54.png

Jetzt eine neue Frage. Wenn ich den BOOST_STATE hinzufüge, dann geht der Dialog nicht auf ?
(HMIP)

{
 "type": "state",
 "common": {
   "def": false,
   "type": "boolean",
   "read": false,
   "write": true,
   "role": "switch.boost",
   "name": "Heizung Wohnzimmer INT0000001:1.BOOST_MODE"
 },
 "native": {
   "MIN": false,
   "OPERATIONS": 6,
   "MAX": true,
   "FLAGS": 1,
   "ID": "BOOST_MODE",
   "TYPE": "BOOL",
   "DEFAULT": false,
   "CONTROL": "HEATING_CONTROL_HMIP.BOOST_MODE"
 },
 "from": "system.adapter.hm-rpc.2",
 "user": "system.user.admin",
 "ts": 1568532780430,
 "_id": "hm-rpc.2.INT0000001.1.BOOST_MODE",
 "acl": {
   "object": 1636,
   "state": 1636,
   "owner": "system.user.admin",
   "ownerGroup": "system.group.administrator"
 }
}

Achso, trotz des eben besprochenen Fixes der Zeile 1223:
Der BOOST_STATE ist nicht der BOOST_MODE (davon hast Du den RAW geschickt).
Im BOOST_STATE wird beim HM (nicht-IP) die verbleibende BOOST-Zeit angegeben:

Ich weiß nicht, ob es diesen Datenpunkt bei HM-IP auch gibt??

LG

dslraser

@s-bormann
diese gibt es bei HMIP

Bildschirmfoto 2019-09-15 um 22.20.51.png

s.bormann

@dslraser Dann wäre es wohl BOOST_TIME.
Echt blöd von EQ3, dass die die Datenpunkte teilweise umbenannt und im Detail anders gestaltet haben beim Vergleich von HM und HM-IP...

dslraser

@s-bormann
aber Boost, so wie in Deinem Bild (blau=aktiv) bekomme ich auch nicht angezeigt

s.bormann

@dslraser Wie ist der RAW von CONTROL_MODE?

s.bormann

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

ok1

@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
VG

ja, 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

NEWS

Test Adapter iQontrol 2.0.x Vis (Entwicklungs-Thread)

Support us

887
Online

31.9k
Users

80.2k
Topics

1.3m
Posts

NEWS

Test Adapter iQontrol 2.0.x Vis (Entwicklungs-Thread)

Support us

887Online

31.9kUsers

80.2kTopics

1.3mPosts

887
Online

31.9k
Users

80.2k
Topics

1.3m
Posts