Presence Simulation with Google Calendar Scheduler

Add-ons Bindings
1

Hi,

I would like to do a presence simulation with Google Calendar Scheduler.
It’s all described in the github and switching on and off lights works for me.

But how to switch on and off presence simulation with a single switch?
Is there a way to check if a trigger comes from the calendar or from a local event?
I would like to switch off all calendar triggers if simulation is off.

Any idea how to realize a main switch for presence simulation?

I hope I do not have to add a simulation item for each existing item and
set up a rule for a main switch.

2

I believe you just need one Switch item named PresenseSimulation, iirc.

1 Like
3

I thought this switch is just to enable the writing to the Google calendar.
But you may be right. Online help says:

“To activate the Presence Simulation simply set PresenceSimulation to ON
and the already downloaded events are being executed.”

I will try. Thanks.

4

(the second s must be a c)

If you have an entry in your Google Calendar with the title

[PresenceSimulation] <item alias, not important>

and the entry’s description contains commands as described in the wiki, then the commands will only be performed if the item named PresenceSimulation exists and is currently in the ON state. You cannot choose a different item name; it must be exactly PresenceSimulation.

The Google Calendar Presence Simulator is a persistence service that creates new calendar entries some fixed number of days in the future for each item that matches the criteria set in gcal.persist. It adds new entries in the format described above.

5

Good catch! Thanks!

1 Like
6

Thanks a lot for the explanation.
I missed the topic with the calendar entry titel and the switch item for PresenceSimulation.
I thought it is just for the persistence option which I do not use.
Now I introduced the item:
Switch PresenceSimulation “Presence Simulation”

and set up an calendar entry like this:

It works, but the thing is that it works always, even if the PresenceSimulation switch is OFF.
I tried it with and without […]. No difference.
Also openHAB was re-started with no effect.

I have not introduced the group G_PresenceSimulation since I’m not adding events automatically.

Maybe someone has again an idea. Thanks for your effort.

7

Ok. It works for single line content in the calendar like:
send Light_UG_Frank_Bed ON

This can be enabled and disabled with the PresenceSimulation switch.

But this means that someone needs two entries, one for ON and one for OFF.

8

Yeah, I was just looking at the code, and that’s the way it appears to work. When adding events automatically, there would be just a single command added to the calendar each time an Item in the group changes state. I’m not sure the design expected PresenceSimulation events would be added manually the way you did (although I think it’s a pretty creative way to use the Gcal Presence Simulator).

9

Now I have been setting up the complete system for Presence Simulation including
Google Calendar Scheduler and Google Calendar openHAB Persistence.
Works well.
Let’s see if I’ll take the whole implementation or just the manual configured Scheduler.

Many thanks for the great help.

1 Like
10

I think it’s an issue (minor, but an issue) that the [PresenceSimulation] in the title is not affecting an event where the description has start and end stanzas. Worth an issue report?

1 Like
11

Good point. Issue opened.

1 Like
12

Hey all,

first of all thanks for the great binding. Makes my home a bit more smarter with the GCAL persistence. Persistence is working with dimmer and switch items. But I have an issue with rollershutter items.

Rollershutter RS_EZ 			"Esszimmer %s" 		 ( gEZ, gPreSim )  {knx="4/1/42, 4/1/41, <4/1/43+4/1/40"}

This item is not recorded in persistence.

I have another issue using dimmer items the item is recorded, but it does not switch on or off when presence simulation is on.

Dimmer  Dimmer_EG_EZ        	"Esstisch Lampe" 	 ( gEZ, gPreSim )  [ "Lighting" ] { knx="1/1/41,1/1/43,1/1/42" }

The description of the calendar entry seems fine for a dimmer item.
send Dimmer_EG_EZ 100 and
send Dimmer_EG_EZ 0

If I change 100 to ON and 0 to OFF it works.

Anyone having the same issues?

Thanks
Thomas

13

I openhab successfully linked to google calendar.

Anytime I want to play the simulation nothing happens.

I made a switch in items

Switch PresenceSimulation “Simulatie” (Diverse)

When I switch it to ON, it would have to play the recorded telegrams?

I have no idea what I’m doing wrong

14

Do you have entries in your calendar whose title starts with [PresenceSimulation], such as this?

15

Yep

presence.png1039×379 5.55 KB

16

Hmm. Maybe it’s an issue with the dimmer, as that’s the only difference I see between our two calendar entries. Could you try changing the 50 to ON to see if it makes a difference?

17

The other thing you could try would be to put the gcal service into debug mode using this command in the karaf console.

log:set DEBUG org.openhab.io.gcal

In the openhab.log file, you should see lines that look like this when the calendar event is downloaded from your calendar.

2017-01-24 07:49:15.305 [DEBUG] [io.gcal.internal.GCalEventDownloader] - created new startJob '[PresenceSimulation] PD300Z_Dimmer' with details 'SchedulerJob [jobKey=ouh754uq40s74nmqule62qm59c@google.com_start, jobGroup=gcal, 1 triggers=[Tue Jan 24 07:52:00 EST 2017], content=send PD300Z_Dimmer 53'

And lines like this when the command executes.

2017-01-24 07:52:00.002 [DEBUG] [gcal.internal.util.ExecuteCommandJob] - Command [send, PD300Z_Dimmer, 53.0, ] has been sent
18

Hi Mark,

It seems like the translation to KNX is not doing well

20:16:29.005 [DEBUG] [gcal.internal.util.ExecuteCommandJob] - Command [send, Licht_sluis, 50.0, ] has been sent
20:16:29.007 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘Licht_sluis’ received command 50.0
20:16:29.013 [WARN ] [.binding.knx.internal.bus.KNXBinding] - Value ‘50.0’ could not be sent to the KNX bus using datapoint ‘command DP 1/1/52 Licht_sluis, DPT main 0 id 5.001, low priority’ - retrying one time: 5.001 Scaling: wrong value format: 50.0
20:16:29.020 [ERROR] [.binding.knx.internal.bus.KNXBinding] - Value ‘50.0’ could not be sent to the KNX bus using datapoint ‘command DP 1/1/52 Licht_sluis, DPT main 0 id 5.001, low priority’ - giving up after second try: 5.001 Scaling: wrong value format: 50.0

19

Unfortunately, I’m not familiar at all with KNX, so I can’t offer any help with that. I wonder if KNX is expecting an integer (50) rather than the decimal value it’s being sent (50.0). I assume the light can be operated successfully using the Basic UI (or whatever UI you may be using).

@watou Should GCAL be sending the command as an integer value?

The calendar event is this.
send Licht_sluis 50

But gcal is sending this.
send Licht_sluis 50.0

20

The code here is just sending the command it parsed:

                    if (args[0].equals("send")) {
                        if (args.length > 2) {
                            Item item = registry.getItem(args[1]);
                            Command cmd = TypeParser.parseCommand(item.getAcceptedCommandTypes(), args[2]);
                            if (cmd != null) {
                                publisher.sendCommand(item.getName(), cmd);
                                logger.debug("Command {} has been sent", Arrays.asList(args));
                            } else {
                                logger.warn("Command '{}' is not valid. Command not sent.", Arrays.asList(args));
                            }
                        }

If the command stored in the event description is send Licht_sluis 50 but the command being parsed is a DecimalType with a scale of 1 (50.0), then that sounds like there is a problem round-tripping the value (in other words, a possible bug in the layers below org.openhab.io.gcal – compat1x, ESH, not sure).

What exactly was stored in the calendar event description? (It looks like you gave the answer already.)

Last edit: it doesn’t look like a KNX bug, but maybe KNX exposed a bug somewhere else.