@mikee123
Thanks for reporting the bug … it’s not new … But related to renaming variables.
When you created a new trigger it was named t1
You previously had a condition named: BedroomHot1
When you remamed t1 to WD2 … it changed your condition to BedroomHoWD2.
I need to be smarter in the renaming.
A short term work around is to use a …t-N suffix instead of …tN suffix.
@Theduck38
Can you send me the Actions value from the Advanced Tab.
I will see if I can clean this up … I think editing a PLEG with an earlier patch may have caused this problem … So I should clean it up.
it would be nice if the auto-update function for the plugin would be added, for a lot of not so techsavvy people that have no idea how to update it.
can use http://:3480/data_request?id=update_plugin&Plugin=3086 in the meanwhile to update the plugin on your vera
[quote=“Da_JoJo, post:45, topic:175016”]it would be nice if the auto-update function for the plugin would be added, for a lot of not so techsavvy people that have no idea how to update it.
can use http://:3480/data_request?id=update_plugin&Plugin=3086 in the meanwhile to update the plugin on your vera[/quote]
^^^
No, please don’t.
I happy with the version I am running and frightened that we could be burden with a “buggy” version automatically.
Once the “bugs” in the current version are fixed, then I will upgrade.
we wont… there is a option to not set the tick for updating to the newer version automaticly. so it can be debugged before going public. also in the plugin settings you could untick the auto-update feature
[quote=“Theduck38, post:33, topic:175016”][quote=“RichardTSchaefer, post:31, topic:175016”]Oops you are right.
Cond1 = (temp @ 2 > 1:00) ? (temp>15) : Cond1
Sequence expressions (or multi triggers expressions) get a timestamp for boolean values every time they change from False to True. Device Properties get a timestamp every time they change.[/quote]
Speaking of features requests… ;D would it be possible to implement something to ‘debounce’ multiple actions before they are sent ?[/quote]
Hello Richard,
I am still looking for a way to “debounce” actions… would it be possible to you to add a kind of timeout for any condition, that will force ‘no evaluation’ during a specified time after the condition goes to true ?
Today, my Hvac changed its mode 6 times (in less than half an hour) as the external humidity and internal humidity were playing around my conditions limits… with a condition timeout, I would have specified 30 minutes and had got no such issue.
In the case you would accept such an enhancement, it will be necessary to define what happens when the timeout finishes if the cond has become false and the true during the timer… either trigger the condition or wait for next “turn”.
Cond1 = A and (Cond1;NOW > 30) where A is my triggering expression. But I have something weird… I use a simple virtual switch to replace “A” :
If I put VS on and off in less than 30 seconds, Cond1 is always false… this is normal.
If VS is ON, cond1 false… I wait for 30s and then set VS off, and on immediately => per my understanding, I should get Cond1 true, as its former timestamp (last true) is older than 30s. But it remains false.
To get cond1 to true, I need to leave VS off for 30 seconds before setting it to on… as if the timestamp of cond1 (used for NOW evaluation) was only related to its last evaluation, and not to its last true state…
NOW is not very useful in this scenario … NOW is only updated with a timestamp once a minute. Not very useful when you are doing comparisons with less than a minute.
For 30 seconds or 30:00 for 30 minutes.[/quote]
I had thought to this way… but it doubles the number of conditions to put…
I think I have found another way :
Condition = AND (Condition;NOW>timer) assuming ‘timer’ is over one minute => this works for timer+2 minutes (I mean “the precision is within two minutes after end of timer”)
For example, if I set 3 minutes for ‘timer’, the Condition will be satisfied for sure if is true more than 5 minutes after Condition goes to false…
Whatever, this seems to do the job for me, as I only need debounces of more than 15 minutes… I will set timer = 13:00 !!!
[quote=“RichardTSchaefer, post:57, topic:175016”]It will work … but it’s tricky … using the sequence time for the same expression.
Will you remember what this is doing 1 year from now ?[/quote]
I hope so !!! I am really trying to remove as many useless commands to actuators as possible… it will increase their lifetime (and actuated devices’ lifetime too !).
Otherwise I will ask you ;D
Please attach the output of a Status command.
Do you know what version you were on before ? I guess it’s possible that something
got lost in the transition. Do you know what PIR_ON was tied to ?
It sounds like it was a device Trigger.[/quote]
My last version was 4.3
After issueing a Status command , it said that plugin was updated to the last version and told me to do a Save again…After that, there is no error message in interface,BUT the actions are NOT executed…
‘‘PIR_ON’’ was is fact ‘‘pir_on’’ (a pir senzor being tripped) and was 1 of the triggers…but it is not recognized as being tripped.
I sent you an email with the details.
Name Description Last Trigger State
pir_on PIR camera router(Cezar) is tripped 2013-09-24 16:56:24.125 false
ping_S4 Ping GALAXY S4 is Tripped 2013-09-24 16:51:08.236 true
plecat Ping GALAXY S4 is not Tripped 2013-09-24 16:50:58.122 false
AC_on AC Router Status is turned on 0 false
Conditions
Name Expression Last True State
declansare_ac (declansare_ac; pir_on > 03:00:00) and pir_on and ping_S4 2013-09-24 16:19:59.591 false
oprire plecat and (pir_on; NOW > 00:15:00) and AC_on 2013-09-22 20:40:33.000 false
Actions
Question… (Hope I did not miss it being already asked)
I have a scene called HomeActivate that is fired from various other scenes. This way as I modify devices in HomeActivate, I do not have to touch 5 other scenes.
I know that having scenes call other scenes with LUUP code is not recommended because of some inherent unreliability of the actions only being attempted once. However, I noticed that within PLEG, I can reference a condition name in the advanced tab within the Actions generator. It seems this would allow me to have Actions evaluate conditions which trigger further actions.
Since this is all within PLEG, would this be more reliable than the native method since PLEG tracks even across reboots ?
I am realizing that the PLEG itself could all but replace every scene logic that I have. PLEG could eventually just replace all the Vera native logic processing as it seems to almost all the features and is seemingly more reliable. Vera just becomes the GUI and the radio interface.
