We have moved at community.getvera.com

Author Topic: 1.1.1183 is quite stable, so it's time to re-add some randomness to Vera  (Read 6182 times)

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Proposal for a Randomizer Luup plugin (as a compromise between usability and ease of implementation)

Device variables:

Code: [Select]
Active          0 or 1
IntervalMin     wait at least IntervalMin seconds for next action
IntervalMax     wait at most  IntervalMax seconds for next action
Device1         device id of device to randomize, optionally postfixed by the name of the device
Device2         ...
Device3
Device4
...
Device10

Algorithm:

at startup:
display a warning if a device does not support urn:upnp-org:serviceId:SwitchPower1

then:

repeat
  wait from IntervalMin up to IntervalMax seconds, then if Active randomly select one device and toggle its state
until false


Activation/Deactivation:
luup.variable_set( 'Randomizer plugin', 'Active', 1/0, devid )


Notes:
When you deactivate the plugin, the states of the devices are indeterminate. This shouldn't be a problem,
because typically you'd deactivate the Randomizer plugin within your "All off"/"Go to bed" scene.
One question remains: what gets executed first within a scene, the Luup code or the Commands?
Chances are that the Luup code gets executed first, because the Luup code can cancel the whole scene ...

If necessary, use multiple instances of the Randomizer plugin (or assign a group id to a device via the device variables
to save memory: Device1, Device1Group, Device2, Device2Group, ...)

Any comments are welcome.

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: 1.1.1183 is quite stable, so it's time to re-add some randomness to Vera
« Reply #1 on: February 05, 2011, 10:16:03 am »
You might want a "weighting" for the action at the decision points. 

ie. 30% chance of "On", 5% chance of "On" etc.

This will allow some lights to be "more on" than others as you go around randomizing them, attempting to simulate the behavior of "Main" lights (60%) vs "Bedroom" (20%) or even "Bathroom" (2%) lighting (simply as examples, not representative usage data)


This will amuse you...
    http://forum.micasaverde.com/index.php?topic=2826.msg11175#msg11175

Offline maks327

  • Sr. Newbie
  • *
  • Posts: 28
  • Karma: +0/-0
Re: 1.1.1183 is quite stable, so it's time to re-add some randomness to Vera
« Reply #2 on: February 05, 2011, 10:27:26 am »
This is MUCH simpler than what you're proposing (and less powerful), but here is a luup script I've used in scenes to randomize when a single light is turned on.

Quote

local RandomRange = 3600
local RanNumb = (math.random() * RandomRange)
local brsDevice = 9
local brsDimLevel = 80

luup.call_timer("RandomDelayOn", 1 , RanNumb,"","")

function RandomDelayOn()
   luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget",{ newLoadlevelTarget=brsDimLevel },brsDevice)
end

In this case, the light will be turned on at 80% dim at some random time over the next hour, triggered by whatever event/timer is set for the scene.  It wouldn't be difficult to expand this to multiple devices, etc.  I like your proposed plugin, just throwing this out there in case someone is looking for a simple fix for a single light or two.

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: 1.1.1183 is quite stable, so it's time to re-add some randomness to Vera
« Reply #3 on: February 24, 2011, 04:15:07 am »
Just a link to some additional ideas by guessed:
http://forum.micasaverde.com/index.php?topic=2826.msg33615#msg33615

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: 1.1.1183 is quite stable, so it's time to re-add some randomness to Vera
« Reply #4 on: February 28, 2011, 10:43:26 am »
Another approach to a randomizer plugin:

Record all actions and replay the actions with a random timeshift (global or per action):

http://ipaddress:3480/data_request?id=scene&action=record
http://ipaddress:3480/data_request?id=scene&action=pause&seconds=y
http://ipaddress:3480/data_request?id=scene&action=stoprecord
http://ipaddress:3480/data_request?id=scene&action=listrecord
http://ipaddress:3480/data_request?id=scene&action=deleterecord&number=x

Unfortunately, record doesn't save timestamps. If it would, it would be quite easy to convert the recorded actions to calls to luup.call_timer().

Feature request:
http://bugs.micasaverde.com/view.php?id=1428
« Last Edit: February 28, 2011, 10:58:07 am by Ap15e »

Offline Henk

  • Hero Member
  • *****
  • Posts: 820
  • Karma: +3/-0
@Ap15e & @Guessed

Is there any progress on this?
| Vera2 @ UI4 1.1.1350 / 3.20 | Vera Lite @ UI5 | Vera 3 @ UI5 | 2x Merten  504519 | 1x Duewi  064374 | 1x Everspring SM103 doorbell mod |1 Y-cam IP cam | various LUUP plugins |

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
@Henk,
I'm not working on it.  Seemed like @Ap15e was working on a version so I never developed mine further (or even tried to get it working, for that matter)

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
I'm waiting for feature #1428 ...