Hi
I have a scene I setup with a schedule but its not working quite right, can I disable the scene without deleting it ?
Thanks
Edit the scene, go to the “Schedules” tab, and uncheck the “Enabled” checkbox. You can do the same for the “Triggers” tab.
Don’t forget to hit “Confirm changes” and then “Save” to store it!
[quote=“PurdueGuy, post:2, topic:172421”]Edit the scene, go to the “Schedules” tab, and uncheck the “Enabled” checkbox. You can do the same for the “Triggers” tab.
Don’t forget to hit “Confirm changes” and then “Save” to store it![/quote]
Nice one thank you!
Can the schedules be activated/deactivated with a luup code ?
I don’t yet have a Vera. I’m eyeing off the Vera lite.
Can I confirm that PurdueGuy means that you can enable/disable an individual trigger or schedule (and PurdueGuy doesn’t mean that the enabling/disabling is done with respect to the whole Schedule or Trigger tab), without having to delete and recreate them?
Can I also confirm this to be readily achievable in AutHomationHD, or another Android Remote Control App?
Most if not all apps do not allow full control over vera. Meaning the creation or modification of scenes etc. You’ll need to do this in Vera’s Web interface or use a virtual switch and have the scene check it’s state before running. The second option allows you to control via most apps.
- Garrett
Thanks garrettwp. But I’m still unclear.
As I understand it Scenes are conceptually and programmatically distinct from Triggers and Schedules (although a schedule is a kind of Trigger), albeit that you use Triggers and Schedules to run Scenes.
Thinking specifically of Triggers and Schedules, do you mean:
[ul][li]These can be readily enabled/disabled (without having to delete and recreate them) through Vera’s Web Interface; and [/li]
[li]These can be readily enabled/disabled (without having to delete and recreate them) through Vera’s Web Interface with a Virtual Switch Plugin (which is useful if you need to check state before running); and[/li]
[li]These can be readily enabled/disabled (without having to delete and recreate them) through (your good looking) AutHomation Android App, and most other Phone Apps, if the Virtual Switch Plugin is installed in Vera’s Web Interface.[/li][/ul]
?
As I understand it Scenes are conceptually and programmatically distinct from Triggers and Schedules (although a schedule is a kind of Trigger), albeit that you use Triggers and Schedules to run Scenes.
Almost true. Schedules are really timed triggers. Triggers can have Luup code attached, schedules cannot. Scenes can have Luup code too, which gets run after any trigger code. Trigger code and scene code run in the same context and can share variables. An excellent diagram available from the wiki here:
http://wiki.micasaverde.com/index.php/Luup_Scenes_Events
These can be readily enabled/disabled (without having to delete and recreate them) through Vera's Web Interface;
TRUE, as described completely in @PurdueGuy’s reply. (Edit: Although I would hesitate to use the word ‘readily’ since it requires a START to save the state, hence rather interferes with the running of the rest of the system).
These can be readily enabled/disabled (without having to delete and recreate them) through Vera's Web Interface with a Virtual Switch Plugin (which is useful if you need to check state before running);
TRUE unreservedly for triggers, although you will need some Luup code in the trigger to check the status of the virtual switch and [tt]return false[/tt] to stop the subsequent scene from running. You CAN’T do this for schedules because you can’t add Luup code, but you could put that into the scene code assuming that you could infer that this was the intended meaning (ie. to stop the schedule running - more difficult if you have a scene with both triggers and schedule(s)).
These can be readily enabled/disabled (without having to delete and recreate them) through (your good looking) AutHomation Android App, and most other Phone Apps, if the Virtual Switch Plugin is installed in Vera's Web Interface.
TRUE. A virtual device should appear as any other Z-Wave device on a well-honed app. However, in terms of direct interaction with scenes, most apps don’t allow anything but the running of scenes (ie. can’t usually disable a scene without the Luup code and virtual switch approach described above).
Straight-forward - yes?
akbooer Thanks. That teaches me a great deal.
I’ll repeat back some of that to verify I’ve understood. I’ll use a specific example to lay bare the goal here (the specific case that served as the catalyst for my looking into Home Automation): A Guest Electric Blanket.
I want my Guest’s Electric Blanket to operate as follows:
[ol][li]A schedule will turn on the blanket via a Aeon SmartSwitch at 18:00 (say);[/li]
[li]When the guest goes to bed I manually turn off the blanket via my Phone’s App; and[/li]
[li]I can toogle the Schedule on/off from my Phone’s App, based in whether they intend to sleep over (they might sleep over for a few nights in a row).[/li][/ol]
Point 3 has been our issue. From what you’ve written it seems this is readily achievable. Specifically, I
[ol][li]Vera Web Interface > Setup a Guest Electric Blanket Scene, a scene with one Aeon SmartSwitch.[/li]
[li]Vera Web Interface > Setup a daily schedule to fire the Guest Electric Blanket Scene. [/li]
[li]Vera Web Interface > Install Virtual Switch Plugin.[/li]
[li]Phone App (like AutHomation/AutHomationHD). Observe that the Virtual Switch appears as a Virtual Device.[/li]
[li]Vera Web Interface > Edit the Guest Electric Blanket Scene’s Luup Code, which runs before Scene execution, to check on the Virtual Switch State (if off then abort).[/li]
[li]Phone App (like AutHomation/AutHomationHD) > Toggle my Virtual Switch as I desire.[/li][/ol]
So as a matter of code operation the schedule will fire everyday. It will only carry through and turn on the Hardware switch if the Virtual Switch is also on.
Alternatively, so goes the full technical explanation, I could disable the schedule directly via the Vera Web Interface. But in practice that’s going to less convenient that hitting a Virtual Switch in an Android App (and it would render the Virtual Switch on the Android App temporarily inoperable).
You mean, incidentally, “since it requires a ‘SAVE’ to save the state”? You’re talking of the need in Vera’s Web Interface to save changes back to the firmware which takes a few seconds?
John
Spot on. The scheme is amenable to refinements:
[ul][li]by analogy with a heating controller’s “extra hour” button, your virtual switch could simply function as “Extra night”… if the scene runs then it switches the virtual switch off - that way you can’t accidentally leave it on for several nights.[/li]
[li]similarly, you could have another schedule which always runs and switches the blanket off at, say, midnight, so that if you don’t roast your guest by accident.[/li][/ul]
You mean, incidentally, "since it requires a 'SAVE' to save the state"? You're talking of the need in Vera's Web Interface to save changes back to the firmware which takes a few seconds?
Yes, typo, I meant SAVE. But note that this forces a Luup reload which is not really what you want in an active system. It’s one of the reasons I have multiple Veras, so that I can experiment on one without impacting everyday operations supported by the others.
akbooer,Terrific! Thanks for the verification.
Do you mean the SAVE reloads (and resets) the current Luup code you are working on; or all Luup code in the Vera is reset?
Either way I’m a bit vague about why this might be a problem because I’m vague about the extent to which Vera is operating according to a Stateless Protocol. Ultimately this is all operating by http messaging (so I understand), so each http message ought be independent of state at the time of a previous http message.
So, to use one of you excellent examples of scheme refinement, that you http a “turn of” message to the electric blanket at midnight achieves the desire result regardless of whether the blanket was previously turned on or not.
Perhaps the requirement to program in terms of a stateless protocol, better called a “state independent protocol” given that objects do take on states, is something one needs to be disciplined about when coming from other programming contexts.
This could be exemplified, perhaps, by imagining a further refinement to address a problem with the current Guest Electric Blanket scheme.
The current Guest Electric Blanket scheme doesn’t handle the case when I discover my Guest’s intentions to sleep over at late notice, at 19:00 for example. When I toggle my virtual switch “On” my guest’s electric blanket will not turn on that night for the schedule fires once at 18:00. So the virtual switch is wrongly state dependent (it depended on the time of day being before 18:00).
To rectify this I make the following refinement: Create a trigger that goes off when the Virtual Switch is switched to “On” that runs the Guest electric Blanket scene if after 18:00 and before Midnight. I also create a trigger that turns the electric blanket off whenever the Virtual Switch is in the “Off” position.
In this way the Virtual Switch, when switched “On” will either:
- Turn on the Electric Blanket on immediately (if between 18:00 and midnight); or
- Turn on the Electric Blanket at the Schedule time (at 18:00).
When “Off” the electric blanket will be turned off immediately and the schedule will not fire that day (because the Scene only goes ahead when the virtual switch is in the “On” position, as originally set up).
… and so the Virtual Switch functions in a manner that is independent of the State of the rest of the system.
I’m not sure if this all demonstrates a fundamental problem with Home Automation in general or Vera in particular: that it has to be (or merely is) coded in a state independent manner; and that coding for state independence can get complex very quickly (even when setting up relatively trivial scenarios).
But no doubt I’d see why your having a development V production Vera would make life easier in practice, if I stepped into the HA/Vera world.
Something which is more likely given that you’ve helped me see what is possible with Home Automation, and Vera in particular. It looks to be both a frustrating and exciting toy to play with.
You may find Program Logic Event Generator a useful tool as well.
See:
http://forum.micasaverde.com/index.php/topic,13802.0.html
I fear we have wandered from the original intention of this thread, however…
Do you mean the SAVE reloads (and resets) the current Luup code you are working on; or all Luup code in the Vera is reset?
Restarts the whole system, and this can cause problems because, for example, there may be outstanding schedules whose correct operation depend on states which are not preserved across system resets. There are ways around this. Vera is far from stateless.
Perhaps the requirement to program in terms of a stateless protocol, better called a "state independent protocol" given that objects do take on states, is something one needs to be disciplined about when coming from other programming contexts.
You have put your finger on why HA is not entirely straight-forward. Whilst it’s true that some people never come to grips with the finer points of programming (Lua is an amazing tool), the real challenge is understanding what they really want to do and the ramifications of the sometimes convoluted logic that they construct to achieve it. It’s the reason why people still struggle when presented with an alternative such as PLEG, which RichardTSchaefer has pointed you towards… just go and look at the forum and how many problems people raise with logic and sequencing even when using this option which raises them above the level of a conventional programming language (albeit you still have to learn something of a syntax). It is as you said:
I'm not sure if this all demonstrates a fundamental problem with Home Automation in general or Vera in particular: that it has to be (or merely is) coded in a state independent manner; and that coding for state independence can get complex very quickly (even when setting up relatively trivial scenarios).
And you also have it, once again, “spot on” when you say:
It looks to be both a frustrating and exciting toy to play with.
We REALLY need to start a new thread if we are to continue in this vein.
akbooer, thanks for indulging my drawing us somewhat off topic. I think we’ve suitably covered that tangential issue, of the general nature of HA/Vera programming, such that a separate thread is not necessary 
RichardTSchaefer, thanks very much! Your PLEG and PLTS plugins look essential. It’s likely they’d help in the Guest Electric Blanket scheme I’ve outlined. Apart from the Luup syntax hiding you’ve provided a tool to help reduce the complexity in virtue of
… I have therefore less to fear.