Host your own doodles with jawanndenn

Thursday, March 14. 2019

For a website where event dates are offered to a group of users who need to find those dates that most users can attend, doodles are a good solution. There are well known providers for that sort of thing like, or, with the latter two offering better privacy for european users (no transfer of data to servers in the USA).

Still, hosting your very own service is an attractive alternative. For this there is  which can be downloaded from It is a web application written in python by Sebastian Pipping, libre software.

Installation is easy with

pip install jawanndenn

and then run it from the command line with something like

jawanndenn --host your-domain.tld --port 23456  (the port is arbitrary).
navigate your browser to
https://your-domain.tld:23456 and create your first own poll.

You see the log entries written out on the console. This is nice for testing but to actually use jawanndenn you'll need something more stable than a manually started programm.

As my web server runs with apache this is how I did it:

- set up a subdomain dedicated for the application, like doodle.your-domain.tld

- get certificates for it from Let's Encrypt (i.e. using )

- create a folder for document root of the new subdomain and put a file app.wsgi and a favicon.ico there, the former you'll find at , the latter can be done with touch as we won't see that icon anyways but it saves 404 log entries to have a file named like it.

- make sure that apache2 has mod_wsgi enabled

- set up a virtual host for it in apache2/sites-available. Example:

#  doodle.your-domain.tld

# subdomain dedicated for running the jawanndenn web application
# don't separate .conf and .common since this will lead to errors when both :80 and :443 try to set
# a WSGIDaemonProcess with the same name.
# Don't include processes=1 into the WSGIDaemonProcess definition for this will lead to errors "Single process needed"

<VirtualHost :80>
#       include sites-available/doodle.
your-domain.tld.common ## this won't do, see above
        ServerName doodle.

        WSGIDaemonProcess doodle user=web123 group=web123 threads=5
        WSGIScriptAlias / /var/www/web123/doodle/app.wsgi

    <Directory /var/www/web123/doodle>
        WSGIProcessGroup doodle
        WSGIApplicationGroup %{GLOBAL}
        Order deny,allow
        Allow from all

   CustomLog /var/log/apache2/doodle.
your-domain.tld.access.log combined
   ErrorLog  /var/log/apache2/doodle.your-domain.tld.error.log



ServerName doodle.your-domain.tld

    # supply a different name for the WSGIDaemonProcess on :443
    WSGIDaemonProcess doodler user=web123 group=web123 threads=5
    WSGIScriptAlias / /var/www/web123/doodle/app.wsgi

    <Directory /var/www/web123/doodle>
        WSGIProcessGroup doodler
        WSGIApplicationGroup %{GLOBAL}
        Order deny,allow
        Allow from all

   CustomLog /var/log/apache2/doodle.your-domain.tld.access.log combined
   ErrorLog  /var/log/apache2/doodle.your-domain.tld.error.log

        SSLEngine on

        SSLCertificateFile      /etc/dehydrated/certs/
        SSLCertificateKeyFile   /etc/dehydrated/certs/
        SSLCertificateChainFile /etc/dehydrated/certs/


Now restart apache2, weed out typos and your done. You create new doodles from doodle.your-domain.tld,
make note of the handle of the new poll and embed it on a web site with an iframe like

<div class="dudel">
<iframe src="https://doodle.your-domain.tld/poll/a9108dcfa12006ce3c229d6f0110c5f976df14e963ddd9b7ffc8618013a0bd7e"
        width="100%" height="600" frameborder="0"
        allowfullscreen >
  <p> <a href="">
    Fallback link for browsers that don't support iframes
  </a> </p>


I had no luck trying to use sandbox with the iframe, YMMV


Now, is that secure?

Do a little exploration with the 'View Web Source' feature of your browser to see all the relevant URIs and handles visible in plain text. Who ever gets to that page with the doodles can do shyte like

  • create 'unofficial' doddle polls
  • post spam as the name of a doodle
  • what the heck

Thus, we do have the security feature of 'data never leave my own site'. Which is cool.
All the rest of your desired security you will have to provide on your own.

Now, can I edit a vote? As it comes jawanndenn does not support any editing of votes which is regarded a security feature but makes doodles pretty useless in real life cause people do change opinion all the time. You cannot manually edit the stored votes cause they are stored in a binary format that's hard to access.

What you can do is add that functionality by yoursel like modify the vote() method of the _Poll object to replace the prior vote with the new vote if the name is exactly the same. 


rfid-tags for presence detection in smarthome

Wednesday, November 28. 2018

Pressence detection is vital in a smarthome setup, lights should go out when I leave and on when I come home.  But presence detection is not trivial, you can not rely on PIR motion sensors since they often do false positives. You can not rely on pinging the smartphone when it connects to the WLAN because phones have sleep modes to save energy and you'll find your phone regarded as absent when it sits next to you on your desk. Even owntracks and tasker provide solutions which work sometimes and fail later. .

And, more often then I like, I have to search for my keys before leaving the house. Now this is how I try to catch two flies with one stone:

I bought a RC522 rfid reader to integrate it into my smarthome IoT.
Most of the stuff you can find for those, both software and things, follows the idea of access control.
That is:

  • the thing with the reader waits in front of a door and controls a lock. User comes, holds a keycard at the reader, is denied or allowed, puts the keycard back in their pocket and enters...

My use case is different, more like what you may find in a hotel:

  • the thing with the reader waits behind the door and the user is supposed to insert the key card into the reader and leave it there. The reader identifies the key card and informs the smarthome controler that the owner of that key card is at home so it's time to turn on the lights and enable all the features that will be turned off again when the key card is taken out of the reader, later.

For this to work the key card (those blue drop shaped ones with a key chain ring you get with the reader) has to be in close range of the reader in a stable position, in other words, some sort of pocket is needed.


rfid-boxThe box is a remix of something I found searching thingiverse and sits at

It's printed in fast mode and with elements into all directions the slicer added lots of support which was hard to get off, you can see ht the box suffered from it.

Anyways, this cheap RC522 rfid reader which set me back by about 6€ sits in this box I printed, with a pocket to insert the chip and thus hold my keys at a defined place. The reader, connected to an Nodemcu V2 microcontroller identifies the chip, thus knows it's me who is at home and reports this to the smarthome controller. When I leave the house and take my keys the reader creates a new event and the system knows I'm out.

On the software side again there are plenty of example sketches for access control where the reader idles until you put a key card in its range, then the card is analysed, the result is given and the thing idles on. There is no event when the card is taken away.

So I had to write my own sketch for that, too. Again it is a remix.
It runs on an arduino clone and it creates an event when a known key card is entered, and another event when that card is taken out.

Since my smarthome is controlled by openHab2 which has a very usable rest api there is some code to report those events to it.
The sketch is part of the thingiverse file bundle linked above.

openHab2 startup chaos

Thursday, October 25. 2018

starting and stopping openhab2 is a messy affair, filling the logs with loads of Java's verbose exception messages and since the order of loaded models is basically random things may or may not work as intended when items have not been loaded or rules not executed that are assumed to be there.

As it was, manual corrections and reloads were needed after each restart.

There is an elegant workaround discussed at which uses systemd's ExecStartPre and ExecStartPost commands to deactivate all rules before starting openhab, and then reactivate them one by one when the system is up and has it's feet on the ground.

It did not work exactly like described there for me, but I still found a solution that has cleaned up the messy startup here.

A small bash script does the renaming. I put it in /etc/openhab2 next to openhab's configuration into a new folder /exec-scripts:

# clean up the start process 
#  starting rules in a sorted manner after openhab2 got it's feet on the ground
#  called from systemd pre start 
#  to rename *.rules away initially 
#  synopsis: org-extension new-extension (POST)
#  first call is from
#  /etc/systemd/system/openhab2.service.d/override.conf
#  called from the running openhab again to rename them back one by one
# $3 allows to distinguish between pre and post action 
# REF:


