Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable / Disable Scene from VIS/Script #164

Open
Streit187 opened this issue May 9, 2022 · 2 comments
Open

Enable / Disable Scene from VIS/Script #164

Streit187 opened this issue May 9, 2022 · 2 comments

Comments

@Streit187
Copy link

I`m using a Scene for the Night to close some blinds and dimm some lights. This is configured with cron to true or false the scene.
Befor I go on holiday I turn off (disable) the scene in the adapter. I would like to have the possibility to do this script and vis based.
Means it would be great to have for example an additional state to enable/disable a scene or a 4th value for the existing like true/false/uncertain/disable.

@Streit187 Streit187 changed the title Enable / Disable Scene from with Enable / Disable Scene from VIS/Script May 9, 2022
@jbubik
Copy link

jbubik commented Jul 25, 2022

Hi @Streit187, nice request. I had a similar scenario and disabling the scene didn't come to my mind.

From script this can work for you (set enabled:true or enabled:false to enable/disable the scene):

extendObject('scene.0.myfolder.myscene', {common: {enabled: false}}, function (err) {
    if (err) log('Cannot write object: ' + err);
});

Please mind, that you must enable special configuration Enable command "setObject" in your javascript adapter to enable setObject/extendObject calls. Once enabled, javascript can modify your objects. It's your risk if you enable.
And also mind there are Access Control Lists (Owner/Group/Everyone) for every scene (see Objects tree under scene.0. ...) So it may need some changes if called from VIS (not tested in my deployment).

@Apollon77: the suggested additional States "disable object" / "enable object" would be similar to the Absent value and would be a global change in ioBroker mechanisms. A local change in iobroker.scenes is much safer not to break things.
Idea1 is to create for each scene.0.myscene a second boolean object scene.0.myscene_enabled. getState on this new object would return the value .common.enabled of the parent object. setState on this new object would set the value .common.enabled on the parent object. I worry about unique identifiers though. So maybe these new objects could live in a completely different sub-tree (scene_state.0.myscene) or in a dedicated folder (scene.0.states.myscene)???
Idea2 the value for setState can be either boolean/numeric/string or it can be a Json array like {val:true, ack:true, ts: ..., lc: ...}. The declaration allows for the array to contain member c - a comment. A special string in this comment could signal to iobroker.scenes that it is the change of scene's status. Eg setting {val:true, c: "scene status"} wouldn't trigger the scene, but enable it's status. And setting {val:false, c: "scene status"} would disable it. This special comment should be language independent (English only) to be the same in all deployments.

Just my thoughts so others can comment. Regards Jan

@jbubik
Copy link

jbubik commented Jul 25, 2022

Idea3 I have seen this code in README.md for manipulation of a scene:

sendTo(
    'scenes.0', 
    'save', 
    {sceneId: 
        'scene.0.SCENE_ID', // scene ID 
        isForTrue: true     // true if actual values must be saved for `true` state and `false` if for false 
    }, 
    result => result.err && console.error(result.error) // optional
);

I believe the new API for enabling a scene could be:

sendTo(
    'scenes.0', 
    'enable', 
    {sceneId: 
        'scene.0.SCENE_ID' // scene ID 
    }, 
    result => result.err && console.error(result.error) // optional
);

For disabling a scene this may be the call:

sendTo(
    'scenes.0', 
    'disable', 
    {sceneId: 
        'scene.0.SCENE_ID' // scene ID 
    }, 
    result => result.err && console.error(result.error) // optional
);

Implementation expected in main.js around line 155. Makes sense?

GermanBluefox added a commit that referenced this issue Feb 13, 2024
#164

This update adds the capacity to enable or disable scenes via message commands, assisting issue #164. Changes include modifications to the README.md to reflect this new feature and adjustments to the main.js file to handle these new commands. Additional improvements include efficient scene saving using async functions, the elimination of callback hell, and string checks to better handle messages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants