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

Deutsche Foren openHAB
#9

Ich habe mir die Geschichte nochmal angeschaut und kann jetzt bestätigen, dass die Kommunikation zwischen openHAB (2.5) und homegear mit 0.9.22111910-3605 nicht mehr funktioniert.

Ich vermute, dass ich bei den letzten Tests einfach falsch geschaut habe, und auf Items geachtet habe, die über mqtt nach openHAB kommen.

Da hier mehrfach die RPC Server angesprochen wurden habe ich die default-Konfiguration genommen, und auf meine IPs angepasst. Das hat leider keine Abhilfe gebracht, Kommunikation läuft weiterhin nicht.

Es ist bei mir übrigens der Effekt, dass die Bridge online ist, aber die devices nicht übertragen werden.
Es kommt im Log von openHAB die Meldung

Device with address 'NEQXXXXXXX' not found on gateway 'homegear'

Ich benutze Things und Items Files, daher weiss das System wonach es suchen soll, findet es aber nicht.

Vielleicht kann @sathya die letzen Änderungen an der Schnittstelle reviewen?
Meine Installation von openHAB2 ist über 2 Jahre alt, daher ist es unwahrscheinlich, dass der Fehler dort zu suchen ist.

#10

Hallo,

ich würde gerne in diesem Zusammenhang auch nochmal auf meinen Thread Zugriff auf RPC Server triggert Homegear-Neustart verweisen.

Mittlerweile deutet Vieles auf ein Issue mit dem RPC Server hin.

Ich habe das mittlerweile auf eine komplett frischen Homegear-Installation des Nightlies auf einem alten Laptop unter Ubuntu nochmal probiert und es zeigt sich das gleiche Verhalten.

Viele Grüße

FiveEights

#11

Kannst du deine Testinstanz mal mit einer stable-Version prüfen? Das macht die Eingrenzung des Problems einfacher.

Ich trau mich irgendwie nicht, auf eine 0.8er zurück zu gehen, dafür funktioniert bei mir noch zuviel …

#12

Hallo,

gute Idee, leider kann ich keine Stable oder Testing Homegear Version installieren.
Bei mir läuft Ubuntu 22.04 LTS “Jammy Jellyfish” und es werden keine Homegear-Packages im Repository gefunden.

/etc/apt/sources.list.d/homegear.list ist angepasst, wie auf der Homegear-Download Seite beschrieben.

Weder im dem Shell-Skript von der Download Seite noch mit dem Paketinstaller von Ubuntu werden die Homegear Packages für meine Ubuntu-Version gefunden. Es funktioniert nur die Installation des Nightly.

Wenn mir hier jemand einen Tipp geben kann, dann teste ich gerne eine frühere Version.

Viele Grüße

FiveEights

#13

Kann man nicht beim Installer auswählen, welche Version installiert werden soll? Ich meine, da etwas gesehen zu haben. Oder ist das nur auf Raspbian so?

#14

Hallo,

ja richtig, man kann im Installer Skript auswählen, welche Version installiert werden soll.

Von Stable, Testing und Nightly funktioniert aber leider nur Nightly. Bei den anderen Versionen bricht der Installer ab, weil die Pakete nicht geladen werden können.

VG

FiveEights

#15

Also ich nutze

# homegear -v
Homegear version 0.9.22122507-3614
Copyright (c) 2013-2020 Homegear GmbH

Required library versions:
  - libhomegear-base: 0.9.22122507-3614
  - libhomegear-node: 0.1.8-61
  - libhomegear-ipc:  0.1.2-46

Included open source software:
  - Node.js (license: MIT License, homepage: nodejs.org)
  - PHP (license: PHP License, homepage: www.php.net):
      This product includes PHP software, freely available from <http://www.php.net/software/>
      Copyright (c) 1999-2020 The PHP Group. All rights reserved.

und habe keine Probleme mit dem neueste openHAB release.

P.S.: Irgendwer sollte mal das Copyright-Jahr anpassen, am besten schon auf 2023 :wink:

#16

Du hast es gut, @Flole.
Ich habe auf deinen Hinweis mal auf die aktuelle openHAB und Homegear Version upgedated und der Effekt ist der gleiche wie bei openhab2.

:/home/pi# homegear -v
Homegear version 0.9.23012700-3625
Copyright (c) 2013-2020 Homegear GmbH

Required library versions:
  - libhomegear-base: 0.9.23012700-3625
  - libhomegear-node: 0.1.8-61
  - libhomegear-ipc:  0.1.2-46

