A beta update to PLTS has been provide.
See the topic [url=http://forum.micasaverde.com/index.php/topic,13421.0.html]http://forum.micasaverde.com/index.php/topic,13421.0.html[/url] for details.
Fixes bug with using timer inputs in a boolean expression.
Add Time Remaining on the Device Control on the Web.
Version 2.0 is now available at the APP store. (Also upgrade to 2.0 for Program Logic Core plugin.)
It includes support for Actions.
This completes the major functionality for this plugin.
Am I not expected to have more than a single PLTS 2.0 device in my config?
Asking because when I created a 2nd device, it wound up having the same Actions data as the 1st device I’d previously created. It also does not let me select “on” or “off” conditions to create actions in this 2nd instance. Those two conditions are already assigned actions on the 1st device.
Refresh your browser … any time you add ANY device to Vera.
I have 8 PLTS timers.
@RichardTSchaefer
I notice in your recently updated Program Logic Core documentation:
Also, the PLTS, PLEG (as appropriate) must be Armed for the actions to be executed.I am triggering an action in a PLTS immediately after setting it to [i]Bypass[/i] and it seems to be working. See: [url=http://forum.micasaverde.com/index.php/topic,3831.msg101455.html#msg101455]http://forum.micasaverde.com/index.php/topic,3831.msg101455.html#msg101455[/url]
Is this bad logic that could stop working following a change in configuration or an update to Program Logic Core?
No, the Arm and Bypass actions will still run … it’s a pre-bypass action and a post-arm action.
No, the Arm and Bypass actions will still run ... it's a pre-bypass action and a post-arm action.Thanks for that. Are [i]Arm[/i] and [i]Bypass[/i] actions special cases or do the same considerations apply to other PLTS actions?
The only other thing to worry about it the order of evaluations.
The order of evaluation for PLTS is the order in the Settings tab.
And it’s hardcoded.
I think I found a bug with this plugin. When you are creating your triggers, if you select “An armed sensor is tripped” and then try to select the state of the sensor, the state will disappear and so will the box where you name the trigger. I’m doing this in Chrome, so maybe it’s just a problem with Chrome.
I’m running Chrome (version 24.0.1312.57 m) and I haven’t seen this problem with PLTS. Are you using v 2.0 of PLTS and Program Logic Core? What type of sensor are you selecting? For strange problems in the UI, it is always worth reloading Chrome’s page after doing a Save.
Actually there are bugs in the MCV code that I use (and share with Scenes).
This happens when you try to make change after an initial selection.
You have to select the device and event type correctly the first time or you might have to delete and start over. I did not want to rewrite (and fix) all of the code in Vera.
I have already sent MCV some fixes to their code. But since it’s been a while since a release … I am not sure if these fix have been incorporated.
Issue with updating:
Just updated to latest versions. When I go to the “Conditions” tab of the existing switch all entries are undefined and I can’t change any values there. I get a message “No Implementation”
Under the advanced tab the values are set there and the switch appears to be working.
Also on your web site this page does not have the correct permissions:
http://rts-services.com/Vera/Plugin/PLTS/TypicalLightMotion/
I get an HTTP forbidden error.
I get the same error too, but I just installed the apps for the first time today.
I was trying to replace some scenes with so PLTS and PLEG devices, but I have run into a lot of trouble.
First my actions would run regardless wether the device (PLTS) was armed or disarmed. I want to define a schedule within the PLTS to arm and disarm itself in order to avoid running the actions. I have upgraded from 2.0 to 2.1 and now this seems to work out.
But I have lost my settings repeatedly. Under conditions all my triggers have changed into ‘undefined’ and I get an ‘invalid service’ message when I try to change something. I deleted all 5 of my PLTS devices and reconfigured them. But it just happens again.
What causes this behaviour? is it something that I am doing wrong?
Furthermore I wanted to use a value from a ‘variable container’ (plugin version1.6) under ‘device properties’. The names of variables seems to be read OK (VariableName1…5). But the numeric values (Variable1…5) are always returned as 0 even if the variable container actually contains a 2. Should the PLTS be compatible with the variable container?
But I have lost my settings repeatedly. Under conditions all my triggers have changed into 'undefined' and I get an 'invalid service' message when I try to change something. I deleted all 5 of my PLTS devices and reconfigured them. But it just happens again.Next time this happens, try reloading your browser page. It is best to do this whenever you do a [i]Save[/i] in the Vera UI.
Furthermore I wanted to use a value from a 'variable container' (plugin version1.6) under 'device properties'. The names of variables seems to be read OK (VariableName1...5). But the numeric values (Variable1..5) are always returned as 0 even if the variable container actually contains a 2. Should the PLTS be compatible with the variable container?I use this extensively and it works fine. There is a bug in VC 1.6 that prevents PLxx or scenes writing to variables 3 to 5 but this is fixed in version 1.7. Reading from all five variables should be fine in v1.6. If you are setting the VC variables by hand through the Vera UI, try reloading your browser page and see if that fixes it. Another possibility is that your data in the VC variables is not a valid number. Make sure you don't have any leading spaces or special characters in the fields.
I’ll remember that. Configurations can become quite advanced so reconfiguring gets boring…
I use this extensively and it works fine. There is a bug in VC 1.6 that prevents PLxx or scenes writing to variables 3 to 5 but this is fixed in version 1.7. Reading from all five variables should be fine in v1.6. If you are setting the VC variables by hand through the Vera UI, try reloading your browser page and see if that fixes it. Another possibility is that your data in the VC variables is not a valid number. Make sure you don't have any leading spaces or special characters in the fields.
Good to hear that this works, as it is a nice combination. I got it working OK now as well, again I needed to reload the browser instead of just hit the save/reload button.
Thanks for your help!
I’m still fighting the arm/disarm function to suppress actions.
I just wrote the following 2 posts back:
So I thought I had solved it; this was confirmed by tests. However, now my lights are coming on at daytime while the timers are disarmed… So apparently it wasn’t solved after all.
Just to be clear on my setup:
Inputs: Trigger - MotionSensor, DeviceProperties - DayNight status
Conditions: Arm - (DayNight == 0), Disarm - (DayNight == 1) , Trigger - MotionSensor, Restart - MotionSensor
Actions: Trigger - Switch light on, Reset - Switch light off
The DayNight status comes from Richards DayNight plugin. I expect this PLTS to be active (switch the light) only when it is armed. However, it is always active even when it currently is shown as disarmed…
I am pretty certain that I tested this a couple of hours ago and the lights didn’t come on when the PLTS was disarmed. I know I can also arm/disarm the sensor instead of the PLTS, but I want to reserve that functionality for my (kind of) alarm.
Does this problem have something to do with this issue:[quote=“documentation”][1] UI5 has a bug with events with more than 1 condition variables in scenes. Two of my events have 2 condition variables. If you want to use these, email me, I can tell you how to patch your UI5 to work. I have provided fixes to MCV. I hope they will integrate these soon.[/quote]
I really hope I can use this functionality this way…
Add the Day/Night term into your Trigger and Restart expressions:
Trigger: MotionSensor and (DayNight == 0)
Restart: MotionSensor and (DayNight == 0)
You can then remove the Arm and Bypass conditions.
Also change your actions from Trigger and Reset (which are really inputs) to On and Off:
On: Turn Lights On
Off: Turn Lights Off
Actually, changing these actions should make your original logic work but I still think it is better to suppress the Trigger and Restart during the daytime. It may help with future enhancements. 
You could also change the DayNight input from a Device Property to a Trigger like: Night: DayNight indicates Night then your conditions would be:
Trigger - MotionSensor and Night
Restart - MotionSensor and Night
It may not work any better but it makes more sense when you see it in a few months time. ;D
The DayNight status comes from Richards DayNight plugin. I expect this PLTS to be active (switch the light) only when it is armed. However, it is always active even when it currently is shown as disarmed...
The Arm/Bypass state only affects the On and Off actions. The other actions will still fire.
Edit: I should add, before RTS spots this, that PLTS conditions function as both inputs and outputs. If you give a condition an expression, you’re using it as an input. If you define an action for it, you’re using it as an output.
Many thanks for your explanation. Now I understand most of it.
I already wondered what the point was with the on and off conditions but it makes sense as output 8). With the move of the actions from trigger/reset to on/off the arm/disarm functionality now works. But as you said: I want to prevent the trigger and reset from happening. Therefore used the (DayNight == 0) instead.
I also changed the day/night from property to trigger. But to me it made more sense to consider day/night as a condition rather than a trigger, and therefore I asked for the day/night property. A trigger is something instantaneous instead of a condition. But I guess that the state of all triggers is evaluated when any of the triggers occurs.
I learned a lot of new stuff with the PL things today! It is great to have all these possibilities in one place!
I also changed the day/night from property to trigger. But to me it made more sense to consider day/night as a condition rather than a trigger, and therefore I asked for the day/night property. A trigger is something instantaneous instead of a condition. But I guess that the state of all triggers is evaluated when any of the triggers occurs.Well sometimes it's a personal taste thing. Device Properties are great for testing quantities (> 10, < 100, etc). For things that have only two states (on, off), I usually use a Trigger and name it appropriately. I have triggers called [i]ItsDay[/i] and [i]ItsNight[/i] in my PLxx devices so, when I come to massage the logic at some future point, it is clear what they are. That's the result of several times, over the years, when I forgot how I made things work in the first place! ;D
The PLxx plugins are, to me, the best way to achieve almost any logic and timing requirement. As you say, they allow you to keep it all in one place.
I’m happy to hear it’s making sense. 