This is actually due to replacing the evdev driver with the libinput driver. See here for a fix: Raspberry Pi and a 3.5″ touchscreen updates part 1. Sudo apt upgrade (This may also take a while) Install xinput and the calibrator. Sudo apt install xinput xinput-calibrator. Now we need to edit some files. I use the nano editor.
Download Telldus Driverpack
It is rare but sometimes it happens – the telldus daemon responsible for communicating with the Telldus Duo hardware has disappeared from the processlist, crashed or exited silently. This is not acceptable on an embedded system where processes shall have 100% uptime. The preferred way is to have some sort of supervisor which is responsible for restarting the process if it disappears.
- Enlighter Retriever free download - CD Rx Data Retriever, Password Cracker, Enlighter, and many more programs.
- Telldus Adds support for Telldus Z-wave devices. The id of the drivers is the product number from The Z-wave Alliance. Supported devices. Z-wave Door/window sensor - Contact alarm (TZDW-100) Z-wave Plug-in switch - Plug-in Switch (Schuko - TZWP-100) Z-wave Plug-in switch - Plug-in Switch Mini (TZWP-102) Version log.
Who is the naturally supervisor? Well, the process that started the process to be supervised. In Linux the first process started is either the old init or the newer systemd, which then starts all the other processes according to runlevels and dependencies (systemd) or sequence number (init/rc). There are a number of possible solutions for supervising using either init or systemd. A quick check on ‘google’ gives a couple of solutions, others probably exists as well:
- daemontools – a supervisor which monitors processes, possible to use with init.
- monit – a supervisor which monitors processes but also have a wealth of other monitoring possibility. Seems more targeted to server systems than embedded.
- built in supervising in systemd – the systemd has a simple supervisor built in which restarts processes.
In systemd you don’t write a script, instead you define a service having different properties and dependencies. This service configuration is put into /etc/systemd/system/<name>.service. The syntax is the same as .INI files on windows. See Service Configuration for details.
Telldus daemon as a systemd service
| [Unit] |
| Description=Telldus daemon |
| [Service] |
| Type=forking |
| PIDFile=/var/run/telldusd.pid |
| ExecStart=/usr/sbin/telldusd |
| Restart=always |
| [Install] |
| WantedBy=multi-user.target |
Explanations:
The telldus daemon is a forking daemon, i.e. it is forked off the starting process to be able to be automatically attached to the process having pid 1 (systemd in this case) making it independant of the terminal (tty).
The PID number is saved into this file when fork has been made, making it possible to find out the id of the process.
Always restart regardless the case abort, exception, signal or exit via return code.
Websolution (cherrypy) as a systemd service
| [Unit] |
| Description=Cherrypie webserver for the telldus duo |
| After=network.target |
| [Service] |
| Type=simple |
| User=root |
| Environment='PYTHONPATH=/usr/local/bin/setup' |
| ExecStart=/usr/local/bin/cherrytelldus/startwebserver.py |
| Restart=always |
| [Install] |
| WantedBy=multi-user.target |
Explanations:
Dependant on network connection before starting up.
Ordinary process i.e. doesn’t return if started since it is listening on network connections
Start process as root, since the webserver will switch to telldus user as soon as possible.
Environment=”PYTHONPATH=/usr/local/bin/setup”
Sets and exports the env. variable PYTHONPATH to the started process.
Download Telldus Driver Download
To make the services start call:
Download Telldus Drivers
Both solutions were tried out by killing the processes abruptly using ‘kill -kill ‘ and verified that they were restarted.