Enable / Disable all events in a switch planning alltogether

[gizmocuz]

In the settings you can change the timer plan.
Currently normal/holiday, you then get new timers in both modes.
The idea was to extend this further, so you can create your own plans like 'Winter' or 'October'

[maluko]

thanks for the answer, but i dont want to put new timers on diferent mode.
i was thinking that could put a switch that disable all timer of scene because we are in the transition stage of the season it rains and the sun shines ,so turn off all sprinkler scene timers was easily best a button.

thanks.

[furio49]

hello,
here the /json.htm?type=command&param=disabletimer&idx=X or enabletimer don't work
I receive the OK prompt
{
"status" : "OK",
"title" : "DisableTimer"
}
but the timers are always active.
The Domoticz version is 5641
I want to try a script for modify the status (active=0 or 1) in the table Timers
but If I test with sql3lite the table Timers the result is empty !!
But I have my timers active in 2 virtual thermostat
What happen ? where did I go wrong?

[furio49]

solved (half)

the API /JSON dont't work (a bug)

the timer table is setpointtimers and not timers !!

then the scripts are:

---for timers active ------
#!/bin/bash
sqlite3 /home/pi/domoticz/domoticz.db 'update setpointtimers set active=1 where devicerowid = <number of the device>;'

---for timers NOT active ------

#!/bin/bash
sqlite3 /home/pi/domoticz/domoticz.db 'update setpointtimers set active=0 where devicerowid = <number of the device>;'

this is the solution for handle the timers

[maluko]

thanks furio-49

How can i disable all scene timers with this scripts?

[Eduard]

hello,
here the /json.htm?type=command&param=disabletimer&idx=X or enabletimer don't work
I receive the OK prompt
{
"status" : "OK",
"title" : "DisableTimer"
}
but the timers are always active.
The Domoticz version is 5641
I want to try a script for modify the status (active=0 or 1) in the table Timers
but If I test with sql3lite the table Timers the result is empty !!
But I have my timers active in 2 virtual thermostat
What happen ? where did I go wrong?

I think you have to use the idx of the timer instead of the device

[lost]

2. I wrote two bash scripts, one to turn all events from my real switch to "Active", the other one to turn them to "Inactive": (in this example, "Talus" is the name of my real switch)

Code: Select all

#!/bin/bash
sqlite3 /home/pi/domoticz/domoticz.db 'update timers set active=1 where devicerowid in (select id from devicestatus where name = "Talus");'

and

Code: Select all

#!/bin/bash
sqlite3 /home/pi/domoticz/domoticz.db 'update timers set active=0 where devicerowid in (select id from devicestatus where name = "Talus");'

Hello,

Looking for a solution to this problem, I found your post: I wanted to be able to invalidate all heaters schedules globally for some switches (some windows change to do on 2 days, one day per floor, and dit not want to heat the outside!) & set them to off.

For the schedules, I used your trick. Seems to work when reading schedules... but later in the day, schedules were activated again and while working heaters went back on a programmed schedule! Quite annoying as some of them were under a protection and may have overheated if I did not saw the problem immediately.

My bet: We change some db settings in the back of Domoticz, while running thus probably not recommended, and it probably use an internal cache and rewrites the db from time to time (to save graphs data...). Then modifications done in the db gets overwritten and next schedules are handled again!

Do you have the problem on your side?

Anyway, that's really a missing feature:
viewtopic.php?f=31&t=14172

BR

[lost]

I think you have to use the idx of the timer instead of the device

You're correct, I tried this because with switch idx it was not working. The problem is any schedule for a switch = 1 timer idx!
So when you have 10's of lines in a schedule that's the same amount of idx to identify & modify...

So I used the db trick but got into other problems. Still a missing feature IMO.

BR

[nizaga]

hello,

i was having the same issue and i was getting crazy!!!

you need to use the if of the timer, not of the device....

yo get the id of the timer there are several ways.... i use a plugin in firefox called Live HTTP Hearders so you can check the url by clicking...

regards,

nim

[lost]

hello,

i was having the same issue and i was getting crazy!!!

you need to use the if of the timer, not of the device....

yo get the id of the timer there are several ways.... i use a plugin in firefox called Live HTTP Hearders so you can check the url by clicking...

regards,

nim

On my side, I wrote some python stuff using json API do be able to invalidate/validate device(s) planning. As wildcards are supported, if you have a naming convention this allows changing several devices plannings activations at once.

http://www.domoticz.com/forum/viewtopic ... 05#p109305

There is an auto-reverse done currently in combination with a lua time script that can be skipped and should be enhanced. Maybe the best way would be to make the python script a service, so able to keep an history and for which domoticz should send commands, allowing to be able to reverse more than 1 devices set.

[philchillbill]

EDIT: A better way of doing this has been subsequently posted.

I wrote a perl script that you can run once to automatically generate a bash script that you can then use in Domoticz to bulk enable/disable your timer schedules. It uses LWP::UserAgent to query Domoticz idx values for timer schedules and builds a bash file with the results. You can edit that file by hand to remove any entries you don't want switching when the bash runs. If you set up a dummy switch called e.g. "Away" and set the on/off parameters to run a "script://" pointing to this bash file, you can bulk enable or disable all the timer schedules depending on whether you supply a 0 or 1 together with the script. Here's an example of the bash file produced:

Code: Select all

#!/bin/sh
# Domoticz bash script to bulk enable/disable schedules for switch timers

if [ "$1" = "1" ]
then
  ACTION="enabletimer"
elif [ "$1" = "0" ]
then
  ACTION="disabletimer"
else
  curl -s "http://192.168.178.12:8080/json.htm?type=command&param=addlogmessage&message=Invalid%20parameter%20sent%20to%20timer%20schedule%20script"
  echo "Invalid parameter - please run script followed by 0 or 1 only"
  exit 1
fi

# Add an entry to the Domoticz logfile to indicate whether we are now enabling or disabling timer schedules
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=addlogmessage&message=$ACTION"


# Bedroom Lamp -- On Time -- 22:00 (idx 3)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=3"

# Bedroom Lamp -- On Time -- 23:30 (idx 4)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=4"

# Bedroom Lamp -- On Time -- 23:56 (idx 31)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=31"

# Guestroom Lamp -- After Sunset -- 03:00 (idx 5)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=5"

# Guestroom Lamp -- After Sunset -- 04:00 (idx 6)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=6"

# Guestroom Lamp -- After Sunset -- 04:30 (idx 7)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=7"

# Guestroom Lamp -- After Sunset -- 06:00 (idx 28)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=28"

# Guestroom Lamp -- On Time -- 23:45 (idx 40)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=40"

# Guestroom Lamp -- On Time -- 23:56 (idx 33)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=33"

# Kitchen Lights -- After Sunrise -- 00:20 (idx 39)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=39"

# Kitchen Lights -- Before Sunrise -- 00:30 (idx 38)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=38"

# Kitchen Lights -- After Sunset -- 02:00 (idx 36)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=36"

# Kitchen Lights -- On Time -- 09:00 (idx 43)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=43"

# Kitchen Lights -- On Time -- 23:00 (idx 37)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=37"

# Kitchen Lights -- On Time -- 23:30 (idx 41)
curl -s "http://192.168.178.12:8080/json.htm?type=command&param=$ACTION&idx=41"

The perl script also creates a JSON file called "my_domoticz_schedules.txt" as a log of what is returned from Domoticz when querying the schedule idx values. Here's the perl (note you will need to have installed JSON::XS and LWP::UserAgent from CPAN to run it):

Code: Select all

#!/usr/bin/perl
use JSON::XS;
use LWP::UserAgent;
no warnings 'uninitialized';

# Finds the idx values of all your Domoticz timers and builds a bash script that can be called from Domoticz 
# to bulk enable/disable them for away/home purposes.

# -----------------------------------------------------------------------------------------
# IMPORTANT: change these to match your setup before running

$domoticz="http://192.168.178.12:8080";
$bashfile='enable_timers.sh';

# The binmode and \012 statements create UNIX line endings for use on e.g. a Raspberry Pi. 
# If running Domoticz on Windows then delete those 2 lines.

open(OUT, '>', $bashfile) or die $!;
binmode OUT;
$/="\012"; 
# -----------------------------------------------------------------------------------------

# First set up the header and initial portion of our bash file. 

print OUT '#!/bin/sh'       ."\n";
print OUT '# Domoticz bash script to bulk enable/disable schedules for switch timers'       ."\n";
print OUT "\n";
print OUT 'if [ "$1" = "1" ]'       ."\n";
print OUT 'then'       ."\n";
print OUT '  ACTION="enabletimer"'       ."\n";
print OUT 'elif [ "$1" = "0" ]'       ."\n";
print OUT 'then'       ."\n";
print OUT '  ACTION="disabletimer"'       ."\n";
print OUT 'else'       ."\n";
print OUT '  curl -s "'.$domoticz.'/json.htm?type=command&param=addlogmessage&message=Invalid%20parameter%20sent%20to%20timer%20schedule%20script"'       ."\n";
print OUT '  echo "Invalid parameter - please run script followed by 0 or 1 only"'       ."\n";
print OUT '  exit 1'       ."\n";
print OUT 'fi'       ."\n";
print OUT "\n";
print OUT '# Add an entry to the Domoticz logfile to indicate whether we are now enabling or disabling timer schedules'       ."\n";
print OUT 'curl -s "'.$domoticz.'/json.htm?type=command&param=addlogmessage&message=$ACTION"'       ."\n";
print OUT "\n";


# Query Domoticz schedules data and print it out to a file called my_domoticz_schedules.txt
$ua=LWP::UserAgent->new;
$ua->timeout(5);
$ua->env_proxy;
$url=$domoticz.'/json.htm?type=schedules';
$response=$ua->get($url);
if ($response->is_success) { print "Domoticz responded OK\n" } else { die $response->status_line};
$schedules=$response->decoded_content;
$data=decode_json $schedules;

open(LOG, '>', 'my_domoticz_schedules.txt'); print LOG "$schedules\n"; close(LOG);

