Yet another HomeKit adapter

eumats

Das hört sich für mich an wie die Homematic Rolladensteuerung (wegen denen hab ich den Adapter geschrieben…) `

Klappt die Anzeige in HomeKit auch bei manueller Bedienung der Rollläden? Also per Schalter/Taster?

JW86

Klappt die Anzeige in HomeKit auch bei manueller Bedienung der Rollläden? Also per Schalter/Taster? `

Ja, funktioniert einwandfrei.

Ich erstelle gerade ein bisschen Doku - dabei fiel mir aber auf, das ich für die TargetPosition ein bisschen Tricksen musste.

Sofern nicht anders angegeben, sucht Yahka auf dem Objekt das als Parameter angegeben ist, nach einem State namens "WORKING".

Während Working = TRUE ist, werden keine Werte an HomeKit übermittelt. Erst wenn Working für mind. 150ms FALSE ist, wird der TargetState an HomeKit gesendet.

Andernfalls spring der Slider in der App durch die Gegend, da jede Level-Änderung als neuer Soll-Wert interpretiert werden würde.

Vielleicht ist das auch ein Problem bei dir. Gibt es bei deinem Connector ein Flag, das angibt ob der Rolladen fährt?

eumats

~~@JW86:~~

[

Ich erstelle gerade ein bisschen Doku - dabei fiel mir aber auf, das ich für die TargetPosition ein bisschen Tricksen musste.

Sofern nicht anders angegeben, sucht Yahka auf dem Objekt das als Parameter angegeben ist, nach einem State namens "WORKING".

Während Working = TRUE ist, werden keine Werte an HomeKit übermittelt. Erst wenn Working für mind. 150ms FALSE ist, wird der TargetState an HomeKit gesendet.

Andernfalls spring der Slider in der App durch die Gegend, da jede Level-Änderung als neuer Soll-Wert interpretiert werden würde.

Vielleicht ist das auch ein Problem bei dir. Gibt es bei deinem Connector ein Flag, das angibt ob der Rolladen fährt? `

Witzig das Du das gerade schreibst. Denn das ist mir auch gerade beim Spielen aufgefallen. Ein Working gibt es bei mir nicht direkt. Das der Rolladen sich bewegt kann man nur ermitteln, indem der "Verbrauch" größer 0 Watt ist. Bei meinem Testrolladen (der sicher durch die ganze Spielerei bald den Geist aufgibt… :mrgreen: ) ist bis 1 Watt der Motor im Stillstand und eine Bewegung des Motors zeigt ca. 125 Watt an. Siehe Screenshot..

Meine Idee war gerade aus dem Vorgängerzustand und ob der Motor läuft zu ermitteln, ob der Rolladen hoch oder runter fährt. Mal schauen ob meine rudimentären Java Kenntnisse dazu reichen...

Falls Du jemanden brauchst, der die Doku "reviewt" dann einfach melden...
3610_clipboard_1.jpg

JW86

~~@eumats:~~

Falls Du jemanden brauchst, der die Doku "reviewt" dann einfach melden… `
Gerne:

https://github.com/jensweigele/ioBroker.yahka/wiki

Rechts sind die verschiedenen Seiten

Gesendet von iPhone mit Tapatalk

eumats

~~@eumats:~~

Ein Working gibt es bei mir nicht direkt. Das der Rolladen sich bewegt kann man nur ermitteln, indem der "Verbrauch" größer 0 Watt ist. Bei meinem Testrolladen (der sicher durch die ganze Spielerei bald den Geist aufgibt… :mrgreen: ) ist bis 1 Watt der Motor im Stillstand und eine Bewegung des Motors zeigt ca. 125 Watt an. Siehe Screenshot..

Meine Idee war gerade aus dem Vorgängerzustand und ob der Motor läuft zu ermitteln, ob der Rolladen hoch oder runter fährt. Mal schauen ob meine rudimentären Java Kenntnisse dazu reichen... `

Du hast nicht zufällig spontan eine gute Idee, wie ich aus den Gegebenheiten den "PositionState" ableiten und in yahka kann? Ich bin da gerade "lost"… :shock:

eumats

~~@JW86:~~

Ich erstelle gerade ein bisschen Doku - dabei fiel mir aber auf, das ich für die TargetPosition ein bisschen Tricksen musste.

Sofern nicht anders angegeben, sucht Yahka auf dem Objekt das als Parameter angegeben ist, nach einem State namens "WORKING".

Während Working = TRUE ist, werden keine Werte an HomeKit übermittelt. Erst wenn Working für mind. 150ms FALSE ist, wird der TargetState an HomeKit gesendet.

Andernfalls spring der Slider in der App durch die Gegend, da jede Level-Änderung als neuer Soll-Wert interpretiert werden würde.

Vielleicht ist das auch ein Problem bei dir. Gibt es bei deinem Connector ein Flag, das angibt ob der Rolladen fährt? `

Bei Lesen Deiner Doku ist mir gerade eine Idee gekommen. Für Aktoren, bei denen es kein "Working" gibt, wäre es hier nicht eine brauchbarer Workaround, eine Funktion analog zu ioBroker.State.Defered zu schaffen, die aber mit "entprellt (debounced)" von HomeKit in Richtung iobroker. Hier kann man den Wert (z.B. 200ms) ja auch parametrierbar machen.

Paulchen67

~~@JW86:~~

~~@Paulchen67:~~

Danke, aber leider funktioniert das bei Homematic Dimmern auch nicht. `

Kannst du mal Screenshots deiner Konfig schicken? `

Hallo,

So hab ich sie momentan eingestellt.

Funktioniert so halbwegs. Licht flackert beim regeln, geht nicht immer aus beim Aus drücken.

Merkt nicht das das Licht an ist wenn es von anderer Stelle eingeschaltet wird.

Homematic Dimmer HM-LC-Dim1TPBU-FM

Das sind die Objekteigenschaften dazu.

Das ist die andere Variante an Dimmer die ich im Einsatz habe.

Da ist das verhalten noch schlechter.

Homematic iP Dimmer HmIP-FDT

Die Objekteigenschaften dazu:

Astrein funktionieren die Dimmer wenn ich sie in Yahka als Door definiere.

Was halt daran unschön ist, ist die Darstellung in der Home App als Tür und

an Stelle von Ein/Aus steht halt Geöffnet/Geschlossen dran.

Hatte dir schon mal ne PN geschrieben wegen dem Einfügen des Dimmer in die Yahka Dropdown Liste.

Gruss Paulchen

JW86

kannst du mal die verschiedenen Aktionen durchführen und jeweils ein Debug-Log dazu posten?

Ich kann mir nicht vorstellen das wir das nicht zum laufen bekommen. Ich habe leider keinen Dimmer um das zu testen, daher musst du nun die Recherchen/Tests vornehmen.

JW86

~~@eumats:~~

Meine Idee war gerade aus dem Vorgängerzustand und ob der Motor läuft zu ermitteln, ob der Rolladen hoch oder runter fährt. Mal schauen ob meine rudimentären Java Kenntnisse dazu reichen… `
Wenn ich das richtig verstehe, hast du eine Variable für den Level und eine Variable für die Leistungsaufnahme oder?

Ich habe dir mal ein Skript gebastelt:

const PositionState_DECREASING = 0;
const PositionState_INCREASING = 1;
const PositionState_STOPPED = 2;

function FibaroWindowCoverStateEmulator(levelId, powerId, stateId) {
    this.levelId = levelId;
    this.powerId = powerId;
    this.stateId = stateId;
    this.lastLevel = getState(this.levelId).val;

    on({id: levelId}, () => this.refreshState());
    on({id: powerId}, () => this.refreshState());
}

FibaroWindowCoverStateEmulator.prototype = {
    refreshState: function() {
        var level = getState(this.levelId).val;
        var power = getState(this.powerId).val;
        var state = this.calculateState(level, power);
        this.lastLevel = level;
        if (state === undefined) {
            return;
        }

        console.log('settings state with id: ' + this.stateId + ' to ' + state + ' - caused by level:' + level + ' and power: ' + power);
        setState(this.stateId, state);
    },

    calculateState: function(level, power) {
        if(this.lastLevel === undefined) {
            return;
        }

        if (power < 1) {
            return PositionState_STOPPED;
        }

        if (level > this.lastLevel) {
            return PositionState_INCREASING;
        } else if (level < this.lastLevel) {
            return PositionState_DECREASING;
        } else {
            return PositionState_STOPPED;
        }
    }
};

var test1 = new FibaroWindowCoverStateEmulator("Test1.Level", "Test1.Power2", "Test1.State")

Du musst eigentlich nur die letzte Zeile ändern, der Rest sollte so passen.

Der Anfang des Skripts ist eine Klasse die in der letzten Zeile instanziert wird. Der erste Parameter ist der Level, der zweite die Leistungsaufnahme und der dritte Parameter ist der State in den das Ergebnis geschrieben werden soll (=> du musst die Variable vorher anlegen). In dieser Variablen steht der "fertige" Homekit PositionState.

Wenn du mehrere Rolläden hast, kannst du einfach die letzte Zeile beliebig oft duplizieren (mit anderen Werten und einem anderen Variablennamen).

Der Algorithmus ist wie folgt:

Bei Änderung von Level oder Leistungsaufnahme wird der State berechnet.

Ist die Leistungsaufnahme < 1, steht der Rolladen (=> Stopped)

Ansonsten wird der aktuelle Level mit dem letzten Level verglichen. Ist der neue Level größer, fährt der Rolladen hoch (PositionState_INCREASING). Ist der neue Level kleiner, fährt der Rolladen runter (PositionState_DECREASING) - ansonsten steht der Rolladen.

Das Skript hat zwei Annahmen:

1. die Leistungsaufnahme ist immer positiv

2. Kleiner Level bedeutet geschloßen (Level = 0) und großer Level (Level = 100) bedeutet geöffnet.

eumats

~~@JW86:~~

Wenn ich das richtig verstehe, hast du eine Variable für den Level und eine Variable für die Leistungsaufnahme oder? `
Jein. Variablen nicht, sondern Datenpunkte (z.B. javascript.0.virtualDevice.Rolllaeden.EsszimmerOsten.LevelRollo).

~~@JW86:~~

Ich habe dir mal ein Skript gebastelt: `
Besten Dank!

~~@JW86:~~

Das Skript hat zwei Annahmen:

1. die Leistungsaufnahme ist immer positiv

2. Kleiner Level bedeutet geschloßen (Level = 0) und großer Level (Level = 100) bedeutet geöffnet. `

Diese beiden Annahmen treffen zu…

~~@JW86:~~

Du musst eigentlich nur die letzte Zeile ändern, der Rest sollte so passen. `
Geht leider nicht.

var test1 = new FibaroWindowCoverStateEmulator("javascript.0.virtualDevice.Rolllaeden.EsszimmerOsten.LevelRollo", "javascript.0.virtualDevice.Rolllaeden.EsszimmerOsten.PowerRollo", "javascript.0.virtualDevice.Rolllaeden.EsszimmerOsten.position");

Fehlermeldung:

javascript.0 2018-01-10 22:48:01.513 warn at script.js.common.1_Play.Skript3:48:13

javascript.0 2018-01-10 22:48:01.513 warn at Object.FibaroWindowCoverStateEmulator (script.js.common.1_Play.Skript3:6:22)

javascript.0 2018-01-10 22:48:01.507 warn getState "undefined" not found (3)

Die Datenpunkte existieren und LevelRollo und PowerRollo sind mit dem Fibaro Shutter "verbunden".

Hier die yahka Konfiguration:
3610_clipboard_1.jpg

JW86

Sorry, hatte noch eine last minute Änderung gemacht und nicht getestet [emoji30]

Habe das Script korrigiert.

Gesendet von iPhone mit Tapatalk

Paulchen67

~~@JW86:~~

kannst du mal die verschiedenen Aktionen durchführen und jeweils ein Debug-Log dazu posten?

Ich kann mir nicht vorstellen das wir das nicht zum laufen bekommen. Ich habe leider keinen Dimmer um das zu testen, daher musst du nun die Recherchen/Tests vornehmen. `

Was meinst du?

Was iobroker ins Log schreibt wenn ich versuche die Dimmer mit der Home-App auf iPhone zu bedienen,

oder was iobroker Logt wenn ich in Yahka den Dimmer konfiguriere?

Also wenn ich denn Dimmer so konfiguriere

Dann kommt das im Log

eumats

~~@JW86:~~

Sorry, hatte noch eine last minute Änderung gemacht und nicht getestet [emoji30]

Habe das Script korrigiert. `

Danke! Damit kommt zumindest keine "undefined" Fehler. Aber leider ist das Verhalten nicht wie gedacht.

In HomeKit sieht es wie folgt aus (am Beispiel des Hochfahrens, das Runterfahren ist aber analog):

1. "geschlossen"

2. "Wird geöffnet…" wird max 1 sek eingezeigt.

3. "geschlossen" wird angezeigt, bis der Rollladen ganz hochgefahren ist. Danach wird offen angezeigt.

Die folgende Log-Ausgabe beschreibt das hochfahren. Also von 0-100%.

javascript.0	2018-01-11 08:21:59.925	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:100 and power: 0.7
javascript.0	2018-01-11 08:21:59.906	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 1 - caused by level:100 and power: 66.4
javascript.0	2018-01-11 08:21:58.096	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:0 and power: 66.4
javascript.0	2018-01-11 08:21:40.745	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:0 and power: 125.9
javascript.0	2018-01-11 08:21:39.643	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:0 and power: 0.7
javascript.0	2018-01-11 08:21:39.572	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:100 and power: 0.7

Die folgende Log-Ausgabe beschreibt das runterfahren. Also von 100-0%.

javascript.0	2018-01-11 08:22:44.920	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:0 and power: 0.7
javascript.0	2018-01-11 08:22:44.909	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 0 - caused by level:0 and power: 108.4
javascript.0	2018-01-11 08:22:42.928	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:100 and power: 108.4
javascript.0	2018-01-11 08:22:26.598	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:100 and power: 125.4
javascript.0	2018-01-11 08:22:25.470	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:100 and power: 0.7
javascript.0	2018-01-11 08:22:25.403	info	script.js.common.Devices.Rolladen.EsszimmerOsten.FibaroWindowCoverStateEmulator: settings state Position to 2 - caused by level:0 and power: 0.7

Zur Info: Der Datenpunkt Level verhält sich bei den Fibaro Dingern wie folgt:

1. aktueller Wert z.B. 0 (unten)

2. Zielwert (z.B. 80) wird in den Datenpunkte geschrieben

3. Im Datenpunkt wird der Zielwert kurz angezeigt und zeigt dann wieder auf den Startwert (in meinem Bsp also 0) an.

4. Erst nach dem Erreichen des Zielwertes geht Level auf den Zielwert (in meinem Bsp. 80)

Die Konfiguration in yahka ist wie folgt:
3610_untitled.jpg

JW86

Danke euch beiden für die Logs. Schaue es mir heute Abend mal an

Gesendet von iPhone mit Tapatalk

JW86

@eumats: kannst du mal schauen wie sich das „ACK“ flag verhält während der ganzen Prozedur?

@Paulchen67: ich brauch ein Log indem du ein oder ausschaltest, oder dimmst etc. Am besten mit Beschreibung was du gemacht hast

Gesendet von iPhone mit Tapatalk

Paulchen67

~~@JW86:~~

@eumats: kannst du mal schauen wie sich das „ACK“ flag verhält während der ganzen Prozedur?

@Paulchen67: ich brauch ein Log indem du ein oder ausschaltest, oder dimmst etc. Am besten mit Beschreibung was du gemacht hast

Gesendet von iPhone mit Tapatalk `

Da kommt gar nichts im Log.

Ich kann alles ohne Probleme schalten bis auf die Dimmer.

Ich drücke in der Home App auf das WZ Licht. Der Button geht an und dabei manchmal auf

100% oder auf 1%. Das Licht flackert aber in Wirklichkeit nur kurz auf. Dann drücke ich lang auf den Button damit das Schieberegler Menü aufgeht. Wenn ich den Schieberegler bewege ruckelt das Licht hin und her. Bleibt mal an, mal aus. Dabei schießt der Schieberegler ohne mein zutun auch hin und her.

Außerdem wird nichts angezeigt wenn ich die Dimmer anderweitig schalte (direkt am Wandschalter).

Wie schon weiter oben (08.01.2018 11:41) und in der PN an dich funktionieren die Dimmer hervorragend wenn ich sie als Door definiere.

Da ruckelt nichts, der Schieberegler macht das was mein Finger macht und das Licht wir als an angezeigt wenn ich die Dimmer anderweitig bediene (Wandschalter)

eumats

~~@JW86:~~

@eumats: kannst du mal schauen wie sich das „ACK“ flag verhält während der ganzen Prozedur?

Gesendet von iPhone mit Tapatalk `

Ich habe noch mal ein bisschen rumgespielt. Für eine korrekte Anzeige in HomeKit (also die Zustände offen, geschlossen, wird geöffnet, wird geschlossen) reicht es currentState und Target korrekt zu befüllen. PositionState kann ignoriert werden.

Bedeutet:

Target=100, current: 20 -> wird geöffnet

Target=40, current: 80 -> wird geschlossen

beide gleich -> offen oder zu

Bei den Fibaro Autoren ist es so, dass beim schreiben des Zielwerte in Level_1 dieser nur kurz angezeigt wird. Dann springt er auf den Startwert zurück.

Und das führt zu einer unschönen Anzeige in HomeKit. Bedeutet:

Target=100, current: 20 -> 20% geöffnet bis Zielwert erreicht

Ich habe mir aktuell wie folgt beholfen. Ich habe einen Datenpunkt für TagetLLevel und in yahka eingebunden. Ändert sich der Wert (on:…) schreibe ich den Wert mit setState in Level_1 vom Aktor. Bei einer reinen HomeKit Steuerung funktioniert das alles Problemlos.

Nur bei einer Bedienung über die Taster an der Wand muss ich da tricksen. Aktuell mache ich das wie folgt:

Aktueller Verbrauche (in Watt) kleiner 1 (Rollladen steht still) dann schreibe den Wert aus Level_1 des Aktors in TargetLevel.

Hier besteht aber das Problem, dass nicht der ACK Wert von Level_1 in TageLevel geschrieben wird und somit der Rollladen teilweise lustig hin und her fährt...

Ich hoffe das war einigermaßen verständlich...

Hast Du evtl. eine Idee wie man das "umgehen" kann?

if (value < 1) {
	var wert = getState(LevelRollo).val;
	console.log('### Power: ' + value + '. Setze Target auf: ' + wert)
	setState(TargetLevel,wert);
}

Hier eine Fahrt von 76% auf 99%…

stateChange	zwave.0.NODE10.SWITCH_MULTILEVEL.Level_1	99	true	 zwave.0	2018-01-14 15:37:54.522	2018-01-14 15:37:54.522
stateChange	zwave.0.NODE10.SWITCH_MULTILEVEL.Level_1	76	true	 zwave.0	2018-01-14 15:37:48.357	2018-01-14 15:37:48.357
stateChange	zwave.0.NODE10.SWITCH_MULTILEVEL.Level_1	99	false	javascript.0	2018-01-14 15:37:48.288	2018-01-14 15:37:48.288

JW86

~~@eumats:~~

Hast Du evtl. eine Idee wie man das "umgehen" kann? `

Kannst du mal kurz die folgende Version des Scripts einspielen und mir die Log-Ausgabe geben? Bin mir noch nicht sicher wie man den Sollwert erkennen soll.

Wenn du den Rolladen über die Wandtaster fahren lässt, was kommt dann eigentlich für ein Level?

Fahre am besten mal per Homekit hoch+runter und per Taster hoch+runter und poste das Skript hier.

const PositionState_DECREASING = 0;
const PositionState_INCREASING = 1;
const PositionState_STOPPED = 2;

function FibaroWindowCoverStateEmulator(levelId, powerId, stateId) {
    this.levelId = levelId;
    this.powerId = powerId;
    this.stateId = stateId;
    this.lastLevel = getState(this.levelId).val;

    on({id: levelId}, () => this.refreshState());
    on({id: powerId}, () => this.refreshState());
}

FibaroWindowCoverStateEmulator.prototype = {
    refreshState: function() {
        var level = getState(this.levelId).val;
        var levelAck = getState(this.levelId).ack;
        var power = getState(this.powerId).val;
        var powerAck = getState(this.powerId).ack;
        var state = this.calculateState(level, power);
        this.lastLevel = level;
        if (state === undefined) {
            return;
        }

        console.log('settings state with id: ' + this.stateId + ' to ' + state + ' - caused by level:' + level + '(' + levelAck + ') and power: ' + power + '(' + powerAck + ')');
        setState(this.stateId, state);
    },

    calculateState: function(level, power) {
        if(this.lastLevel === undefined) {
            return;
        }

        if (power < 1) {
            return PositionState_STOPPED;
        }

        if (level > this.lastLevel) {
            return PositionState_INCREASING;
        } else if (level < this.lastLevel) {
            return PositionState_DECREASING;
        } else {
            return PositionState_STOPPED;
        }
    }
};

var test1 = new FibaroWindowCoverStateEmulator("Test1.Level", "Test1.Power2", "Test1.State")

JW86

~~@Paulchen67:~~

Wie schon weiter oben (08.01.2018 11:41) und in der PN an dich funktionieren die Dimmer hervorragend wenn ich sie als Door definiere.

Da ruckelt nichts, der Schieberegler macht das was mein Finger macht und das Licht wir als an angezeigt wenn ich die Dimmer anderweitig bediene (Wandschalter) `

Yahka macht keinen Unterschied zwischen Door und Dimmer. Es wird einfach nur durchgereicht.

Du kannst nun mit der Door-Lösung leben oder wir versuchen das ganze strukturiert zu analysieren.

Dazu wäre es gut wenn du bei einer Konfig bleiben würdest - am besten angelehnt an den Beitrag von dutchman.

Dann schaltest du das Debug-Log von Yahka an (weißt du wie das geht?)

Und anschließend machst du eine Aktion, bei der etwas "komisch" ist (bspw. Licht flackert) und postest das Yahka Log mit samt Beschreibung was du gemacht hast und deiner Konfig nochmal gebündelt hier.

Dann kann ich analysieren, welche Werte von Homekit kommen, welche von Homematic kommen und vielleicht herausfinden was vorsich geht.

Paulchen67

~~@JW86:~~

Du kannst nun mit der Door-Lösung leben oder wir versuchen das ganze strukturiert zu analysieren.

Dazu wäre es gut wenn du bei einer Konfig bleiben würdest - am besten angelehnt an den Beitrag von

Dann schaltest du das Debug-Log von Yahka an (weißt du wie das geht?)

Und anschließend machst du eine Aktion, bei der etwas "komisch" ist (bspw. Licht flackert) und postest das Yahka Log mit samt Beschreibung was du gemacht hast und deiner Konfig nochmal gebündelt hier.

Dann kann ich analysieren, welche Werte von Homekit kommen, welche von Homematic kommen und vielleicht herausfinden was vorsich geht. `

Wenn man das Debug-Log von Yahka extra einschalten muss, dann weiß ich nicht wie das geht.

Ich dachte im Log werden immer alle Adapter automatisch gelogt.

Wenn du mir sagst wie man den einschaltet dann mach ich das und schick dir dann alles hier.

NEWS

Yet another HomeKit adapter

Yet another HomeKit adapter

Support us

125

32.4k

81.3k

1.3m