I suspect that this problem is caused by the logging facility. I discovered some time after I released 0.0.1.26 with improved logging that the date/time functions used in log messages were interfering with date/time functions used in sunrise/sunset or timers. I already fixed it in CVS. If you want to be sure that you see the same problem, you can add <loggging format="simple"/> to your config file (inside the <config> element, at the same level as <rules>, <objects> and <sevices>). This will remove the timestamps from log messages and perhaps solve your problem.
Regards,
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At system startup, the timers compute the time of the next occurence of the "at" and "until" (in this case, sunrise and sunset). If "at" occurs first, the initial value of the timer is "false". If "until" occurs first, the initial value of the timer is "true". I know that this solution can sometimes be wrong, but that's the best I have done until now. Perhaps I could allow user to give an initial value.
Regards,
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all, Hi Jean-François,
I am still not satisfied with the rule as posted above. After changing the logging, the infinite loop was solved, but when I start up my system during daytime, the object daylight still remains off.
I enclude the Linknx log below:
[ INFO] Rule: Rule: Configuring rule_daylight (active=1)
[ INFO] TimeSpec: 1899-0--1 -1:-1:0 (wdays=0; exception=2)
[ INFO] TimeSpec: 1899-0--1 -1:-1:0 (wdays=0; exception=2)
[ INFO] SolarTimeSpec: sun_rise_set date 2009-7-18
[ INFO] SolarTimeSpec: sun_rise_set returned 21:33
[ INFO] SolarTimeSpec: adjustTime date 2009-7-18
[ INFO] SolarTimeSpec: adjustTime returned 21:33
[ INFO] SolarTimeSpec: sun_rise_set date 2009-7-18
[ INFO] SolarTimeSpec: sun_rise_set returned 5:21
[ INFO] SolarTimeSpec: adjustTime date 2009-7-19
[ INFO] SolarTimeSpec: adjustTime returned 5:23
[ INFO] PeriodicTask: Rescheduled at 2009-7-18 21:33:0 (1247945580)
[ INFO] Rule: ActionList: Configuring
[ INFO] Action: SetValueAction: Configured for object daylight with value on
[ INFO] Rule: ActionList: Configuring 'on-false'
[ INFO] Action: SetValueAction: Configured for object daylight with value off
[ INFO] Rule: Rule: Configuration done
By the way, I missed the way to start knxlog. I was able to do so earlier, but now I am stuck with a non-responsive prompt after calling
knxlog ip:127.0.0.1
Thank you for your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fivesails - the way you ask your questions I really hope you donated some money to
Here are my2cents for your "request":
Jean-François. He is doing this excellent stuff for free and we should honor him at least by beeing polite in our questions towards him.
If something is not working as you wish, maybe you should ask if it could be implemented in the way you want it. Not beeing satisfied by something you got for free is really not the way to ask for help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The rule that you are using is defining an action-list to execute when the condition changes from false to true and another one when it changes from true to false. If you start the system in between, no action will be executed until sunrise or sunset occurs.
In next release (0.0.1.27), I'll add new type of action-lists. If type="if-true" is used instead of "on-true", the action-list will be executed every time the condition is evaluated true (not only when there is a change from false to true) and additionally, I'll force the evaluation of the condition once at startup to execute the right action-list.
For knxlog, I didn't change it since years, but I think that Martin included it in the last bcusdk release. Which version of eibd are you using, compiled by whom an on which platform?
Regards,
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jean-François,
would it be possible to have also the feature realised in a 0.0.1.27, that every message (independent from its previous value) is used for rules?
(not just the gads, which have changed their values).
Thanks, Best Regards, auto-mate
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ronny put the issue to my way of asking: I would like to clarify that in my post above I was saying that I am not satisfied with the way my basic rule is working and only referring to that rule.
Linknx is a very nice software, I am using it for more than a year. It is working very well and I appreciate the forums and especially Jean-François' support.
To evaluate the problem with my rule as above, I would like to log group addresses with knxlog. What is the basic command line for loging to a file in /var/log?
Thank you for your help,
fivesails
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am a bit confused by your two postings from 2009-06-27 and 2009-07-20.
Supposed, linknx is starting up after sunrise and before sunset with the following rule in the configuration file,
<rule id="rule_daylight">
<condition type="timer" trigger="true">
<at type='sunrise'/>
<until type='sunset'/>
</condition>
<actionlist>
<action type="set-value" id="daylight" value="on" />
</actionlist>
<actionlist type="on-false">
<action type="set-value" id="daylight" value="off" />
</actionlist>
</rule>
In my understanding of the first post, the timer would evaluate to false and daylight would be set to off.
In my understanding of the second post, the timer would not be evaluated and daylight would remain unchanged.
I am not sure, what to expect at linknx start.
Thank you for your help,
fivesails
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@auto-mate:
Yes, in 0.0.1.27 I introduced a new flag "s" in object definitions (s for stateless). If that flag is set, the object is allowed to send its value on the bus even if the last value was the same (that's the behavior of actual "f" flag). Additionally, if a value received from bus is equal to the previous value, it will not be ignored (that's what you expect). In other words, multiple "set-value" actions for the same object and with the same values will result in multiple telegrams sent over the bus. And if multiple telegrams with the same value are received, they will all trigger the evaluation of the rules in which they are present with the trigger="true" parameter set.
@fivesails:
The initial value in postings from 2009-06-27 is a value internal to the timer condition. it's used to decide which event we are waiting for and it's the value that will be returned if the condition is evaluated. But at system startup, the condition is not evaluated, so the action-lists are not executed (that's how it works in 0.0.1.26).
for knxlog, the llog files are created in the current directory. You must first go to the directory where you want to have the log files, make sure that you have write permissions to that directory and then launch knxlog. The command could be something like this:
cd /var/log && knxlog ip:127.0.0.1
Regards
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all,
I am trying to set an object called daylight by a timer.
However my rule sends Linknx into an infinite loop continuously reevaluating the timer condition.
The rule is:
<rule id="rule_daylight">
<condition type="timer" trigger="true">
<at type='sunrise'/>
<until type='sunset'/>
</condition>
<actionlist>
<action type="set-value" id="daylight" value="on" />
</actionlist>
<actionlist type="on-false">
<action type="set-value" id="daylight" value="off" />
</actionlist>
</rule>
Thank you for your help,
fivesails
I forgot to include the log output:
...
2009-06-19 16:58:30 [ INFO] TimerManager: TimerTask execution. 1245423510
2009-06-19 16:58:30 [ INFO] Condition: TimerCondition evaluated as '0'
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set returned 4:58
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime returned 16:58
2009-06-19 16:58:30 [ INFO] PeriodicTask: Rescheduled at 2009-6-19 16:58:30 (1245423510)
2009-06-19 16:58:30 [ INFO] TimerManager: TimerTask execution. 1245423510
2009-06-19 16:58:30 [ INFO] Condition: TimerCondition evaluated as '1'
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set returned 21:47
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime returned 16:58
2009-06-19 16:58:30 [ INFO] PeriodicTask: Rescheduled at 2009-6-19 16:58:30 (1245423510)
2009-06-19 16:58:30 [ INFO] TimerManager: TimerTask execution. 1245423510
2009-06-19 16:58:30 [ INFO] Condition: TimerCondition evaluated as '0'
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set returned 4:58
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime returned 16:58
2009-06-19 16:58:30 [ INFO] PeriodicTask: Rescheduled at 2009-6-19 16:58:30 (1245423510)
2009-06-19 16:58:30 [ INFO] TimerManager: TimerTask execution. 1245423510
2009-06-19 16:58:30 [ INFO] Condition: TimerCondition evaluated as '1'
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set returned 21:47
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime returned 16:58
2009-06-19 16:58:30 [ INFO] PeriodicTask: Rescheduled at 2009-6-19 16:58:30 (1245423510)
2009-06-19 16:58:30 [ INFO] TimerManager: TimerTask execution. 1245423510
2009-06-19 16:58:30 [ INFO] Condition: TimerCondition evaluated as '0'
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set returned 4:58
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime returned 16:58
2009-06-19 16:58:30 [ INFO] PeriodicTask: Rescheduled at 2009-6-19 16:58:30 (1245423510)
2009-06-19 16:58:30 [ INFO] TimerManager: TimerTask execution. 1245423510
2009-06-19 16:58:30 [ INFO] Condition: TimerCondition evaluated as '1'
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: sun_rise_set returned 21:47
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime date 2009-6-19
2009-06-19 16:58:30 [ INFO] SolarTimeSpec: adjustTime returned 16:58
2009-06-19 16:58:30 [ INFO] PeriodicTask: Rescheduled at 2009-6-19 16:58:30 (1245423510)
...
Hi,
I suspect that this problem is caused by the logging facility. I discovered some time after I released 0.0.1.26 with improved logging that the date/time functions used in log messages were interfering with date/time functions used in sunrise/sunset or timers. I already fixed it in CVS. If you want to be sure that you see the same problem, you can add <loggging format="simple"/> to your config file (inside the <config> element, at the same level as <rules>, <objects> and <sevices>). This will remove the timestamps from log messages and perhaps solve your problem.
Regards,
Jean-François
Hi Jean-François,
thank you for the hint! That was exactly the problem. When I added the logging directive, everything runs fine.
Just one small thing: How would you set the value at system startup?
Regards,
Erik
Hi,
At system startup, the timers compute the time of the next occurence of the "at" and "until" (in this case, sunrise and sunset). If "at" occurs first, the initial value of the timer is "false". If "until" occurs first, the initial value of the timer is "true". I know that this solution can sometimes be wrong, but that's the best I have done until now. Perhaps I could allow user to give an initial value.
Regards,
Jean-François
Hi all, Hi Jean-François,
I am still not satisfied with the rule as posted above. After changing the logging, the infinite loop was solved, but when I start up my system during daytime, the object daylight still remains off.
I enclude the Linknx log below:
[ INFO] Rule: Rule: Configuring rule_daylight (active=1)
[ INFO] TimeSpec: 1899-0--1 -1:-1:0 (wdays=0; exception=2)
[ INFO] TimeSpec: 1899-0--1 -1:-1:0 (wdays=0; exception=2)
[ INFO] SolarTimeSpec: sun_rise_set date 2009-7-18
[ INFO] SolarTimeSpec: sun_rise_set returned 21:33
[ INFO] SolarTimeSpec: adjustTime date 2009-7-18
[ INFO] SolarTimeSpec: adjustTime returned 21:33
[ INFO] SolarTimeSpec: sun_rise_set date 2009-7-18
[ INFO] SolarTimeSpec: sun_rise_set returned 5:21
[ INFO] SolarTimeSpec: adjustTime date 2009-7-19
[ INFO] SolarTimeSpec: adjustTime returned 5:23
[ INFO] PeriodicTask: Rescheduled at 2009-7-18 21:33:0 (1247945580)
[ INFO] Rule: ActionList: Configuring
[ INFO] Action: SetValueAction: Configured for object daylight with value on
[ INFO] Rule: ActionList: Configuring 'on-false'
[ INFO] Action: SetValueAction: Configured for object daylight with value off
[ INFO] Rule: Rule: Configuration done
By the way, I missed the way to start knxlog. I was able to do so earlier, but now I am stuck with a non-responsive prompt after calling
knxlog ip:127.0.0.1
Thank you for your help!
Fivesails - the way you ask your questions I really hope you donated some money to
Here are my2cents for your "request":
Jean-François. He is doing this excellent stuff for free and we should honor him at least by beeing polite in our questions towards him.
If something is not working as you wish, maybe you should ask if it could be implemented in the way you want it. Not beeing satisfied by something you got for free is really not the way to ask for help.
Hi,
The rule that you are using is defining an action-list to execute when the condition changes from false to true and another one when it changes from true to false. If you start the system in between, no action will be executed until sunrise or sunset occurs.
In next release (0.0.1.27), I'll add new type of action-lists. If type="if-true" is used instead of "on-true", the action-list will be executed every time the condition is evaluated true (not only when there is a change from false to true) and additionally, I'll force the evaluation of the condition once at startup to execute the right action-list.
For knxlog, I didn't change it since years, but I think that Martin included it in the last bcusdk release. Which version of eibd are you using, compiled by whom an on which platform?
Regards,
Jean-François
Hi Jean-François,
would it be possible to have also the feature realised in a 0.0.1.27, that every message (independent from its previous value) is used for rules?
(not just the gads, which have changed their values).
Thanks, Best Regards, auto-mate
Hi Jean-François, hi Ronny,
Ronny put the issue to my way of asking: I would like to clarify that in my post above I was saying that I am not satisfied with the way my basic rule is working and only referring to that rule.
Linknx is a very nice software, I am using it for more than a year. It is working very well and I appreciate the forums and especially Jean-François' support.
My apologies, if my words were misunderstood.
I am using linknx-0.0.1.26-OpenWRT-Kamikaze-r7908 from sourceforge and http://ouaye.net/linknx/OpenWRT-Kamikaze-r7908/eibd_0.0.2.1-10_mipsel.ipk
on a Linksys WRT54GS.
To evaluate the problem with my rule as above, I would like to log group addresses with knxlog. What is the basic command line for loging to a file in /var/log?
Thank you for your help,
fivesails
Hi Jean-François,
I am a bit confused by your two postings from 2009-06-27 and 2009-07-20.
Supposed, linknx is starting up after sunrise and before sunset with the following rule in the configuration file,
<rule id="rule_daylight">
<condition type="timer" trigger="true">
<at type='sunrise'/>
<until type='sunset'/>
</condition>
<actionlist>
<action type="set-value" id="daylight" value="on" />
</actionlist>
<actionlist type="on-false">
<action type="set-value" id="daylight" value="off" />
</actionlist>
</rule>
In my understanding of the first post, the timer would evaluate to false and daylight would be set to off.
In my understanding of the second post, the timer would not be evaluated and daylight would remain unchanged.
I am not sure, what to expect at linknx start.
Thank you for your help,
fivesails
Hi,
@auto-mate:
Yes, in 0.0.1.27 I introduced a new flag "s" in object definitions (s for stateless). If that flag is set, the object is allowed to send its value on the bus even if the last value was the same (that's the behavior of actual "f" flag). Additionally, if a value received from bus is equal to the previous value, it will not be ignored (that's what you expect). In other words, multiple "set-value" actions for the same object and with the same values will result in multiple telegrams sent over the bus. And if multiple telegrams with the same value are received, they will all trigger the evaluation of the rules in which they are present with the trigger="true" parameter set.
@fivesails:
The initial value in postings from 2009-06-27 is a value internal to the timer condition. it's used to decide which event we are waiting for and it's the value that will be returned if the condition is evaluated. But at system startup, the condition is not evaluated, so the action-lists are not executed (that's how it works in 0.0.1.26).
for knxlog, the llog files are created in the current directory. You must first go to the directory where you want to have the log files, make sure that you have write permissions to that directory and then launch knxlog. The command could be something like this:
cd /var/log && knxlog ip:127.0.0.1
Regards
Jean-François