1.1.1183 is quite stable, so it's time to re-add some randomness to Vera

Proposal for a Randomizer Luup plugin (as a compromise between usability and ease of implementation)

Device variables:

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.

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

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.

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.

Just a link to some additional ideas by guessed:
http://forum.micasaverde.com/index.php?topic=2826.msg33615#msg33615

Another approach to a randomizer plugin:

Record all actions and replay the actions with a random timeshift (global or per action):
[tt]
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
[/tt]
Unfortunately, [tt]record[/tt] doesn’t save timestamps. If it would, it would be quite easy to convert the recorded actions to calls to [tt]luup.call_timer()[/tt].

Feature request:
http://bugs.micasaverde.com/view.php?id=1428

@Ap15e & @Guessed

Is there any progress on this?

@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)

I’m waiting for feature #1428