Domoticz

Hi,

I'd like to run a script which would trigger some actions with some delays between steps. Something like:
1) send Down command to device A (RFLink)
2) wait for 13.75s
3) send STOP command to device A (RFLink)
4) Switch off light on device B
5) submit URL request (to command another device)
6) wait for 5s
7) submit another URL request

I had built a bash script for another need where I was using a tempo ('perl -e "select(undef,undef,undef,$duration);"'), but it was a short one (1s for each step, and total duration was not exceeding 6s).

Now, with the sequence I want above, total duration would be very long: almost 20s and I'm afraid Domoticz would kill the script after 10s (that's the limit, correct ?) and moreover, I wouldn't want to suspend Domoticz during 20s as it could prevent Domoticz from running some planned actions (Murphy's law..).

So, what would you advise me to do ?

NB: I use Domoticz on a Raspberry Pi2.
br,
Ricorico94

Call the script with a intermediate script.
Like ex in domoticz: /path/to/script/placeholder.sh &
and in placeholder.sh: /path/to/script/realscript.sh

In the domoticz link you add a & to tell shell not to wait for the end of the script, that way domoticz thinks the script is instantly ready.
In the realscript.sh you can do whatever you want with sleeps etc.

Thanks a lot Egregius. I'll try that

Egregius wrote:Call the script with a intermediate script.
Like ex in domoticz: /path/to/script/placeholder.sh &
and in placeholder.sh: /path/to/script/realscript.sh

In the domoticz link you add a & to tell shell not to wait for the end of the script, that way domoticz thinks the script is instantly ready.
In the realscript.sh you can do whatever you want with sleeps etc.

Just out of curiosity. Is it best practice to use a intermediate script? What are the advantages compared to calling the real script directly?

Because you put a & at the end of the command to execute the script in the background so domoticz doesn't wait for it to finish.

But then you could also use /path/to/script/realscript.sh & directly from Domoticz isn't it?

Probably, should be tested.
I don't use bash scripts or on/off actions.

Maybe there are some other considerations but from the basic functionality viewpoint I don't see any need to use an intermediate script. Just call the main script and add & at the end. If simple on/off actions are not enough, you can call the script with LUA based on whatever conditions you want (e.g. temperature goes over / under something etc.) with:

@Nautilus : What do you mean by calling the script with LUA ? Only in case a LUA script is requiring a longer script, then the LUA script would call this long action through .sh script ? Or do you mean that I should always first trigger a LUA script when I want the sequence activated which would call the sh script ?

ricorico94 wrote:@Nautilus : What do you mean by calling the script with LUA ? Only in case a LUA script is requiring a longer script, then the LUA script would call this long action through .sh script ? Or do you mean that I should always first trigger a LUA script when I want the sequence activated which would call the sh script ?

With the above I meant that yes you can use the on / off action to trigger the .sh "sequence" script if this suits your purpose. But in case you need to build a more complex logic of when the sequence script would be triggered, then I'd use LUA for triggering it.I have e.g. some vocal announcement scripts that take long time to run and for those I need to first set the A/V receiver to correct input and volume level (and put it back to that input as well, but this is handled with a parameter passed to the .sh script) which I solved by creating a LUA script which does first all sorts of things and then at the end triggers the vocal announcement .sh script.

So yes, "Only in case a LUA script is requiring a longer script, then the LUA script would call this long action through .sh script"

Egregius wrote:Probably, should be tested.
I don't use bash scripts or on/off actions.

Thats exactly what you posted

You ment to call the longlasting script with the & from the intermediate script...

Thats also a common practice usrd in eg crontab.

Sent from my D6603 using Tapatalk

ok, thanks again for all explanations. Now it sounds clear.
In case I want to pass parameters to scripts, I should use the following command ?
os.execute('/path/to/script/script.sh param1 param2 &')
(ie parameters between name of script and the "&" ?)

Correct. Though if and when the parameters are coming from variables it needs to be something like:

os.execute('/home/pi/domoticz/scripts/tts2.sh "' .. sentence .. '" ' .. status .. ' &')

In this example sentence contains multiple words, hence the extra double quotes, and status is single word (sentence = what the vocal announcement will be, satus = current receiver input to which it needs to return after reading the sentence...)

ricorico94 wrote:I'm afraid Domoticz would kill the script after 10s (that's the limit, correct ?)

I used the bluetooth exemple from the wiki (slightly modified) to check presence when familiy members phones are reachable. That's OK when phones can be reached, but when not, "hcitool names" command used by the BT check is longer to answer and does not provide any tunable timeout.

So I exceed a little bit the 10s delay when at least 2 phones cannot be reached: That's only a warning in the logs, but as time scripts are runned every minute I would also like another solution: Adding more phones checks could lead to a script reaching the minute delay with domoticz unable to do anymore task.

One solution could be to have a task completely separate from domoticz monitoring BT devices presence in the background and able to report only presence change in a domoticz virtual switch for instance.

lost wrote: One solution could be to have a task completely separate from domoticz monitoring BT devices presence in the background and able to report only presence change in a domoticz virtual switch for instance.

In fact, I found a python base (not targeting Domoticz on the notify side, but modifications were an easy job even for a python early beginner like me!) code doing this... And using requests python module on dictionaries containing (updatable) JSON API elements allowed making get requests the "params" way (automatically transforms dictionnaries like domo_get={'type':'command', 'param':'switchlight', 'idx':'99'...} to extend an url as "type=command&&param=switchlight&&idx=99...") very easily!

A tip that should IMO make it's way in the wiki.

And this way, domoticz is only notified on status change and time between checks can be tuned more easily (for instance only check found nearby devices every 10mn to preserve battery from too frequent pings and those not found every 15sec, to minimize alarm delay if a motion detector trigs vs BT device presence detection for instance).

This also adds the possibility to have other checks for the found device itself on top of just a (spoofable) BT MAC address that is periodically pinged for presence (something a smart thieve may check & try to tamper).