Avoid message loops with FHEM2FHEM

Multiple instances of the open source server for house automation FHEM running on different machines can communicate using the FHEM2FHEM¹ module. Unfortunately one runs into big trouble when trying to use the module bidirectionally. FHEM2FHEM reads events from a remote FHEM instance. When using declarations like the following on both sides this results in an event loop because instance1 reads an event from instance2 and generates a new event on instance1. This event then gets read by instance2 again and so on…

define instance2 FHEM2FHEM instance2:7072 LOG:.*

fhem.cfg on instance1

define instance1 FHEM2FHEM instance1:7072 LOG:.*

fhem.cfg on instance2

Eventually this results in an event loop consuming all available CPU power and freezing FHEM.

One could simply prevent this situation by not forwarding all events by using a regular expression filtering the events instead of using LOG:.* . This also means one has to know which event gets received best by which instance. For example for simple radio temperature sensors this is hard to tell. Also one might want to have all sensor data available on all instances. This can be achieved by preventing FHEM from processing events, that got received from a remote instance a second time.

My modified version of 93_FHEM2FHEM.pm does exactly this, when a remote event gets read an additional flag (DISABLEEVENT) is being set. When the event afterwards gets processed a second time it gets discarded and the flag gets removed, so that usual message handling for the device can continue. This might not be the most sophisticated solution for the problem, but at least it prevents FHEM from freezing.

To prevent FHEM from freezing in the bidirectional setup, download the modified version of 93_FHEM2FHEM.pm (400 downloads) and replace the original file in the folder /opt/fhem/FHEM for both instances. Then edit the file fhem.cfg for both instances and add the attribute avoidMsgLoop to the FHEM2FHEM device, like in the following example. To get useful states for some devices, like CUL_TCM97001 sensors one still has to add the addStateEvent attribute.² Without this, for example plots would not work properly.

define instance1 FHEM2FHEM instance1:7072 LOG:.*
attr instance1 avoidMsgLoop 1
attr instance1 addStateEvent 1

With this modification it should be possible to set up a “cluster” of FHEM instances that can operate independent from each other but have the same data available. Thus the failure of one instance has less impact and the range of most radio devices can be extended transparently.

For completeness and in case someone wants to include this or an improved variant into FHEM the diff is available from here: 93_FHEM2FHEM-avoidMSgLoop.patch (305 downloads)


1. fhem.de
2. forum.fhem.de

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

glsldevil binaries