$count=scalar(@{$$data{result}});
print "Found $count schedule entries for switches at $url\n";

foreach $entry (@{$$data{result}}) {
   $name=$$entry{DevName};
   $time=$$entry{Time};
   $type=$$entry{TimerTypeStr};
   $idx=$$entry{TimerID};
   print OUT "\n";
   print OUT "# $name -- $type -- $time (idx $idx)\n";
   print OUT "curl -s \"$domoticz/json.htm?type=command&param=\$ACTION&idx=$idx\"\n";
}

close(OUT);
print "Finished. Your script file is \"$bashfile\".\n";
print "On Unix, don't forget to chmod +x this file and move it to your Domoticz scripts directory\n";
print "Then create a dummy switch that calls the script with extra parameter 1 for enable and 0 for disable\n";
sleep 10;

Don't forget to change the value of $domoticz to match the IP and port of your Domoticz instance. You can also change the file name of the created script and set whether UNIX or Windows line-endings are needed. As always, don't forget to chmod +x the bash file if trying to execute on a UNIX based box.

[lost]

I wrote a perl script that you can run once to automatically generate a bash script that you can then use in Domoticz to bulk enable/disable your timer schedules. It uses LWP::UserAgent to query Domoticz idx values for timer schedules and builds a bash file with the results. You can edit that file by hand to remove any entries you don't want switching when the bash runs.

You'll have to re-run your bash buildup script + all the post buildup edit every time you modify a schedule. This is a method that require less processing than mine (that always query all timers and dynamically validate/invalidate those belonging to a device switch) if plannings do not change often, indeed.

But for those who want to modify all plannings activation, looks current development versions of Domoticz allows more selectable plannings (currently, there is only 2: Normal & vacation) than current stable.
=>This job will soon be possible much more easily making an "all off" planning & a selector vSwitch that allows plannings selection.

Indeed, the problem will remain when more flexibility is needed, for instance on a per switch (or switch groups, if a naming prefix convention is used & using wildcards in name) granularity: Making as many plannings with all useful device combinations would be a problem (+ no planning copy feature, from one device to another).

So I think my scripts will still be useful!

[philchillbill]

You'll have to re-run your bash buildup script + all the post buildup edit every time you modify a schedule

That's something that can be run on a cron schedule every 5 minutes or so... I can also put a single line in the perl to always exclude certain idx numbers so it's trivial to avoid post-edits altogether.

[lost]

You'll have to re-run your bash buildup script + all the post buildup edit every time you modify a schedule

That's something that can be run on a cron schedule every 5 minutes or so... I can also put a single line in the perl to always exclude certain idx numbers so it's trivial to avoid post-edits altogether.

Well, was just trying to figure out the reason behind auto-building a script with static IDXes subject to change vs just getting them dynamically at execution.

[philchillbill]

Yep, you're right. When I originally wrote this I was new to Domoticz and to Linux and didn't know you could directly run a perl script via the script:// concept in Domoticz (as opposed to bash-only). I recently rewrote my script to just do it all dynamically in perl.

So deploying 'script://bulktimers.pl 0' on a switch will disable timers and 'script://bulktimers.pl 1' will enable them.

Code: Select all

#!/usr/bin/perl
use JSON::XS;
use LWP::UserAgent;
no warnings 'uninitialized';

# Queries timers within Domoticz and bulk-enables/disables them depending on whether 0 or 1 is passed when executing
# Any idx values in the hash '%ignore' are skipped. If $debug is set to 1 the script provides feedback when run from command line 

$what=$ARGV[0];
unless (defined ($what)) { print "No parameter supplied, exiting. ($what)\n"; sleep 2; exit 0 };
if ($what == 1) { $action = 'enabletimer' } else { $action = 'disabletimer' };

$debug=0;
 
# get the list of scheduled timers into a hash
$domo_url='http://192.168.178.12:8080';
$ua=LWP::UserAgent->new; $ua->timeout(5);
$scheds=$domo_url.'/json.htm?type=schedules';
$response=$ua->get($scheds);
unless ($response->is_success) { warn "Error getting schedule data from Domoticz $response->status_line" };
$schedules=$response->decoded_content;
$jdata=decode_json $schedules;

%ignore = ( '38' => 1, '39' => 1 );

# loop through the timers and enable/disable them. Only idx is strictly needed, the others are for feedback
foreach $entry (@{$$jdata{result}}) {
 $name=$$entry{DevName};
 $time=$$entry{Time};
 $type=$$entry{TimerTypeStr};
 $idx=$$entry{TimerID}; 
 $cmd=$$entry{TimerCmd};  
 
 if ($ignore{$idx}) { next };

 $c++; $c=sprintf("%02d", $c);
 print "\[$c\] $name -- $type -- $time -- $cmd -- idx: $idx\n" if ($debug);
 $set_schedule=$domo_url."/json.htm?type=command&param=$action&idx=$idx";
 $response=$ua->get($set_schedule);
 unless ($response->is_success) { warn "Error performing '$action' $response->status_line" };
}