• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Ideas for replacement of datetime protocol
#11
@wo_rasp, i understand that optimalizations are not explicitly needed on our platforms, that might be true, but not best practice programming wise Smile

Second, the task based approach is not just implemented for CPU / RAM optimalizations but also for future requirements:
- The new config is storage independent allowing database integration.
- The (internal) event structure allows more extensive GUIs. There is currently a REASON_DEVICE_ADDED event, but that should be extended with the REASON_DEVICE_UPDATED and REASON_DEVICE_DELETED.
- The task based approach is scaleable. Extensive configs could trigger over 20 threads. Eventually these threads were going to clog any platform.

What i discuss here is merely a side-effect of this new implementation. The datetime device doesn't fit the vision of the time based queue.

Thanks for all the ideas posted here!


Also, it helps running the rewrite code in a gdb session. If error occur, you at least know why they happen (as too me just know):
Code:
Program received signal SIGPIPE, Broken pipe.
0x76ef5a50 in send () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x76ef5a50 in send () at ../sysdeps/unix/syscall-template.S:81
#1  0x000b1528 in client_send (node=0xa260e0) at /home/pilight/daemon2/libs/pilight/core/webserver.c:1078
#2  0x000b5620 in eventpool_process (param=0x0) at /home/pilight/daemon2/libs/pilight/core/eventpool.c:808
#3  0x00093ca0 in main (argc=4, argv=0x7efff1d4) at /home/pilight/daemon2/daemon.c:2726
(gdb) frame 1
#1  0x000b1528 in client_send (node=0xa260e0) at /home/pilight/daemon2/libs/pilight/core/webserver.c:1078
1078    /home/pilight/daemon2/libs/pilight/core/webserver.c: No such file or directory.
(gdb)
 
Reply
#12
@curlymo
Will have a look into it. The more i am testing the two branches, the more i am getting convinced, that the rewrite branch is revealing some design issues that are present in development as well.

Originally I thought that some failures that i am monitoring in the rewrite branch were unique to rewrite, but i have to change that opinion, it happens less often on development as well.
Can you give me a hint where to start looking into it?

It is the same issue as discussed before:
- A timebased rule changes the state of a device (ZeitSchaltUhr).
The fact that the state of this device has changed is supposed to change the state of 4 other physical devices (and display it on the GUI) as well, but from time to time it does not.
The main difference:
- Whenever I change the state of ZeitSchaltuhr on the WEBGUI, all 4 physical devices are supposed to change their state (there should be no difference whether the state change is triggered by a rule or via the GUI), and they do so on development (but typically not on rewrite)
- Whenever the same state change of ZeitSchaltUhr is triggered by a rule, not all rules that are supposed to "act" will do so, only a subset does on development (they typically do not trigger any resonse on rewrite).
 
Reply
#13
Can we discuss the fundamental design issues in another post and focus on datetime replacement here?
 
Reply
#14
i pretty much like the meta by assigning a cron/"clock" device that can trigger state changes. since the second just solves the problem for the datetime. the first one could lead a way to implement future "meta" devices. it behaves like a global variable and it could be used more than once.

for the second one i feel like the rule should the be splitted into the if clause and the action.

edit: further, with a meta device you could force the clock to trigger by pilight-control or even drive the clock with linux cron and pilight-control
 
Reply
#15
I think an event should only be triggered once, e.q. the event is scheduled once, no matter how often the event gets scheduled afterwards.
Once the scheduled times arrives, the associated task gets the state running.
What should be discussed, are the properties, and the lifespan (should the event for example survive a reboot or not)

The default value of a parameter is 0, the default property is once:
- 2016 means: once at 2016-1-1 00:00:00:000
- Friday 9:15 means, every Friday at 9:15:00:000
 
Reply
#16
I'm was thinking about this again after i rewrote the current event parser. The idea i have now is to make the scheduler part of the rule syntax. E.g.:

Code:
ON wednesday AT 12:00:00 AND thursday AT 17:00:00 AND sunday AT 21:00:00 AND IF switch.state == on THEN ...
Or the other way around:
Code:
IF switch.state == on AND ON wednesday AT 12:00:00 AND thursday AT 17:00:00 AND sunday AT 21:00:00 THEN ...

So, the current rule that starts with the IF statement will be extended by a ON statement that allows us to semantically defines schedules that can extend the IF old statements.
 
Reply
#17
This doesn't look bad. A few first thoughts though:

Rules for random weekdays (now 0 through 6) will become complicated when working with day names.
e.g

Code:
IF datetime.weekday == RANDOM(0,6) THEN...

Or doing things only during workingdays:

Code:
IF datetime.weekday > 1 THEN...

Triggering rules at given intervals too (eg. once every 10 minutes):

Code:
IF (datetime.minute % 10) == 0 THEN...

I have no doubt that your idea can be extended to cater for things like this.

I will scan the time based rules I actually am using now and see how those could be rewritten based on your idea. I  fear that such rules will become quite a bit longer than they already are are now.
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  program protocol missing in rewrite Niek 1 487 10-07-2017, 08:55 PM
Last Post: curlymo

Forum Jump:


Browsing: 1 Guest(s)