Included open source software:
  - Node.js (license: MIT License, homepage: nodejs.org)
  - PHP (license: PHP License, homepage: www.php.net):
      This product includes PHP software, freely available from <http://www.php.net/software/>
      Copyright (c) 1999-2020 The PHP Group. All rights reserved.

Die Bridge wird gefunden, aber kein einziges Gerät funktioniert oder wird erkannt. :frowning:
Dann wechselt die Bridge immer zyklisch den Status:

changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Connection lost
changed from OFFLINE (COMMUNICATION_ERROR): Connection lost to ONLINE

Das muss irgendwas mit dem rpc Server zu tun haben. Kannst Du mal deine diesbezügliche Konfiguration zeigen (/etc/homegear/rpcservers.conf und evt. auch rpcclients.conf )?

Danke!

#17

Die Konfiguration ist bei mir tatsächlich noch “alt” und gefühlt ewig nicht angefasst worden, könnte also die Ursache sein.

[RPCServer1]
# Interface to bind the RPC server to. By default IPv4 and IPv6 are
# enabled. If you want to only use IPv4 set "interface" to "0.0.0.0".
# Default: interface = ::
interface = 0.0.0.0
# The port number to bind the RPC server to. This setting is mandatory.
port = 2001
# Enable Homegear's XML-RPC and binary RPC server on this port.
# Default: true
xmlrpcServer = true
# Enable Homegear's JSON-RPC server on this port.
# Default: true
jsonrpcServer = true
# Enable Homegear's build-in web server on this port
# Default: false
webServer = true
# Enable Homegear's REST server on this port
# Default: false
restServer = true
# Path to static web content used by the web server
# Default: /var/lib/homegear/www
contentPath = /var/lib/homegear/www/rpc
# Default: contentPathPermissions = 550
# contentPathPermissions = 550
# Default: contentPathUser =
# contentPathUser = homegear
# Default: contentPathGroup =
# contentPathGroup = homegear
# Enable Homegear's build-in WebSocket server on this port
# WARNING: Enabling Websockets without authentication is a high security risk!
# So make sure, webSocketAuthType is not set to none!
# Default: false
webSocket = true
# Set ssl to "true" to enable SSL support
ssl = false
# You can specify the authentication type your server uses here.
# Can be one of the following:
# - none: No authentication is required
# - basic: Use basic authentication
# - cert: Use certificate authentication (only works when "ssl" is "true")
# Default: authType = cert
authType = none
# You can specify the websocket authentication type here. Never ever use basic auth
# over an unencrypted connection!
# Can be one of the following: none, basic, session
# "session" checks for the PHP session variable "authorized", which must be set
to
# "true" for the authentication to succeed.
# Default: webSocketAuthType = session
webSocketAuthType = session

In den rpcclients habe ich nichts eingestellt.

#18

Danke!
Leider hat es nichts gebracht. Meine rpcservers.conf sieht fast genauso aus, nur dass ich ein festes Interface benutze. :frowning:

Ich benutze node-blue, homegear-admin, homegear-ui und homegear-gateway.

Mir scheint es so als wenn die Kommunikation aller Services über Port 2001 läuft. Welche Teile von homegear benutzt du?

#19

Stell mal das debug level von dem openHAB Binding auf DEBUG und schau mal was dann im Log steht.

Ich nutze in openHAB übrigens die textbasierte Konfiguration, eventuell ist nur die funktionsfähig?

#20

Hallo,

ich bin echt erleichtert, dass sich hier im Forum mal wieder etwas tut. Ist leider echt ruhig geworden hier…

Ich habe genau die gleichen Symptome auch mit Home Assistant beobachtet und deswegen vermute ich, dass es am Homegear RPC Server liegt. Bei mir läuft das aktuelle Homegear Nightly 0.9 unter Raspbian Stretch.

Könnt Ihr bitte mal in meinen Thread Zugriff auf RPC Server triggert Homegear-Neustart schauen und checken, ob der Homegear Neustart bei Euch auch auftritt ?
Anscheinend reicht schon dieser recht einfach Zugriff auf den RPC Server um das Issue auszulösen und es gibt mittlerweile einige Threads, wo Leute über RPC Probleme klagen.

Meine Homegear Installation läuft seit Jahren problemlos, deswegen halte ich meine Konfiguration für zuverlässig und eigentlich habe ich an der rpcservers.conf kaum etwas geändert.

Vielen Dank für Eure Unterstützung!

FiveEights

#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: