Openhab 3: Homematic Binding online aber es werden keine Homematic Devices gefunden

Deutsche Foren openHAB
#21

Der Neustart passiert bei mir auch.

Die nutze ich auch. Ich habe es aber auf der neuen openhab Instanz mal ohne probiert. Gleicher Effekt.

Genau wie bei mir.

#22

Der Neustart klingt verdächtig. Häng da am besten mal einen Debugger dran, ich rechne fest damit, dass es der beim reproduzieren des Problems ein Signal bekommen wird (vermutlich segmentation fault) und dann kann man mal schauen wo bzw. wieso.

Ich werde mal schauen ob der bei mir auch passiert, glaube aber nicht.

#23

Mit der aktuellen openHAB Version kann ich den Neustart von homegear 100% reproduzieren. Ich muss nur nach Homematic-Geräten scannen lassen, dann startet homegear sang- und klanglos neu.

Zusätzlich sind alle meine über Text konfigurierten Geräte “not found on gateway”

Nachdem ich jetzt auch wieder rausgefunden habe, wie man den Debug-Level in openhab erhöht, kann ich sehen, dass die ganzen Gerätevariablen und Systemvariablen übertragen werden. Wahrscheinlich kommen die nur mangels Geräten nicht an. :frowning:

Nachtrag: auch die Systemvariablen kommen nicht in den Items an. :frowning:
Nachtrag 2: Was auch logisch ist, da die ja am Gateway-Extras-Gerät hängen, wenn ich mich recht erinnere.

Nachtrag 3: So mit folgendem Kommando kann ich Homegear reproduzierbar zum Absturz/Neustart bringen:

sudo homegear -e rc 'print_r($hg->listDevices())'

Wäre echt toll, wenn @sathya da mal schauen könnte.

Habe auch mal ein Issue auf github erstellt, da scheint @sathya ja ab und zu noch reinzuschauen.

@flole, könntest Du mal prüfen, was bei dir mit dem Kommando passiert?

1 Like
#24

Nach meinen gestrigen Erkenntnissen vermute ich, dass Du die gleichen Probleme haben wirst, wenn openHAB seine Devices neu aufbauen muss. Das things-File ist ja nur eine Art Import für die interne Struktur. Das würde auch erklären, warum ich anfangs das Problem nicht gesehen habe.

#25

Hallo,

ich habe jetz bei mir auch mal ausprobiert

sudo homegear -e rc 'print_r($hg->listDevices())'

und von Homegear wurde ein coredump geschrieben.

gdb angewendet auf den coredump ergibt bei “where” folgende Ausgabe:

