openHAB can integrate Google Calendars. The functionality is kind of limited, it can only see the current and the next calendar event, but in my case that is enough. More about the use case in another blog post.
There are three different calendar bindings available, let's have a quick look:
- CalDAV Personal Binding: this is a v1 binding, which means it will no longer work in the soon-to-be-released openHAB v3. Apparently this works with Google calendars, but has performance issues. It can show the current and next event.
- Google Calendar Scheduler: also a v1 binding. Needs more work for presense simulation, and additional bindings.
- iCalendar Binding: v2 binding, should work with v3. It can show the current and next event. That's the one I'm going to use.
Continue reading "Add a Google Calendar to openHAB"
A very common use case for hooks in git is a "pre-commit" hook. This hook is used to verify the to-be-committed data before it is added to the repository.
One important note: hooks are not part of the repository itself. Everyone can install a hook on it's own checkout of a repository, but by default the hook is not there when you clone/checkout the repository. This avoids security problems by executing arbitrary code during "git commit", or any "git" operation.
Because of this implication it is common that developers install a hook from somewhere in the repository into the ".git/hooks" directory. And in addition, the server side (the repository) can run the same checks during "git push", to enforce the rules.
Hooks in git work in a simple way: whatever program or script is run as the hook has to set a return code. If the return code is "0", git proceeds. If it's not "0", git aborts the operation.
Continue reading "git pre-commit Hooks"
openHAB rules files are lazy loaded. When a rule is used the first time, the entire rule file is loaded and compiled, which apparently is single-threaded and takes a couple seconds. Even on a reasonable powerful Rasperry Pi 4. This happens both after restarting openHAB and after changing the rules file. It also means that whatever the rule in question is supposed to do has to wait a couple seconds when requested for the first time. Imagine you have a light switch, enter a room, press the switch, and it takes 5-10 seconds until the light comes on.
To work around this problem, I add a piece of code in all rules files which triggers an immediate action right after loading the file. This way the rules file is already pre-loaded (which again takes a couple seconds, but likely at a time when the rule is not needed right now).
Continue reading "openHAB: faster loading of rules files"
One of the things I'm using Huginn for is monitoring for Twitter keywords. Some of them might appear in pairs, as example people like to tag Tweets about PostgreSQL with both #postgresql and #postgres. When I was using IFTTT this always created two emails, one for each hashtag. With Huginn I can deduplicate the events, and only notify about the first occurrence.
I need the following agents for this scenario:
Continue reading "Remove duplicates from Huginn event stream"
Huginn comes with a number of Twitter agents, but before they can be used you need to authenticate them. That process requires multiple steps, and they are not well documented.
The basics are described on the "Configuring OAuth applications" Wiki page.
For the Twitter integration one must know that you are using a single Twitter app for all users, but every Huginn user can (and should) have this app authenticated against their own Twitter account. Therefore if you want to use multiple Twitter accounts in Huginn, you need multiple Huginn users.
Continue reading "Enable Huginn Twitter integration"
Huginn is a great piece of software, but the documentation is ... a bit sparse. Especially when it comes to details of the agents. I'm going to blog about a couple more more examples in the future.
Continue reading "Monitor software version changes with Huginn"