@Mic said in Planung neuer Adapter: Smart Control:

Ich verstehe deinen Use-Case nicht ganz, also z.B.

0 ms: Bewegung löst aus (zigbee.0.XXX.occupancy -> true). Derzeitige Helligkeit (lt. zigbee.0.XXX.illuminance z.B. 30)
5 ms: Der Adapter liest die Helligkeit (30) und stellt fest, sie ist unterhalb von z.B. 60 --> also soll geschaltet werden.
10 ms: Licht wird eingeschaltet.
500 ms: Helligkeit (zigbee.0.XXX.illuminance) ist jetzt 500

Wüsste jetzt nicht, warum man hier einen Timestamp zum Vergleich bräuchte? Helligkeit wird ja ermittelt, bevor geschaltet wird, daher ist doch die Verzögerung hier egal.

Der Aqara Sensor aktualisiert Lux-Wert nur wenn eine Bewegung erkannt wird. Mein Problem ist, dass das Script (in meinem Fall) nicht mit dem aktuellen Helligkeitswert arbeitet. Es wartet ja nicht, bis dieser aktualisiert wird, sondern prüft einfach nur. Wenn der Lux-Datenpunkt aber erst nach dieser Prüfung mit dem aktuellen Wert beschrieben wird (ist bei mir so, denn ich benutzte ein eigenes Script zum Beschreiben der Datenpunkte, die Werte werden aus einem Json Objekt geparst, welches ich über mqtt empfange. Dieses Objekt ist so aufgebaut, dass Lux-Wert als letztes Element vorkommt) Die Zeitverzögerung zwischen Beschreiben von Occupancy und Lux habe ich nicht gemessen, bin mir aber ziemlich sicher, dass das aquara-motion-control Script die Prüfung schneller ausführt...
Ich hoffe, ich habe mein Problem ausführlich beschrieben.
Ich könnte meinen Parser auch so abändern, dass der Lux-Datenpunkt vor dem Occupancy beschrieben wird, finde aber dass eine Timestamp Prüfung hier sinnvoll ist. Es wird bestimmt noch Leute mit ähnlichen Timing Problemen geben...

Viele Grüße

Siehe dir folgenden Adapter an:
https://github.com/Mic-M/ioBroker.smartcontrol
bzw folgendes Script:
https://github.com/Mic-M/iobroker-xiaomi-aquara-motion-control

@Sk4ll
Schau unter
javascript.0.Heizung.Heizplan
Dort sind deine angelegten Zimmer gelistet. Jedes Zimmer hat eigene(s) Profil(e), auf diese Datenpunkte greift die Vis zu.

@Sk4ll
Hi, ich benutze noch dieses Script und bin vor einiger Zeit aufs gleiche Problem gestoßen.
Werden Zeiten über Vis angepasst, so kommt es zu dem von dir beobachteten Verhalten.
Das Format der Zeitpunkte wird von hh:mm:ss auf hh:mm geändert und kann
vom Script nicht mehr richtig verarbeitet werden. Bitte Kontrolliere alle Datenpunkte und passe die Zeitangaben an.
z.B. 06:00 --> 06:00:00 etc.

VG,
Max

@butsch
Habe das Problem gefixt, das Script wirft keine Warnings mehr bei mir.

const JSPath = "javascript.0"                              // JS- Pfad
const parsedStatesPath   = JSPath + ".zigbee2mqtt"         // Pfad fuer geparste States
const zigbee2mqttJsonPath = "mqtt.0.zigbee2mqtt"           //Pfad fuer zigbee2mqtt Json Objekte
let IDs = [];


$("[id=" + zigbee2mqttJsonPath + ".*]").each(function (id) {
    IDs.push(id)
})
on({id: IDs, change: "ne"}, function (obj) {
    let JsonObj = JSON.parse(obj.state.val)
    Object.keys(JsonObj).forEach(function(key){
        let currState = obj.id.replace(zigbee2mqttJsonPath, parsedStatesPath) + "." + key
        if (getState(currState).notExist){
            createState(currState, JsonObj[key], {read: true, write: true, type: typeof(JsonObj[key]), name: '' , desc: ''},function(){
                setState(currState, JsonObj[key]);
        })
        }else {
            setState(currState, JsonObj[key])
        };
    })
})

@butsch
Die Warnings bekomme ich auch seit einiger Zeit. Das Script funktioniert aber weiterhin ohne Probleme bei mir. Muss ich mal bei Gelegenheit debuggen, es fehlt leider im Moment die Zeit...

@butsch

const JSPath = "javascript.0"                              // JS- Pfad

const parsedStatesPath   = JSPath + ".zigbee2mqtt"         // Pfad fuer geparste States

const zigbee2mqttJsonPath = "mqtt.0.zigbee2mqtt"           //Pfad fuer zigbee2mqtt Json Objekte

Man muss nur die o.g. Pfade anpassen.
JSPath ist hierber der Pfad zu javascript Instanz, welche das Script ausführt.
zigbee2mqttJsonPath ist der Pfad, wo Json Objekte von zigbee2mqtt landen.
parsedStatesPath ist der Pfad für die geparsten Datenpunkte.
Die Datenpunkte werden erst angelegt, wenn Json Objekte geändert werden - etwas Geduld ist hier also gefordert

@Mic said in Planung neuer Adapter: Smart Control:

Ich verstehe deinen Use-Case nicht ganz, also z.B.

0 ms: Bewegung löst aus (zigbee.0.XXX.occupancy -> true). Derzeitige Helligkeit (lt. zigbee.0.XXX.illuminance z.B. 30)
5 ms: Der Adapter liest die Helligkeit (30) und stellt fest, sie ist unterhalb von z.B. 60 --> also soll geschaltet werden.
10 ms: Licht wird eingeschaltet.
500 ms: Helligkeit (zigbee.0.XXX.illuminance) ist jetzt 500

Wüsste jetzt nicht, warum man hier einen Timestamp zum Vergleich bräuchte? Helligkeit wird ja ermittelt, bevor geschaltet wird, daher ist doch die Verzögerung hier egal.

Der Aqara Sensor aktualisiert Lux-Wert nur wenn eine Bewegung erkannt wird. Mein Problem ist, dass das Script (in meinem Fall) nicht mit dem aktuellen Helligkeitswert arbeitet. Es wartet ja nicht, bis dieser aktualisiert wird, sondern prüft einfach nur. Wenn der Lux-Datenpunkt aber erst nach dieser Prüfung mit dem aktuellen Wert beschrieben wird (ist bei mir so, denn ich benutzte ein eigenes Script zum Beschreiben der Datenpunkte, die Werte werden aus einem Json Objekt geparst, welches ich über mqtt empfange. Dieses Objekt ist so aufgebaut, dass Lux-Wert als letztes Element vorkommt) Die Zeitverzögerung zwischen Beschreiben von Occupancy und Lux habe ich nicht gemessen, bin mir aber ziemlich sicher, dass das aquara-motion-control Script die Prüfung schneller ausführt...
Ich hoffe, ich habe mein Problem ausführlich beschrieben.
Ich könnte meinen Parser auch so abändern, dass der Lux-Datenpunkt vor dem Occupancy beschrieben wird, finde aber dass eine Timestamp Prüfung hier sinnvoll ist. Es wird bestimmt noch Leute mit ähnlichen Timing Problemen geben...

Viele Grüße

Ich nutze selber zigbee2mqtt seit langem, weil es einfach stabiler lief als der zigbee Adapter.
Hier ist ein kleines Script von mir zum parsen der Json-Objekte vom zigbee2mqtt:

const JSPath = "javascript.0"                              // JS- Pfad
const parsedStatesPath   = JSPath + ".zigbee2mqtt"         // Pfad fuer geparste States
const zigbee2mqttJsonPath = "mqtt.0.zigbee2mqtt"           //Pfad fuer zigbee2mqtt Json Objekte
let IDs = [];


$("[id=" + zigbee2mqttJsonPath + ".*]").each(function (id) {
    IDs.push(id)
})
on({id: IDs, change: "ne"}, function (obj) {
    let JsonObj = JSON.parse(obj.state.val)
    Object.keys(JsonObj).forEach(function(key){
        if (getState(obj.id.replace(zigbee2mqttJsonPath, parsedStatesPath)).notExist){
            createState(obj.id.replace(zigbee2mqttJsonPath, parsedStatesPath) + '.' + key, JsonObj[key], {read: true, write: true, type: typeof(JsonObj[key]), name: '' , desc: ''},function(){
                setState(obj.id.replace(zigbee2mqttJsonPath, parsedStatesPath) + '.' + key, JsonObj[key])
        })
        }else {
            setState(obj.id.replace(zigbee2mqttJsonPath, parsedStatesPath) + '.' + key, JsonObj[key])
        };
    })
})

Viel Spaß damit

Hey Mic,

ich nutze dein aqara motion control script (mit einigen Anpassungen) seit Version 0.1 und bin super zufrieden mit dem Funktionsumfang und Zuverlässigkeit.
Das Einzige, was bei mir nie so richtig funktioniert hat (hat Nichts mit deinem Script zu tun ) ist die helligkeitsbezogene Steuerung.
Ich habe Aqara RTCGQ11LM Sensoren, welche ich mittels zigbee2mqtt und ein Paar Zeilen Code ins iobroker eingebunden habe. Das Problem, das im Zusammenhang mit deinem Script auftritt ist Folgendes:
Die Lux-Datenpunkte werden etwas später geschrieben als Occupancy. Das Script prüft den Lux-Wert, jedoch nicht sein Timestamp, was in meinem Fall zur Verarbeitung nicht aktueller im Script Lux-Werte führt.
Eine mögliche Lösung wäre die Timestamps zu vergleichen. Sollte Lux-Timestamp um mehr als x (Milli)Sekunden in der Vergangenheit liegen, wird maximal y (Milli)Sekunden auf Aktualisierung des Lux-Datenpunkts gewartet, oder so ähnlich...
Des Weiteren wäre ein gewisses "misbehaviour-handling" wünschenswert, wenn zum Beispiel der Occupancy-Datenpunkt nicht auf False gesetzt wird. Hier könnte man zwischen "nichts tun" und "in z Minuten ausschalten" wählen.
Und zum Schluss: wird die Konfiguration nur statisch im Adapter vorgenommen oder auch mittels Datenpunkte?

Viele Grüße,
Max

@TDCroPower:

naja der aktuelle Offset ist eigentlich egal solange das Script dauerhaft die Werte regelt.

Sobald eine negative Differenz vorhanden ist wird der Offset Wert sowieso überschrieben. `

Ohne berücksichtigung des aktuellen Offsets wird das Nichts…

Zahlenneispiel:

1)Offset = 0

HKT = 20°C

EXT = 18°C

--> Offset = 18 - 20 = -2

2. Offset = -2* HKT = 18°C

   EXT = 18°C

   –> Offset = 18 - 18 = 0

   3. Offset = 0

   HKT = 20°C

   EXT = 18°C

   --> Offset = 18 - 20 = -2

   etc.

   Nun unter Einbeziehung des Offsets (HKT - EXT + Offset)

   1)Offset = 0

   HKT = 20°C

   EXT = 18°C

   --> Offset = 18 - 20 + 0 = -2

   2. Offset = -2

   HKT = 18°C

   EXT = 18°C

   --> Offset = 18 - 18 + (-2) = -2

   3. Offset = -2

   HKT = 18°C

   EXT = 18°C

   --> Offset = 18 - 18 + (-2) = -2

   Offset konvergiert hier gegen -2...

   Grüße