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 (2887 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 (2888 downloads )

Update (08/11/2021): This approach is outdated. Better use the new loopThreshold³ parameter from now on.

Jürgen

References:
1. fhem.de
2. forum.fhem.de
3. forum.fhem.de

(No Ratings Yet)

Loading...

Posted in house automation, linux, networking, programming | No Comments »