setHue followed by forXXX

[Nico44]

Hello all from France,

First of all, thanks to every one who has been providing all these great information on this forum. I've been reading it for years and It has been a everyday helper.

Congrats also to danny bloe who has created dzVents, this is a masterpiece of software, and I'm a professional developer myself. I've always wanted to thank him, really. It has unlocked the domoticz potential so much. My house is now all I dreamt about thanks to him and all the domoticz contributors.

Now on the topic :

I've tried to use forSec, forMin subsidiary commands after a setHue on a color bulb like this :

domoticz.devices('mydevice').setHue(35, 100, false).forMin(2)

This could be very useful to push a visual notification in the main room (alarm, heavy rain, door ring etc...)

In the logs, an "attempt to call field 'forSec' (a nil value)" error shows only if I add the forXXX() command after the setHue() one. I'm on Domoticz stable 4.10717 with dzVents 2.4.19

Is this normal ? Could this be a bug ? If no, Is it planned to supported these chained commands in the futur for setHue, setColor etc...?

Thank you !

[waaren]

I've tried to use forSec, forMin subsidiary commands after a setHue on a color bulb like this :
domoticz.devices('mydevice').setHue(35, 100, false).forMin(2)
Is it planned to supported these chained commands in the futur for setHue, setColor etc...?

forXXX() is only available for switchtype commands (see this table on the wiki page). Might be that somewhere in the future it will be available but I would not wait for it.

[BOverdevest]

Maybe you can use a helper switch as an in between?
So, replace the setHeu command for a .switchOn().forMin(2) and have a separate event that is triggered (on and off) by the helper switch device

greetz

[Nico44]

Thank you both for your help.

Reading the documentation, I thought It would be available (state change) but does setHue() should be considered as an update command ? Am i reading it wrong ? Could the documentation by clearer concerning this particular point (explain what is a state change, an update, a snapshot...) ? If it is explained somewhere, please ignore this message.

I would love to see this function implemented and I'm curious to know how difficult It would be...

[Nico44]

BOverdevest,

I'm using it already for non-colored bulbs and It works perfect. However, I thought It would be more meaningfull to notify inhabitants by flashing a color bulb with a temporary color change (ex. for 2 min) and then revert back to the previous state, which can be more complex than just ON/OFF/Dimming level.

That's why forXXX was the perfect candidate to set this up.

Have a great day.

[waaren]

I would love to see this function implemented and I'm curious to know how difficult It would be...

Quite difficult... The forXXX is like other methods (afterXXX, withinXXX, silent) a dzVents "translation" of functionality domoticz offers.
To implement this for commands like setHue the before value need to be stored somewhere to enable restoring the old state.

I did create a dzVents script once that changed Hue of a light and restored the original Hue after some time. When I find it again I will post it here.

[waaren]

Can you try ths one ?

Code: Select all

return 
{  
    on =   
    { 
        devices =
        {
            'myTrigger'
        },
    },

    logging =
    {
        level   = domoticz.LOG_DEBUG,  -- switch to LOG_ERROR when
        marker      = 'hueFor'
    },
      
    execute = function(dz, item)

        local myLight = dz.devices(156)  -- Your hue light idx or "name"
        local myDelay = 10 -- seconds delay before restoring old color
       
        local blinkHue = 300
        local blinkBrightnes = 40
       
        local function restoreColor(device, delay)
            local url = dz.settings['Domoticz url'] ..
                        '/json.htm?type=command&param=setcolbrightnessvalue' ..
                        '&idx=' .. device.id   .. '&brightness=' .. device.level .. '&color=' .. device.color

            dz.openURL(url).afterSec(delay)
            device.switchOn().afterSec(delay+1) --Force store of device.color in domoticz database
            dz.log('Color will be restored to ' .. device.color .. '( brightness: ' ..device.level ..') after ' .. delay  .. ' seconds.',dz.LOG_DEBUG )
        end

        restoreColor(myLight, myDelay)
        myLight.setHue(blinkHue,blinkBrightnes)

    end
}

[Nico44]

Can you try ths one ?

Code: Select all

return 
{  
    on =   
    { 
        devices =
        {
            'myTrigger'
        },
    },

    logging =
    {
        level   = domoticz.LOG_DEBUG,  -- switch to LOG_ERROR when
        marker      = 'hueFor'
    },
      
    execute = function(dz, item)

        local myLight = dz.devices(156)  -- Your hue light idx or "name"
        local myDelay = 10 -- seconds delay before restoring old color
       
        local blinkHue = 300
        local blinkBrightnes = 40
       
        local function restoreColor(device, delay)
            local url = dz.settings['Domoticz url'] ..
                        '/json.htm?type=command&param=setcolbrightnessvalue' ..
                        '&idx=' .. device.id   .. '&brightness=' .. device.level .. '&color=' .. device.color

            dz.openURL(url).afterSec(delay)
            device.switchOn().afterSec(delay+1) --Force store of device.color in domoticz database
            dz.log('Color will be restored to ' .. device.color .. '( brightness: ' ..device.level ..') after ' .. delay  .. ' seconds.',dz.LOG_DEBUG )
        end

        restoreColor(myLight, myDelay)
        myLight.setHue(blinkHue,blinkBrightnes)

    end
}

Brillant ! This is working ! I did not think about calling a restore function BEFORE calling my notification event. I allows saving all current parameters and using of afterSec subsidiary command on openUrl. I also did not know about forcing storage of device data by calling switchOn() function.

Also on another subject, I suspected not a while ago dz.settings['Domoticz url'] to be hard coded and after some research, I discovered that it was (to 127.0.0.1). The calling of some functions (like setHue) was failing because I'm not using localhost in my particular setup.

Is this right ? I mean, I'm certainly not the only one not using localhost. Shouldn't this parameter be retrieved from the domoticz settings menu (It would require to add it, because It is missing right now on stable) ?

Thanks a lot for your time and contribution.

[waaren]

Also on another subject, I suspected not a while ago dz.settings['Domoticz url'] to be hard coded and after some research, I discovered that it was (to 127.0.0.1). The calling of some functions (like setHue) was failing because I'm not using localhost in my particular setup.

Is this right ? I mean, I'm certainly not the only one not using localhost. Shouldn't this parameter be retrieved from the domoticz settings menu (It would require to add it, because It is missing right now on stable) ?

I understand your remark but by far most people use 127.0.0.1 and dzVents needs password less acces to it. From the wiki:

Also make sure that in the Security section in the settings (Setup > Settings > System > Local Networks (no username/password) you allow 127.0.0.1 to not need a password. dzVents uses that port to send certain commands to Domoticz.

I would not know how to change this without breaking stuff for existing users.