for f in /etc/openhab2/rules/*.${ORG};
    CURRENT=$(basename $f)
    if [ "$CURRENT" == "$IGNORE" ]    
        echo "ignoring $IGNORE"
        mv "$OLDFILE" "$NEWFILE"
    # let some time between each load
    if [ "$THX" == "POST" ]
        /bin/sleep $DUR

# some things left on startup
if [ "$THX" == "POST" ]
    /usr/bin/touch /etc/openhab2/things/tradfri.things

Since the openhab2.service file is part of the package and thus is replaced with each update modifying the .service file would need to be repeated whenever a new version gets installed, but, systemd provides a way to override a service definition. systemctl edit openhab2.service creates an override dir and opens the editor to allow creating a service file that is not replaced by the next update.

Now don't try to copy the entire .service file, systemd will complain duplicated statements. My override.conf looks like this:

ExecStartPre=/etc/openhab2/exec-scripts/ rules rules_

The third element is a .rules file in openhab2 that triggers the renaming of all the other .rules once the system is running. It is excepted from the renaming and I named it 005_start.rules. This works for me:

var rulesDelayed
var nada

rule "triggered by system start"
    System started
    var duration = 1
    rulesDelayed = createTimer(now.plusMinutes(duration), [|
					logInfo("rulesDelayed", "Timer expired and start")
					nada=executeCommandLine("/bin/bash /etc/openhab2/exec-scripts/ rules_ rules POST ",90000)
                    logInfo("rulesDelayed", "result: "+nada)
					rulesDelayed = null

    logInfo("rulesDelayed", "Timer set on "+duration+" min")

The bash script works the list of rules -files in an alphanumerical order so a naming scheme like praefixing all .rules with a three digit number finally allows to control the order of rules loading.

Startup is much faster now, less or no exceptions and a much cleaner log :-) Openhab is a Java application and those exceptions are super-ugly and come with a performance penalty.

You'll notice that the bash script supports an optional 3. parmeter to distinguish between pre- and post-action and that a certain config file is touched after the renaming. touch-ing triggers a reload of that config file and this was a workaround for a bug in the tradfri-addon, the bug may have been addressed by now.

TimeStamp in mosquitto.log

Monday, September 24. 2018

 mosquitto gibt jedem Log-Eintrag einen TimeStamp im für Maschinen recht praktischen Aekunden-seit-Epoche - Format. Für menschliche augen ist diese Angabe eher sperrig.

Mit perl und ccze (macht's bunt) kann man die Ausgabe etwas aufhübschen:

tail -n2000 -f  mosquitto/mosquitto.log |  perl -pe 's/(\d+)/localtime($1)/e'| ccze -m ansi


Presence Detection in WLAN

Sunday, September 9. 2018

 I was not content with the network/pingdevice based presence detection openhab2 offers. While it finds and detects smarphones connect to the wlan, it soon gets beaten by some energy-savong sleep modes, so the device does not ping. It may still respond to arping, though.

The following script is used on a linux router with several interfaces where a device miight be reachable. It can be configured from a settings.ini, reads it's sc an targets from a different ini file and reports it's findings via openHab's REST api.



baseUrl points to the REST api of the openHab2 server, interfaces is a comma separated list of the interface/s that should get scanned and interval gives the number of seconds the scanner will sleep between to scans





Each device has its own section with the section name acting as the unique id of the device, item is the openHab item (expected to be a Switch) that should get the result (ON or OFF) and MAC has the MAC or IP of the device 

The scanner is done in python (2.7)

#!/usr/bin/env python

import ConfigParser
import string
import os
import subprocess
import time
import sys


def get_script_path():
   return os.path.dirname(os.path.realpath(sys.argv[0]))
def LoadConfig(file, config={}):
   returns a dictionary with keys of the form
   <section>.<option> and the corresponding values
   config = config.copy(  )
   cp = ConfigParser.ConfigParser(  )
   for sec in cp.sections(  ):
       name = string.lower(sec)
       obj  = { }
       for opt in cp.options(sec):
           obj[string.lower(opt)] = string.strip(
               cp.get(sec, opt))
   return config

def ScanThings():
       for interface in interfaces:
           p = subprocess.Popen(["arp-scan","-l","-q","-r","3", "-I", interface], stdout=subprocess.PIPE)
           output, err = p.communicate()
           scantext += output
       for key in devices:
           if device["mac"].lower() in scantext.lower():
               print key+" ja"
               val = "ON"
               print key+" nein"
               device["tap"] = device.get("tap", 0) + 1
               if device["tap"] <= grace:
                   print key+" tap: "+str(device["tap"])
           if val != "na":         
               os.system('/usr/bin/curl --silent --header "Content-Type: text/plain" --request POST --data '+val+' '+url)

conf=LoadConfig(get_script_path()+"/"+"settings.ini", conf)


while 1:





The script is most useful when run as a daemon. You can easily do this with systemd which uses .service files found in /lib/systemd/system/


Description=Run arpscan device detection
ExecStart=/usr/bin/python /usr/local/bin/presence/

The scanner reads settings and scan data, runs an arpscan on each configured interface and finally searches the specified MAC (or IP, just one of the two is needed) in the result.
it needs the linux arp-scan package to be installed, which you can test and confirm by running

arp-scan -l -I eth0

from the commandline. It needs to be run as root.

Some devices may show up oscillating between on and off, to get more stable results the script waits for a number of fails before the "OFF" result is sent. This can be finetuned by the value for grace. 


(Page 1 of 36, totaling 176 entries) » next page