A new event architecture

Forum about Domotiga Open Source Home Automation for Linux.

Moderator: RDNZL

airox
Member
Member
Posts: 214
Joined: Sat May 15, 2010 10:42 pm

Re: A new event architecture

Post by airox »

Sounds like a nice concept. You still will need to roundtrip to the database. But it would indeed be just selecting by one column for any dates marked for processing. A single index can help a lot and would speed it up. I still wonder how much you would win with this, it would limit the amount of timers being returned and you would be capable of executing them right away, but you still need to do the same IO. I experimented a week ago with caching all the events every X seconds (configured at 60 now). Because the events don't change a lot this seemed like a nice trick.

Following numbers were measured:
With no optimization I was capable of processing 4,7 incoming values in one second.
With caching I was capable of processing 44 incoming values in one second.

This greatly improved the speed. The performance at the beginning was fast enough (i don't have a lot of sensors providing me with update statuses per minute), but this improvement would make it capable of sizing my devices a lot without being afraid of hitting the ceiling in the near future.

I like this discussion a lot! We are really getting to a nice vision about domotica architectures.
User avatar
RDNZL
Forum Moderator
Forum Moderator
Posts: 1008
Joined: Sun Sep 24, 2006 1:45 pm
Location: Dordrecht, The Netherlands
Contact:

Re: A new event architecture

Post by RDNZL »

Seems like a good idea, maybe not as powerfull as cron (no repeats etc) but i see advantages.
What do you mean about doing ir the same way? It's unrelated... can you elaborate on this?
Regards, Ron.
hplus
Starting Member
Starting Member
Posts: 43
Joined: Fri Jan 22, 2010 12:21 pm

Re: A new event architecture

Post by hplus »

It will have the exact same capability as today's cron. The differences are:
Today, when different events share the same timecron trigger, the trigger is evaluated once per event (this is also true for other types of triggers)
The timecron trigger could be evaluated once and then all the events using this trigger retrieved and then their condition evaluated.
By using the multitrigger feature we already have solved the problem of triggers evaluated once per event for the device update and gloalvar update triggers. The timecron was still heavy to handle. This idea will make the three types of triggers identical, in the multitrigger tab you will have in the tree : the devices, the globalvars, and the timers names.
When a timer is triggered, we select the events that has this timer name in their multi trigger list.

Now there are two ways to manage the timers:
the simple way:

Code: Select all

each minute  
retrieve all timer from database
for each timer
 IF TimeCron(timer) THEN timerlist.add(timer.name)
next

for each timername IN timerlist
select event type 'multi-trigger' regexp 'timername'
....
the more efficient way:

Code: Select all

at timer creation 
compile timer to store next triggering date
at each minute
check all timers date (faster than TimeCron(), could be just 2 integers comparison)
for each triggered timer 
 add to timerlist and recompile timer to store next truggering date
next

The idea for the ir thing is to have a IR(remote, button) in the multitrigger list and to have an efficient way to select from the database all event whose having a trigger on such an event...
Post Reply

Return to “DomotiGa Forum”