[SOLVED] "Pausing" Presence Simulation with Google Calendar Scheduler

Hello, and first of all thanks. Thanks to you all, I´ve learned a huge lot from all of you. In a few weeks I came from dont-know-what-im-doing to managing my whole home.

I tested presence simulation with google calendar and it works like a charm. Whole weekend of on-off lights

I was wondering if there could be a way to “pause” event saving into calendars. I only need this feature enabled from time to time, and dont want my whole life recorded.
So I´m thinking about using exec binding: when switch “Record” is ON system replaces addons.cfg and gcal.persist files with other called addons.cfgGCAL and gcal.persistGCAL which contains bindings and strategies. When “Record” is OFF, files are addons.cfgNOGCAL and gcal.persistNOGCAL (same as the others but everything related to gcal commented).
I´m sure this is not an elegant way to do it, but this could be effective. I dont know if messing with these files this way could lead to a problem.
I´m also aware that, for example, if i touch addons.cfg for enabling/disabling bindings i have to do it in both -gcal and -nogcal files… (is there an “include” feature for these files?)

Thanks again for all your articles, topics and support, its amazing.

How is the recording of the events to GCal done?

I wouldn’t do anything with the services configs like proposed. But what I would do largely depends on how this works. You don’t have to remove the GCal binding to turn the behavior on and off. There are far more flexible approaches that are possible.

There are also other ways to implement this. For example, you can store the events locally using Persistence and then you have a Rule that runs periodically to set everything to what ever state it happened to be in seven days ago. I document that in Presence Simulation.

Hi, thanks for the answer.
Gcal presence was the first presence simulation I came across and, since it worked for the first time and was only a few lines of code, I took it. I have only read about persistence (and your elegant seven-days-ago solution), when I get into it I´m sure it will lead to another -much better- solution.
The thing with gcal is: it was so easy to implement and there is a extremely easy wait to test it and to control if it works, just with my calendar mobile app.
The way recording is done is told by gcal.persist

Strategies {
	default = everyChange
}

Items {
	G_PresenceSimulation* : strategy = everyChange  // NOGCAL file contains this line commented, GCAL file doesn´t
}

Gcal binding removing is just a personal preference, I love to save as much as ram as I can (I have even paperui disabled and only run it when needed—not so much as I’ve learned to use config files)
The point is: changing those files has a bad effect? I’m not planning to change it on a regular basis, only when needed. I’m only away each couple, three months.

OK, so it uses a persistence engine.

It can. You run the risk of corrupting the cache which will break OH until you clear the cache.

The question is, does this actually save much RAM? Have you done a before and after comparison to see if it does? If either save more than a few MB of RAM I’d be surprised. And saving RAM in this manner only makes sense if you are running short of RAM. And if you are actually running that short of RAM, wouldn’t you rather have OH reserve the full amount of RAM it needs in all circumstances instead of discovering one day you can’t install PaperUI because you’ve run out of RAM?

That also raises another issue. Unless you are rebooting OH after removing the bindings, you actually are not reducing the RAM OH is currently using. Once a Java program acquires RAM from the system, it never gives it back.

It would be safer over all to do this file move only on the persist file. It would be more elegant to leave these configs alone and control what is saved using rules.

I can think of a couple of ways to do it. Perhaps the easiest would be to remove the Group from the gcal.persist file. Then use the following Rule:

rule "gcal recording"
when
    Member of GPresenceSimulation received update
then
    if(Record.state == ON) triggeringItem.persist("gcal")
end

This will only record updates to the calendar when Record’s state is ON. If you only want to record commands or changes, change the Rule trigger.

With this approach you avoid the potential disruption from messing with config files from a Rule, the possibility of corrupting the cache, and you have full control of what get’s saved. And it’s a one liner Rule.

1 Like

Cool.
It’s so so nice to learn more and more. Thanks for this elegant solution, and also for the file replacement explanation.
I didn’t know how openhab treated Ram, but I know now… And yes, I don’t have plenty of mem, it always loads up to 80-85 in my Zero W 512MB

Thanks!

Long run you will not be happy with a Zero W. The minimum recommended machine is an RPi 2.

1 Like

I see… Just for this learning time is quite enough. I’m waiting for the pi 4 so my 3b will host openhab (and other things like openvpn or plex)

You might want to run Plex on a separate machine. The problem is both OH and Plex want to use the same port for automatic discovery on your local network. I think it’s 5353 or something like that.It can be done but you would be losing some small features on one of the servers or the other.

1 Like

Tested, working and added to my system. Thanks!!!