Persistence Presence Simulation [3.2.0;3.4.9)

logo

Simulates presence by playing back Item states from the default persistence from a number of days ago commanding the devices so they behave the same way, simulating presence.

Debug logging is available at the “Presence Sim” logger.

Parameter Type Purpose
Enable Simulation Switch Item Switch Item which, when OFF, will trigger the simulator rule to run. OFF was chosen to make it easier to tie the rule to an Item that tracks presence.
Simulation Items Group Group Item Group whose members are those Items that should be included in the presence simulation. All these Items must support commands (e.g. no Contact Items) and their states must be saved by the default persistence (e.g. no String Items if using rrd4j).
Num Days integer The number of days in the past to simulate the behavior from. It’s best to choose a multiple of 7 to correctly capture different behaviors between work days and weekends.
Minutes integer How many minutes between runs of the rule.

Language: Rules DSL

Dependencies:
Persistence is installed and configured and the default persistence saves the states of the Items that are to be simulated.

Changelog

Version 0.2

  • adjusted for breaking change, will no longer work for versions of OH prior to December 15th

Version 0.1

  • initial release

Resources

https://raw.githubusercontent.com/rkoshak/openhab-rules-tools/main/rule-templates/presenceSim/presence_sim.yaml

11 Likes

My occupation switch is sOccupied - it is a Switch Item. It is OFF when no-one is around.

Configuring this template and saving as a rule forces the comparison of sOccupied to true, for some reason, not ON. Is that intended? Screenshot below taken just after saving the rule for the first time, after having added the relevant Items during configuration.

(I think the description may also be wrong, but that doesn’t affect the automation at least!)

Can you post the code tab for the rule that was generated from the template? It’s hard to tell given just the screenshot.

configuration:
  simItems: gSecurityLights
  days: 7
  enableSim: sOccupied
  minutes: 5
triggers:
  - id: "1"
    configuration:
      cronExpression: 0 0/5 * * * ? *
    type: timer.GenericCronTrigger
conditions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: sOccupied
      operator: "!="
      state: "true"
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "3"
    label: Playback members of Simuation Item Group's states from Num Days days ago
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: >-
        val logName = "Presence Sim"

        gSecurityLights.members
                   .forEach[i | 
                           val hState = i.historicState(now.minusDays(7))
                           if(hState === null) 
                               logWarn(logName, i.name + " does not have a historic state for " + 7 + " days ago.")
                           else {
                             logDebug(logName, "Commanding " + i.name + " to " + hState.state)
                             if(i.state != hState.state)
                                 i.sendCommand(hState.state.toString)
                             else
                                 logDebug(logName, i.name + " " + " is already " + hState.state)
                           }
                       ]
    type: script.ScriptAction

Hmmm. I just don’t see how that could have happened.

The relevant part of the template is as follows:

conditions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: "{{enableSim}}"
      state: ON
      operator: "!="
    type: core.ItemStateCondition

The part in {{ }} gets replaced with the parameter, in this case your Item. But the state and operator part are hard coded. I can’t figure out how “true” got in there.

Everything else looks right in the rule though.

Try removing the template and readding it. Then generate a new rule from the updated template. If it’s still showing up as “true” we might need to pull in Yannick to figure out what’s going on.

You can see the actual template code by clicking on the link at the top of the first post.

Deleting the rule, removing the template, restarting openHAB, installing the template and creating a new rule results in the same thing happening, unfortunately.

Below my system details if it helps:

runtimeInfo:
  version: 3.2.0
  buildString: Release Build
locale: en-GB
systemInfo:
  configFolder: /etc/openhab
  userdataFolder: /var/lib/openhab
  logFolder: /var/log/openhab
  javaVersion: 11.0.13
  javaVendor: Azul Systems, Inc.
  javaVendorVersion: Zulu11.52+13-CA
  osName: Linux
  osVersion: 5.11.22-5-pve
  osArchitecture: amd64
  availableProcessors: 2
  freeMemory: 83789840
  totalMemory: 337641472
bindings:
  - astro
  - gpstracker
  - http
  - jellyfin
  - mqtt
  - network

Are you able to recreate this?

Does

state: ON

not need to be

state: "ON"

in the template?

I don’t think so but… try it

I just went back and tested my rule templates and I’m seeing the same behavior.

A template with a condition state of None

  - inputs: {}
    id: "3"
    configuration:
      itemName: "{{sceneModifier}}"
      state: None
      operator: "!="
    type: core.ItemStateCondition

is properly converted to

conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: Rule_SceneModify
      state: None
      operator: "!="
    type: core.ItemStateCondition

but a template with the condition state of ON

conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: "{{sceneController}}"
      state: ON
      operator: =
    type: core.ItemStateCondition

is changed to

conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: Auto_SwitchTest_Control
      state: "true"
      operator: =
    type: core.ItemStateCondition
1 Like

I think we need to bring in the big guns then. When I get to a computer I’ll file an issue (probably not before tomorrow). If someone gets to that before me please post a link here.

In the mean time, you can modify the rule generated by the template to fix it. Just use MainUI to change the true to ON and it should work.

Oh, it definitely does work when configured with ON!

1 Like

It’s a rule template. Who cares what language it’s written in if you never have to even look at the code?

Anyway, I am usually pretty lax when it comes to somewhat highjacking a thread except in the Marketplace categories.

This thread is the Marketplace publication. The original post in this category is how the template appears in MainUI under Settings → Automation. It makes no sense to come along and post an alternative raw chunk of code in this type of thread because:

  1. Very few users will ever see it. For most users all they will ever see is the first post in the thread because that’s all that’s shown in MainUI.

  2. The replies in this thread should be strictly related to the Marketplace entry itself: requests for help and stuff like that. Adding alternative implementations and side topics makes it very difficult for users of the rule template to ask for and get the help they need. This become especially true when people come along and need help with your code, and not the code in the original post.

So not only is it bad for you because almost no one will find your post. It’s also bad for the original post because it makes it harder to support their offering.

So please either create a separate Marketplace entry for this or, if you don’t want to turn it into a rule template, please create a new thread in the Tutorials and Solutions category. It’s better for you and it’s better for the Marketplace.