About one year ago I wrote about the OpenGL/GLSL debugger glsldevil in the article gentoo ebuild for glsldevil-1.1.5 and provided a gentoo ebuild for it. Unfortunately glsldevil seems not to be available anymore from the web page of the University of Stuttgart (http://cumbia.informatik.uni-stuttgart.de/glsldevil/), which has rendered the ebuild useless.

Edit 29/5/2012: The original download site of the University of Stuttgart is available again.

Since the license of glsldevil  permits redistribution, I decided to upload my local copy, to make glsldevil available for the public again. Unfortunately this only includes the Linux binaries (32bit and 64bit) and neither Windows binaries or the source code.

You can download the Linux binaries from here: [download#87]

For use with the ebuild, just copy the file to /usr/portage/distfiles/.



1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)

Pagerank 0 everywhere

Starting yesterday, the Google Pagerank of all sites is being displayed as 0 or n/a.  Pagerank is not that important for determining the quality of a site as it was once. It can still be a hint to see how good search engine optimizations (SEO) are for a site, or if the site needs improvements.

Many bloggers wondered what happened to their sites. Then there were the usual rumors, about Google disabling the Pagerank completely and Googles License for the Pagerank expiring.  The Pagerank algorithm weightens websites by importance. This is done by weighting inbound links to a site by the Pagerank of the referring site. So links from sites with a higher Pagerank are more valuable than links from sites with a lower one. The algorithm was developed by  the Google founders Brin and Page, but the patent for the algorithm was assigned to Stanford University. Google has got an exclusive license till 2011, afterwards the license becomes non-exclusive. Thus the expiring of this license has no impact on the availability of Pagerank at all, it only means, that others also could get a license for the algorithm and use it. The real cause for the Pagerank displays not working anymore is being discussed in [1]. It is quite simple: The Google API for inquiring the Pagerank has changed. For most scripts it is sufficient to replace the string toolbarqueries.google.com/search with toolbarqueries.google.com/tbr.

Some Firefox extensions, like SEOQuake, can be fixed by running the following command line in the extensions folder of the firefox profile:

grep -rl toolbarqueries.google.com/search . | xargs -t sed -i -e ‘s/toolbarqueries.google.com\/search/toolbarqueries.google.com\/tbr/’

After a firefox restart the Pagerank in i.e. SEOQuake is being displayed correctly again. For some other extensions there has to be done some more work and one has to wait for the next update to get this fixed. The pages providing online Pagerank information, like seitwert.de, can also be expected to get fixed soon. In the meanwhile one can use the Online Pagerank Checker of Jens Altmann to check the Pagerank.



[1] seomonitor.de

[2] wikipedia.org

[3] cickconf5.org

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Improved OpenSceneGraph-2.8.3 ebuild

The current OpenSceneGraph ebuild in the Gentoo Portage tree does not install the OpenSceneGraph sample data set.  These  files include some sample models, fonts, bitmaps etc. used in the OpenSceneGraph examples and other applications.  This is a problem for applications relying on the files to be available. In example my stereoscopic image viewer SIV relies on having the OpenSceneGraph sample dataset installed and fails to load the arial font from the dataset with the following error:

Warning: font file “fonts/arial.ttf” not found.

Here is my modified ebuild resolving this issue: [download#63]

Download the modified ebuild and extract the archive into /usr/local/portage. Be sure to include the following line in your /etc/make.conf:


If you want to use OpenSceneGraph with ffmpeg support, download the patch from bugs.gentoo.org and copy it to /etc/portage/patches/dev-games/openscenegraph-2.8.3/ as described there, to compile with ffmpeg-0.6. Otherwise the emerge will fail with:

error: cannot allocate an object of abstract type

Now you can set the examples USE-Flag and emerge openscenegraph to get the example dataset.

If you have got flightgear installed, reinstall simgear afterwards,  like the ebuild requests you to do:

emerge -1 dev-games/simgear

Depending on if you were upgrading or just reinstalling with the new ebuild it may be necessary to run revdep-rebuild to resolve issues with broken libraries. Hopefully the next ebuild in the portage tree will  include the sample data set.

Wxwidgets support seems to be broken with the current version. When using the wxwidgets USE-Flag Openscenegraph fails to compile with, so include

=dev-games/openscenegraph-3.0.1 -wxwidgets

in your /etc/portage/package.use if you have enabled wxwidgets in your make.conf.

best regards



1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)

VRTrack 1.0 – headtracking driver for the vr920 HMD

As I promised in New version of the vr920 headtracking driver coming soon here is the new version of my headtracking driver for the Vuzix VR920 iwear for Linux. It calculates yaw, pitch and roll from the accelerometer and magnetometer data (The device has got three of each). This makes a 3DOF tracking possible and allows you to look around in a 3D Scene.  In example you can use the driver with my stereoscopic image viewer SIV. The driver averages the sensor readings with an improved algorithm, which gives a far smoother experience than with the initial driver version. The driver package consists of a daemon which can be run in the background and for convenience a basic control application that enables one to easily tweak the various driver settings and to callibrate the device. For general Information on how to use the device with Linux see: Vuzix VR920 with Linux and active 3D stereo.

The driver provides the trackingdata in different formats to the application using it. It always writes the data to /dev/headtracking. A line read from /dev/vrtrack consists of six floats that correspond a sensor reading in this format:

yaw pitch roll x y z

Yaw, pitch and roll are angles from 0 to 360 degrees. X, y and z are always zero for the vr920, since it only supports three degrees of freedom. These values are reserved for future devices which may support six degrees of freedom, in the hope to propose a standard for tracking devices.

The driver can scale the readings and invert the axes independantly to get the needed value range for the used application and a pleasant experience.

For maximum compatibility with existing applications there are four other modes of operation available that can be enabled separately:

  • Joystick emulation
    The driver emulates a joystick device /dev/input/jsX. The readings for yaw, pitch and roll are the X,Y and Z axis of the emulated joystick. This may be used to enable basic headtracking support in games that do not natively support headtracking.
  • Mouse emulation
    The driver emulates a joystick device /dev/input/mouseX. The readings for yaw and pitch are being translated to X and Y of the mouse device, so when you look right the mouse pointer moves to the right and when you look up the pointer moves upwards and vice versa.  This may also be used to enable basic headtracking support in games that do not natively support headtracking. It can also be used to just control the mouse pointer of the window system. Controlling the viewport of the window system can also be a resonable purpose. With the new MPX extension in xorg this may be possible.
  • UDP – network
    In UDP mode the driver sends the tracking data via network as UDP unicast. The approach to send the data out via network makes the language used for writing the application independant from the language used for developing the driver. The packet sent to the clients contains the three angles, yaw, pitch and roll and x,y and z as 32 bit fixed point in Q16.16 format. This mode may i.e. used to control flightgear.
  • Multicast – network
    In multicast mode the driver sends the tracking data via network as UDP multicast, thus many clients may read the data, which makes parallelization more possible, i.e. one could use one machine for rendering and another machine for calculations. In addition to this, the approach to send the data out via network makes the language used for writing the application independant from the language used for developing the driver. The tracking data sent to the clients contains the three angles, yaw, pitch and roll and for easy usage a viewmatrix, one can directly use with scenegraph libraries. If you intend to develop an application using the headtracking of the VR920 see the file democlient.cpp included in the download for details on how to get the data into your application. This mode is used by the stereoscopic image viewer SIV.
Below is a screenshot of the control application during callibration of a vr920 device:


Important note: During calibration make sure that the display of the device is displaying something. Since the displays not only showing a blue screen influences the sensor data (at least with my device) you’ll end with wrong calibration else. You may use i.e. nvidia-settings to ensure this. For detailed usage instructions see the readme included in the download.


I decided to publish the driver under the creative common noncommercial license. You may download the full source from here: vr920-driver(source) (2083 downloads) , an x86_64 binary from here: vr920-driver(x86_64 binary) (1570 downloads) , or an i686 binary from here: vr920-driver(i686 binary) (1708 downloads) . An Archlinux PKGBUILD provided by Feilen is available here: aur.archlinux.org More binary/distribution specific formats may be available in the future. The x86_64 binary has been build on an up to date gentoo system, the i686 binary on ubuntu hardy. For the i686 binary you may install libconfig++ i.e. libconfig++8_1.3.2-2 from here: libconfig++ If none of the binaries works for you, you may have to build from source…

You need to have libusb, libconfig++, libfuse and libcurses installed on your system. For ubuntu users I included the small shell script ubuntu_install_deps.sh that installs the dependencies. Maybe it works also for for other Debian-based distributions. Gentoo users just have to make sure that  libusb, ncurses, fuse, and libconfig have been emerged. Your kernel version has to be at least 2.6.31 and you must have cuse enabled in your kernel.


If you like the driver, feel free to link to www.mygnu.de. If you developed an application using the tracking data provided by the driver please leave a comment, because then I can review the application and eventually write about it. To request commercial licenses contact us at info(at)mygnu.de. Well, if you just want to support our work on MyGNU.de use the donate button 😉

best regards


1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)

gentoo ebuild for glsldevil-1.1.5

Some days ago I wanted to get some information on how OpenSceneGraph internally performs the rendering, to prepare for my B.Sc. thesis. Especially I wanted to know if it really uses Vertex Buffer Objects when I “force” Graphics Nodes to do so. Code analysis would have taken to long and would not have been proof enough for me. Thus I needed an OpenGL debugger. A nice one I found is glsldevil, which was developed at the university of Stuttgart. It can not only debug pure OpenGL, but also GLSL shaders.

glsldevil screenshot


For gentoo I found an old ebuild somewhere in the web and modified it for the new version of glsldevil. Here is my overlay including the modified ebuild: [download#47]

Download the overlay and extract it in /usr/local/portage. Be sure to include the following line in your /etc/make.conf:


Then emerge glsldevil.



1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)

FlightGear with quad buffered stereo

With my upcoming new headtracking driver for the vusix vr920 hmd it is likely that I manage to get the famous flight simulator FlightGear to work with it. This led me again to the problem that FlightGear does not work in quad buffered stereo, as  I described in my comment to FlightGEAR 2.0.0 on GENTOO.

One expects to enable stereoscopic mode in FlightGear starting it with the following line:


When starting flightgear this way, one gets the following console output and no stereoscopic view:

Warning: detected OpenGL error ‘invalid operation’ after RenderBin::draw(,)

Getting FlightGear to work with quad-buffered stereo

Doing some code analysis in OpenSceneGraph-2.8.0 I discovered the following lines of code in View.cpp:

osg::DisplaySettings* ds = osg::DisplaySettings::instance();
if (ds->getStereo())
case(osg::DisplaySettings::QUAD_BUFFER): traits->quadBufferStereo = true; break;
case(osg::DisplaySettings::HORIZONTAL_INTERLACE): traits->stencil = 8; break;
default: break;

It seems that the stereo context in FlightGear does not get initialized properly in WindowBuilder::makeDefaultTraits(bool stencil). Thus these lines have to be added to WindowBuilder.cxx. For convenience here is the patch against  FlightGear-2.0.0: [download#43]

Perhaps some nice FlightGear developer can include this into upstream code. You have to use a professional graphics board that supports quad buffered stereo, like a NVIDIA Quadro FX or a Ati FireGL and proper display hardware, like shutter glasses, a HMD or a stereoscopic projection system, to benefit from it.

Problems remaining

When using the quad buffered stereo mode in flightgear there occur some graphics errors. These are not very annoying, but they are there. Some cockpit controls and other scene details contain yellow lines, like a wireframe,  which are not there when starting FlightGear in “normal” display mode. I suspect this to be another bug in FlightGear, which has still to be located. See the screenshots below for details. The problematic parts of the scenes are marked red. Especially the night pictures show the problem. This problem does not only exist in quad buffered stereo mode, but also in other stereo modes like HORIZONTAL_SPLIT.


FlightGear by day, quad-buffered stereo, with errors


FlightGgear by day, no stereo, without errors


FlightGear by night, quad-buffered stereo, with errors


FlightGear by night, no stereo, without errors

The Gentoo way

For gentoo users here is my overlay including the modified ebuild: [download#44] Download the modified overlay (including the patches) and extract it in /usr/local/portage. Be sure to include the following line in your /etc/make.conf:


Then emerge flightgear and enjoy it in three dimensions.

Have fun


Tool to increase your alexa rank instantly

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)