Core was generated by `/usr/bin/homegear -u homegear -g homegear -p /var/run/homegear/homegear.pid'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  BaseLib::Systems::Peer::getDeviceDescription (this=this@entry=0x37453d0, clientInfo=..., channel=channel@entry=-1, fields=...)
    at /usr/include/c++/8/bits/basic_string.h:1031
1031          empty() const _GLIBCXX_NOEXCEPT
[Current thread is 1 (Thread 0x72dc7b80 (LWP 5257))]
(gdb)
(gdb) where
#0  BaseLib::Systems::Peer::getDeviceDescription (this=this@entry=0x37453d0,
    clientInfo=std::shared_ptr<BaseLib::RpcClientInfo> (use count 1, weak count 0) = {...}, channel=channel@entry=-1,
    fields=std::map with 0 elements) at /usr/include/c++/8/bits/basic_string.h:1031
#1  0x7323ecdc in BidCoS::BidCoSPeer::getDeviceDescription (this=0x37453d0, clientInfo=..., channel=-1, fields=std::map with 0 elements)
    at /usr/include/c++/8/bits/stl_tree.h:129
#2  0x76d14f84 in BaseLib::Systems::Peer::getDeviceDescriptions (this=0x37453d0, clientInfo=
    std::shared_ptr<BaseLib::RpcClientInfo> (use count 7, weak count 0) = {...}, channels=<optimized out>, fields=std::map with 0 elements)
    at /usr/include/c++/8/bits/stl_tree.h:728
#3  0x76cafb4c in BaseLib::Systems::ICentral::listDevices (this=0x72dc7260,
    clientInfo=std::shared_ptr<BaseLib::RpcClientInfo> (use count 7, weak count 0) = {...}, channels=<optimized out>,
    fields=std::map with 0 elements,
    knownDevices=std::shared_ptr<std::set<unsigned long long, std::less<unsigned long long>, std::allocator<unsigned long long> >> (empty) = {...},
    checkAcls=false) at /usr/include/c++/8/bits/stl_tree.h:728
#4  0x76caf754 in BaseLib::Systems::ICentral::listDevices (this=0x286dc00, clientInfo=..., channels=<optimized out>,
    fields=std::map with 0 elements, checkAcls=false) at /usr/include/c++/8/bits/shared_ptr_base.h:614
#5  0x003d95ec in Homegear::Rpc::RPCListDevices::invoke (this=<optimized out>,
    clientInfo=std::shared_ptr<BaseLib::RpcClientInfo> (use count 7, weak count 0) = {...}, parameters=...) at /usr/include/c++/8/bits/stl_tree.h:728
#6  0x004b8d3c in Homegear::ScriptEngine::ScriptEngineServer::processQueueEntry (this=<optimized out>, index=<optimized out>, entry=...)
    at /usr/include/c++/8/ext/atomicity.h:96
#7  0x76b035d4 in BaseLib::IQueue::process (this=0x27dd5e0, index=0) at IQueue.cpp:339
#8  0x75a0e9b0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#9  0x76ee7494 in start_thread (arg=0x72dc7b80) at pthread_create.c:486
#10 0x7584bdd8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Leider reichen meine Programmierkenntnisse nicht aus, um die gdb Ausgabe zu interpretieren aber vielleicht ist das ja trotzdem hilfreich.

Gebt mir bitte einfach kurz Bescheid, wenn ich noch mehr Details liefern soll.

Viele Grüße

FiveEights

1 Like
#26

Vielen Dank! Ich habe mal kurz durchgeschaut, bin aber auch nicht fit in C++.

Der Absturz kommt in der Methode getDeviceDescription im Peer-Objekt. Ich vermute, ein String Pointer ist null.
Die Ursache ist wohl vorher zu suchen.
In der Methode RPCListDevices gibt es keine Behandlung für den Aufruf ohne Parameter, erst ab zwei Parametern wird das “fields”-Array bearbeitet, das in die tieferen Funktionen reingereicht wird.

Das deckt sich mit meinem Ergebnis, dass die RPC-Methode listDevices bei weniger als 2 Parametern Homegear zum Absturz bringt:

homegear -e rc 'print_r($hg->listDevices());' => Absturz/Neustart
homegear -e rc 'print_r($hg->listDevices(true));' => Absturz/Neustart
homegear -e rc 'print_r($hg->listDevices(false));' => Absturz/Neustart

homegear -e rc 'print_r($hg->listDevices(true,ARRAY("ID", "NAME")));' => funktioniert
homegear -e rc 'print_r($hg->listDevices(false,ARRAY("ID", "NAME")));' => funktioniert

Mit “funktioniert”, meine ich dass mir die gewünschten Geräte auf dem Bildschirm ausgegeben werden.
Daher gehe ich davon aus, dass getDeviceDescription grundsätzlich funktioniert und nur die Parameter den Absturz herbeiführen.

#27

Gute Nachrichten.

@sathya hat das Problem gelöst, die -3627 stürzt nicht mehr ab. OpenHAB kann auch wieder mit homegear sprechen, die Geräte kommen an.

Vielen Dank @Flole und @FiveEights!

Mit openHAB 2.5 hatte ich dann ein massives “Channel not found for datapoint”-Problem. Das war früher nur sporadisch.
Durch den Umzug auf openHAB 3.4.1 hat sich das aber behoben.

#28

Da habe ich vor einiger Zeit in openHAB ein automatisches neuladen wenn die Kanäle nicht geladen wurden eingebaut. Das ist zwar nicht schön, funktioniert aber offenbar sehr häufig :smiley: