CalDAV Binding to record presence events and light switch events

presencesimulator
caldav
Tags: #<Tag:0x00007fadf31a30d0> #<Tag:0x00007fadf31a2f90>

(Carsten Wuthenow) #1

Hi,

I successfully installed + setup the CalDAV binding. Now I was wondering if it would be possible to record items and write it directly into an owncloud calendar. The use case is quite simple: record real life in our house (presence items, switching light object on/off, …) and directly create calendar items for now+2 weeks. That would enable me to simulate presence for the time being in vacation. Creating complex presence simulation is quite painful (I’d have to add several calendar items and change the begin/end times not to repeat the same pattern each day). Any idea if the is doable with the current bindings?

Thx,
Carsten


(Rich Koshak) #2

The approach in this thread would be much simpler.

I personally do not think the CalDAV binding is suitable for this use case, even if it were technically feasible, which I am not sure one way or the other.


(Carsten Wuthenow) #3

Thx Rich! Great approach. Right what I was looking for. Will try and play with the parameters. Is this also working with rrd4j persistence or do you recommend to use another persistence that is handling more accurate data (if I remember rrd4j is compacting data and historic states become more and more inaccurate the more you go into the past).


(Rich Koshak) #4

I recommend using something other than rrd4j because in OH 2.x rrd4j doesn’t store the states of Switches any longer. A presence simulation that can’t handle turning on and off lights is pretty limited.

I personally use InfluxDB because of its nice integration with Grafan for pretty and configurable charts.

See:

Though if you want something lighter weight you can use Derby, H2, or SQLite. I also noticed a “Google Calander Presence Simulator” listed in PaperUI. I’ve no idea when it came about and there is no documentation for it (which probably means you need to be running a 2.2 SNAPSHOT to get it).


(Carsten Wuthenow) #5

The rule works great! Saved a lot of time and is sooo easy to implement. Great job Rich. Even with rrd4j it is working. Will try to use influx persistence.


( ) #6

@rlkoshak As everybody is constantly referring to this Tutorial I wonder if it is time to mention it in the official documentation :thinking:


(Rich Koshak) #7

It is perhaps the most read and most linked to article on the whole forum.

The only challenge I see is capturing all the goodness posted as replies (e.g. Docker, autorefreshing iframes, etc).


( ) #8

I’ve tried to include all of them in the first post! I’m constantly updating the article. Please let me know what’s missing.

I could also open the article up as a “wiki” article just like the FAQ.


(Rich Koshak) #9

The wiki might be a nice compromise, though getting people to update versus just continuing the long thread may be a challenge.

I think at this point the existing article works fairly well. I wouldn’t worry too much about converting it to something else unless you want to.

The wiki idea is a nice compromise.

A new tutorial or entry in the docs would be nice but might become rather lengthy.


( ) #10

I was not talking about the openhab 1 GitHub wiki. I would like to delete this one rather sooner than later :wink:

I was talking about the posibility to convert a threads first posting into a “wiki posting” just like I did with: Frequently Asked Questions (FAQs)

I’d rather not move tutorials to the docs page. Posting and updating them is easier here for the “common user” and with the ability to discuss the tutorials the forum is the right place to share and enhance them. I’d like to reduce the docs Tutorials section to two parts eventually: 1. Basic Getting Started Tutorial, 2. links to the community forum.


(Rich Koshak) #11

Oh, I know. you were talking about a wiki forum posting, like the FAQ.

I think we are on the same page.