Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen

[Mic]

@liv-in-sky
Klar, die Einstellung betrifft auch nur:

Du hast da aber einen Adapter. Bestätigt dieser Adapter "control-own" denn nicht sauber den Datenpunkt mit ack:true? Denn das wäre gemäß https://forum.iobroker.net/post/448606 dann ein Fehler/Optimierungsbedarf dieses "control-own" Adapters.

[liv-in-sky]

@Mic meine datenpunkte liegen unter controll-own.0 - ist ein eigener ordner - könnte man da noch einbauen, dass man selber welche definieren kann

[Mic]

@liv-in-sky sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

meine datenpunkte liegen unter controll-own.0

Hmm, das entspricht aber nicht den ioBroker-Regeln, also eigene Datenpunkte dürfen nur unter 0_userdata.0 oder javascript.x sein...

[liv-in-sky]

@Mic userdata.0 kam erst nach einigen jahren - hatte mir damals das angelegt

[liv-in-sky]

@Mic wollte mir den umzug von fast 700 eigenen datenpunkten ersparen

[Mic]

@liv-in-sky sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

@Mic userdata.0 kam erst nach einigen jahren - hatte mir damals das angelegt

Verstehe ich gut
Ich nehme es mal auf die Liste, aber nicht mit hoher Prio (weil eben nicht der ioBroker Spezifikation entsprechend), erst sind noch andere Dinge dran

[Homoran]

@Mic sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

eigene Datenpunkte dürfen nur unter 0_userdata.0 oder javascript.x sein...

Neee

Meine liegen auch unter Messwerte.0 oder Sytemvariablen.0

[liv-in-sky]

@Mic vielleicht könntest du die prio ein wenig höherschrauben es gibt vielleicht mehr von uns "assi-usern"

[Mic]

@Homoran sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

Meine liegen auch unter Messwerte.0 oder Sytemvariablen.0

Verstehe.

@liv-in-sky
Ach Quatsch, alles gut , du und @Homoran und wohl einige weitere haben die wohl halt einfach angelegt, auch weil es geht in den Objekten und aus Übersichtlichkeit.

Ich schau mal. Idealerweise prüfe ich, ob hinter dem Hauptdatenpunkt "Messwerte.0" etc. ein "echter" Adapter ist, wenn ja, dann "ack:true", wenn nicht, dann kann zieht er die Einstellung von

[liv-in-sky]

@Mic

klasse idee

[Homoran]

@Mic sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

weil es geht in den Objekten

zumindest ging es früher - jetzt nicht mehr (so einfach).

@Mic sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

und aus Übersichtlichkeit.

Ganz genau!

Natürlich muss man aufpassen, dass später nicht ein Adapter diesen Namespace belegt. Dann muss es Tatsächlich unter 0_userdata.0 - würde aber alles noch eine Ebene tiefer verschachteln.

[liv-in-sky]

@Mic mic sollte der alias ordner nicht eventuell auch integriert werden ???

[MartyBr]

@liv-in-sky
@Mic
Habe hier den passenden Fehler:

[MartyBr]

@Mic
Das hier wirft er aus:

Ich glaube, das betrifft fast alle nördlich von Hannover, insbesondere die Nordlichter.

[Mic]

@liv-in-sky sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

@Mic mic sollte der alias ordner nicht eventuell auch integriert werden ???

Bau ich auch gleich mit ein, danke. Werde jetzt umsetzen, Update folgt bald.

[Mic]

@liv-in-sky
@Homoran

Anderes Acknowledge für eure eigenen Datenpunkte wie unter "Messwerte.0" ist jetzt eingebaut, ebenso inklusive alias.0, etc.

Siehe Version 0.1.0-alpha.7 auf Github.

Falls es interessiert, so mache ich das jetzt:

    /**
     * Verify acknowledge (ack) once a state was changed.
     * 
     * In General: Any state changes of states will be ignored, if acknowledge (ack) = false.
     * The reason is that adapters confirm states by the acknowledge "ack" flag (setting to true).
     * Reference: https://forum.iobroker.net/post/448606
     * 
     * Exception 1: States under javascript.x/0_userdata.0/alias.x: For states created by users under, this behavior can be changed in the adapter options.
     * Exception 2: States under smartcontrol.x.: ack:false only.
     * Exception 3: States which are not under a "real" adapter namespace, so like "Messwerte.0". Reason: Several users have created 
     *              own states in the object main tree, like "Messwerte.0". https://forum.iobroker.net/post/461189
     * 
     * @param {string}                          statePath   - State Path
     * @param {ioBroker.State|null|undefined}   stateObject - State object
     * @return {Promise<boolean>}               false if state change shall be ignored due to the ack (or error occurred), otherwise true.
     * 
     */
    async isAckPassing(statePath, stateObject) {

        try {

            if(!stateObject || !statePath) return false;            

            const namespace = `${statePath.split('.')[0]}.${statePath.split('.')[1]}`; // like sonos.1

            let isUserState = false;
            if (statePath.startsWith('javascript.') || statePath.startsWith('0_userdata.0') || statePath.startsWith('alias.')) isUserState = true;

            if(!isUserState) {
                // Check if state is under a "real" adapter namespace.
                const isRealAdapter = await this._adapter.getForeignObjectAsync(`system.adapter.${namespace}`);
                if (!isRealAdapter) isUserState = true;
            }

            if (isUserState) {

                if (!this._adapter.config.triggerStatesAck || this._adapter.config.triggerStatesAck == 'false') {
                    if (stateObject.ack == false) {
                        return true;
                    } else {
                        return false;
                    }
            
                } else if (this._adapter.config.triggerStatesAck == 'true') {
                    if (stateObject.ack == true) {
                        return true;
                    } else {
                        return false;
                    }
                } else {
                    // any (ack: true or false)
                    return true;
                }

            } else if (statePath.startsWith(`${this._adapter.namespace}.`)) {
                // Any states under this adapter instance, we require ack = false;
                if (stateObject.ack == false) {
                    return true;
                } else {
                    return false;
                }
            } else {
                // For any other "real" adapter state changes, we require ack = true
                if (stateObject.ack == true) {
                    return true;
                } else {
                    return false;
                }
            }
        
        } catch (error) {
            this.dumpError('[isAckPassing()]', error);
            return false;
        }

    }
```

[Mic]

@MartyBr sagte in Aufruf: Neuen SmartControl-Adapter 0.1.0-alpha.x testen:

@liv-in-sky
@Mic
Habe hier den passenden Fehler:

Schau mal bitte ob es jetzt geht mit 0.1.0-alpha.7

[MartyBr]

@Mic Bin gerade am installieren. Das geht ja wahnsinnig schnell voran

[MartyBr]

@Mic
Bisher sieht es gut aus. Der Zeit-Trigger macht Probleme:

[Mic]

@MartyBr
sehr gut schon mal.

Zur Fehlermeldung:
Ist der Trigger (=Auslöser) sowohl unter "4. ZONEN" eingebunden und gibt es auch eine gültigen Eintrag unter "5. ZEITPLÄNE"?

Falls alles ja: Bitte mach folgendes:

Also lade die Konfig herunter und poste sie hier in Code-Tags. Achtung: Vorher ggf. um personenbezogene Sachen bereinigen...
Danke