And I am trying out the new if-false if-true stateless objects:
<ruleid="shutters_up_down"><conditiontype="timer"trigger="true"><attype="sunset"offset="-20m"/></condition><actionlisttype="if-true"><!-- upstairs down --><actiontype="set-value"id="119"value="on"/></actionlist></rule>
For some reason; the only non-corner shutter will not close with this command anymore (though that one should not have been affected by the changes).
The strange thing is that I can see the command being send (not to 119 but separately to the composing devices).
1271097000 INFO Object : New value on for object shut-se-mov-a (type: 1.001)
1271097000 INFO Object : New value on for object shut-se-mov-b (type: 1.001)
1271097000 INFO Object : New value 18 for object 232 (type: 9.xxx)
1271097017 INFO Object : New value 17.32 for object 248 (type: 9.xxx)
1271097019 INFO Object : New value on for object 246 (type: 1.001)
1271097066 INFO Object : New value on for object 98 (type: 1.001)
1271097066 INFO Object : New value on for object 119 (type: 1.001)
1271097147 INFO Object : New value 17.11 for object 180 (type: 9.xxx)
1271097180 INFO TimerManager : TimerTask execution. 1271097180
1271097180 INFO Condition : TimerCondition evaluated as '1'
1271097180 INFO Condition : TimerCondition evaluated as '0'
1271097180 INFO SolarTimeSpec : sun_rise_set date 2010-4-12
1271097180 INFO SolarTimeSpec : sun_rise_set returned 20:33
1271097180 INFO SolarTimeSpec : adjustTime date 2010-4-13
1271097180 INFO SolarTimeSpec : adjustTime returned 20:35
1271097180 INFO PeriodicTask : Rescheduled at 2010-4-13 20:35:0 (1271183700)
Should I not use combining group addresses when other groups are listening to them? If so, I'd better add it to my example config file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-04-12
shoot formatting goed messed up; I'll have another go.
Hi,
please let me better understand your intentions:
you "just" want to send "3/0/5" 20 minutes before sunset, right?
In this case some comments:
the "if-true" only makes sense, if you have multiple/frequent "triggers", which just say…"something has changed….but the overall conditions i.e. the result of the rule is true"
In this case, the "if-true" actions are executed… this repeats with every newly incomming trigger, which does not make the overall condition false.
Since you have just one condition "sunset -20m", this is just triggered once a day. So you don't need to use "if-true".
(not in your case, but for gads used in stateless conditions, please remind to use the "s"-flag.)
I think the reason, why your 3/0/5 is not working, is the definition of the object.:
I haven't seen any flags in your definition:
you should write something like
<object type="1.001" id="119" gad="3/0/5" flags="cwtuf"><listener gad="3/0/1" />All shutters upstairs up/down (functions) </object>
mind especially the "f" - sine this forces the sending of the "3/0/5", even if it was send as "on" before.
Maybe that helps.
best Regards, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know the forum tool from sourceforge is like you say "plain evil", I suffer from it too.
Concerning your rule, the condition you use is:
<condition type="timer" trigger="true"> <at type="sunset" offset="-20m" /> </condition>
This kind of timer condition (without "until" or "during" element) will become true at the specified time, and become false again just after. Just as if you specifiy <during>0</during>. You can see that behavior in the traces:
1271097180 INFO TimerManager : TimerTask execution. 1271097180
1271097180 INFO Condition : TimerCondition evaluated as '1'
1271097180 INFO Condition : TimerCondition evaluated as '0'
So in this case, the stateless rule doesn't help because the rule becomes true and false alternatively.
But when the action <action type="set-value" id="119" value="on" /> is executed, nothing happens, because the object 119 already has value "on". So what you need here is not a stateless rule, but a a stateless object (an object that will send "on" on the bus even if it's internal state is already "on")
You can use the "s" flag for this. Since the default flags are "cwtu", parameter flags="cwtus" in the objects manipulating groups of shutters will make them "stateless" (115, 118 and 119).
Kr,
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a small precision, the "f" flag Auto-mate is talking about and the "s" flag I'm talking about are in fact the same. I renamed it "s" because it was more coherent with the introduction of stateless rules, but both are supported.
Kr,
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ahhaaaa! I just started to check the wiki and writing a question after seeing your first reply…. :-)
Thanks for the addendum.
(by now I thought "f" is to "force" the sending and "s" is just for receiving stateless rule-triggers…)
BR, Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the past, the "f" flag was only forcing transmission of values on the bus.
Now "f" and "s" are strictly equivalent. They make the rule "trigger" when a value is received from the bus, even if the object already had that same value. And they force sending of the object value on the bus in case the object value is set inside linknx, even if the object already had that same value.
Be careful not to create loops with this. If a stateless rule trigger on a stateless object change and the associated action set the value of that same object….
Kr,
Jean-François
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-04-14
Oh yeah, that did it for me, thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recently added a number of groups to separately control corner window shutters:
And I am trying out the new if-false if-true stateless objects:
For some reason; the only non-corner shutter will not close with this command anymore (though that one should not have been affected by the changes).
The strange thing is that I can see the command being send (not to 119 but separately to the composing devices).
1271097000 INFO Object : New value on for object shut-se-mov-a (type: 1.001)
1271097000 INFO Object : New value on for object shut-se-mov-b (type: 1.001)
1271097000 INFO Object : New value 18 for object 232 (type: 9.xxx)
1271097017 INFO Object : New value 17.32 for object 248 (type: 9.xxx)
1271097019 INFO Object : New value on for object 246 (type: 1.001)
1271097066 INFO Object : New value on for object 98 (type: 1.001)
1271097066 INFO Object : New value on for object 119 (type: 1.001)
1271097147 INFO Object : New value 17.11 for object 180 (type: 9.xxx)
1271097180 INFO TimerManager : TimerTask execution. 1271097180
1271097180 INFO Condition : TimerCondition evaluated as '1'
1271097180 INFO Condition : TimerCondition evaluated as '0'
1271097180 INFO SolarTimeSpec : sun_rise_set date 2010-4-12
1271097180 INFO SolarTimeSpec : sun_rise_set returned 20:33
1271097180 INFO SolarTimeSpec : adjustTime date 2010-4-13
1271097180 INFO SolarTimeSpec : adjustTime returned 20:35
1271097180 INFO PeriodicTask : Rescheduled at 2010-4-13 20:35:0 (1271183700)
Should I not use combining group addresses when other groups are listening to them? If so, I'd better add it to my example config file.
shoot formatting goed messed up; I'll have another go.
Ok, this is just plain evil. Sorry about this; but it copies my code/rules :-/ No way to modify posts.
Hi,
please let me better understand your intentions:
you "just" want to send "3/0/5" 20 minutes before sunset, right?
In this case some comments:
the "if-true" only makes sense, if you have multiple/frequent "triggers", which just say…"something has changed….but the overall conditions i.e. the result of the rule is true"
In this case, the "if-true" actions are executed… this repeats with every newly incomming trigger, which does not make the overall condition false.
Since you have just one condition "sunset -20m", this is just triggered once a day. So you don't need to use "if-true".
(not in your case, but for gads used in stateless conditions, please remind to use the "s"-flag.)
I think the reason, why your 3/0/5 is not working, is the definition of the object.:
I haven't seen any flags in your definition:
you should write something like
<object type="1.001" id="119" gad="3/0/5" flags="cwtuf"><listener gad="3/0/1" />All shutters upstairs up/down (functions) </object>
mind especially the "f" - sine this forces the sending of the "3/0/5", even if it was send as "on" before.
Maybe that helps.
best Regards, Jens
Hi,
I know the forum tool from sourceforge is like you say "plain evil", I suffer from it too.
Concerning your rule, the condition you use is:
<condition type="timer" trigger="true"> <at type="sunset" offset="-20m" /> </condition>
This kind of timer condition (without "until" or "during" element) will become true at the specified time, and become false again just after. Just as if you specifiy <during>0</during>. You can see that behavior in the traces:
1271097180 INFO TimerManager : TimerTask execution. 1271097180
1271097180 INFO Condition : TimerCondition evaluated as '1'
1271097180 INFO Condition : TimerCondition evaluated as '0'
So in this case, the stateless rule doesn't help because the rule becomes true and false alternatively.
But when the action <action type="set-value" id="119" value="on" /> is executed, nothing happens, because the object 119 already has value "on". So what you need here is not a stateless rule, but a a stateless object (an object that will send "on" on the bus even if it's internal state is already "on")
You can use the "s" flag for this. Since the default flags are "cwtu", parameter flags="cwtus" in the objects manipulating groups of shutters will make them "stateless" (115, 118 and 119).
Kr,
Jean-François
Hi,
Just a small precision, the "f" flag Auto-mate is talking about and the "s" flag I'm talking about are in fact the same. I renamed it "s" because it was more coherent with the introduction of stateless rules, but both are supported.
Kr,
Jean-François
Hi Jean-Francois,
ahhaaaa! I just started to check the wiki and writing a question after seeing your first reply…. :-)
Thanks for the addendum.
(by now I thought "f" is to "force" the sending and "s" is just for receiving stateless rule-triggers…)
BR, Jens
In the past, the "f" flag was only forcing transmission of values on the bus.
Now "f" and "s" are strictly equivalent. They make the rule "trigger" when a value is received from the bus, even if the object already had that same value. And they force sending of the object value on the bus in case the object value is set inside linknx, even if the object already had that same value.
Be careful not to create loops with this. If a stateless rule trigger on a stateless object change and the associated action set the value of that same object….
Kr,
Jean-François
Oh yeah, that did it for me, thanks!