A Bug Fixes update, version 2.1, for the Program Logic Event Generator, Program Logic Timer Switch and Program Logic Core is available at http://apps.mios.com
Bug Fixes:
[ul][li]Make sure NOW always evaluate to true.[/li]
[li]Fix Handling of string constants … so it does not treat symbols in the strings as potential operators.[/li]
[li]Fix bug causing string constants to be upper cased![/li]
[li]Fixed a bug in PLTS … if Vera was rebooted during a timing cycle … and subsequently a manual start of the device was issued, it used the wrong interval.[/ul]
New Features:
[ul][li]Add control of log messages via a Debug variable to PLTS and PLEG devices.
You can turn tracing on by setting the Debug value to 1 in the Advanced Tab
The default values is no logging.[/li]
[li]Changes to PLTS and PLEG to reduce setting variables that have not changed … this reduces noise in the log files.[/li]
[li]Add Support for cascading Triggers.
This effects referencing conditions in subsequent conditions.
Previously if you had a condition: Condition1 = … Some Long Logic Expression … Condition2 = NOT Condition1
Conditon2 would NOT fire.
Previously the rule to fire an action was:
[list type=decimal]
[li]The condition must have been previously false[/li]
[li]The condition must evaluate to true[/li]
[li]The condition expression must reference the Trigger, Device Property, or Schedule that has caused the condition to be re-evaluated. This has been changed to:
The condition expression must reference the Trigger, Device Property, Schedule, or a previous condition that has met these conditions and that has caused the condition to be re-evaluated.[/li]
[/list]
[/li]
[li]Reduced the reporting interval for PLTS time remaining … to reduce the log file contents.
By default time remaining will increment at TotalTime/100 seconds, with a minimum of one second and a maximum of 60 seconds. You can force this back to N seconds by setting the TimerInc value in the Advanced Tab to desired number of seconds (integer values only!) … The previous default was updating every second.[/li][/ul]
Excellent! Some really useful new features. I shall enjoy revisiting my logic to exploit the cascading conditions.
The resilience to restarts also extends to upgrades. Despite three restarts as I updated each module, none of my PLxx devices missed a beat. Everything kept running perfectly. That is really some achievement. 8)
Sorry I did not get to Insert Above/Below for new conditions.
But if you feel bold you can try to edit the ConditionMap in the Advanced Tab
Make sure you referesh your browser before editing … to get the latest changes here.
The format of this variable is a list of ordered Name, Values representing the names and values of the conditions. You can insert a new name, value as:
“namexx”, “namexx”,
Before an existing condition name.
Make sure the names are unique …
After restarting saving and restarting vera you can edit the new condition names and expressions in the normal way.
Sorry I did not get to Insert Above/Below for new conditions.
No problem. The cascaded conditions will be far more valuable. I appreciate your consideration.
But if you feel bold you can try to edit the ConditionMap in the Advanced Tab
That's a great idea. Funnily enough, I had been wondering if I should try that but I wasn't sure if you kept a checksum somewhere and would notice tampering. I shall give it a shot for the next enhancement. :) I do keep my more complex devices backed-up via cut-and-paste of the Advanced variables to Notepad but have not yet had to test the restore process.
Is there any issue with a new condition not having an entry in the ObjectStatusMap? I guess it gets one during the restart. I am now checking the map as a substitute to turning on Debug for simple status checks.
I have found out a lot of interesting stuff in my life by being bold. I still have some of the scars to prove it. ;D
BTW: Thanks for not changing your four-state icon in PLTS. It really make a great self-reset trigger.
BTW: Thanks for not changing your four-state icon in PLTS. It really make a great self-reset trigger.
I saw a previous posting about this and I meant to ask you what you use this for ?
It was never meant for triggering logic ... And I wonder if there is not a less obscure way to achieve your needs.
BTW: Thanks for not changing your four-state icon in PLTS. It really make a great self-reset trigger.
I saw a previous posting about this and I meant to ask you what you use this for ?
It was never meant for triggering logic … And I wonder if there is not a less obscure way to achieve your needs.[/quote]
I use it to create a very simple but accurate self-resetting delay. The device is a PLTS with the Interval set to 10 seconds, Reset State is Off and the SwitchMode is Delayed Toggle/Explicit Reset. The Reset Condition is (Icon > 90) where Icon is the Device Property of the PLTS IconState. There are no other Conditions or Properties, no Input Triggers, Schedules or Actions.
The delay is used by a PLEG as a lockout for a problem with an Aeon 4-in-1 MultiSensor. When the delay is required, the PLEG Action pokes the PLTS Trigger, triggers its own Bypass state and also puts the MultiSensor into Bypass. Ten seconds later, the PLTS switches to On which is a Trigger used by the PLEG to re-arm itself and the Multisensor. About 1 second later, the PLTS icon changes to its fourth state (value 100) which triggers its own Reset - ready for the next cycle.
I did try various alternative solutions but I could not get accurate and reliable operation - apart from using another PLTS as a reset generator. The IconState change is just sufficiently delayed to ensure the PLEG recognizes the On action and quick enough to be ready for the next cycle. Trying to do it with normal condition expressions either got me race issues or 1 minute blackouts waiting for the next NOW cycle.
I’m certainly open to suggestions for a less obscure solution.
I have been trying to find a less-obscure way to get a PLTS timer state (On or Off) back as a term for use in its own condition expressions. I cannot get it to work either as a Trigger or Property. I must be overlooking something. Could you suggest an alternative to the IconState, please?
BTW: Feeling bold, or maybe impetuous, I decided I needed to insert a condition into my most complex PLEG - whilst operating out of a hotel room with my laptop hooked to the internet via my mobile phone. It went without hitch. Many thanks for the tip.
I found a slightly less-obscure way to achieve a Reset or Bypass on a PLTS when the time interval completes. If t1 is the Input Trigger and t2 is the PLTS LasteStateChange property, the following works:
Bypass: t1; t2 > 1
Trigger: t1
Edit: This will only work under certain conditions so should not be considered a general solution.
I can, and do, use Immediate Toggle/Automatic Reset for most of my PLTS devices. I only have two instances where I’m using Delayed Toggle/Explicit Reset and adding a reset condition based on the PLTS toggle event. This is to achieve a delayed output “pulse” just sufficient to trigger conditions in other PLxx devices. These work fine so I really don’t need a Delayed Toggle/Automatic Reset mode. I’m sure you have better things to do.
The need to have the Toggle/Reset state of the PLTS available in its own conditions is usually to allow the Arm/Bypass state to be used as a latch. This avoids the need for an external VirtualSwitch in many cases and keeps the logic all in one place. It’s a very useful facility for situations that need more than simple timed-on or timed-off logic.
Hi Richard
I have a strange behavior with PLEG
After I modifiy some settings and then save them in VeraLite, if I go back to any PLEG (not only the one I modified) Conditions tab is empty (all the rows disapeared)
The only way to retrieve them is to reboot the Vera
Thus when the problem is present PLEG still continue to work
I deleted all my PLEG instances and removed the plugin, then reinstalled all but with no luck
IS there anything in the log files ?
You are on a newer Version of software than I am on.
I am on the current public release: 1.5.408
I have not seen any information about incompatibilities … Since I do not have a second Vera Unit I am not inclined to move forward until the new firmware is released commercially. If you have any errors from the
LuaUPnP.log or from the JavaScript console I will be glad to look at them and see if I can provide a quick fix.
MCV has provided feedback that a bug fix I gave them has been integrated into the new public beta.
I am running firmware release 1.5.622 and all my PLxx devices are working perfectly. I use both Chrome and Firefox on different PCs and haven’t seen any issues. One in a while I forget to reload the browser page after making changes to a PLxx logic and get a page full of undefined conditions. This frequently happens if I have modified two devices before hitting Save - probably not too wise. A page reload always fixes this.
MCV has provided feedback that a bug fix I gave them has been integrated into the new public beta.
They don't seem to have fixed the two-condition trigger. I still cannot set a PLxx input trigger to On and Armed.
@Rex and @Richard
I agree with Rex, what I did was to modify multiple PLEGs before saving…
I use Firefox and now my best friend is Ctrl+F5 ;D @Richard, I had the same behavior with v1.5.408
I made the upgrade because my Aeotec 4 in 1 and Fib 3 in 1 were not well supported
Thanks for your help…
Best Home Automation shopping experience. Shop at Ezlo!
