MAX: Homegear empfängt nichts mehr

Deutsche Foren Fehler
#1

Hi,

bevor ich meine Max Geräte in die Tonne werfe, dachte ich, ich versuche es nochmal mit homegear. Doch leider auch sporadisch Probleme :frowning:

sporadisch empfängt homegear nichts mehr von den MAX Geräten. (Fenstersensor blinkt 3x)
Im Moment habe ich ein Thermostat basic, Wandthermostat und Fenstersensor angebunden.
Erst wenn ich wieder was sende (SET_TEMPERATURE z.B.) kommt wieder was an und es läuft weiter als wenn nix wäre ohne neustart.

Homegear Version auf dem Raspi: 0.7.40-2948

CUL Modul: von cod.m

Vielleicht könnte es mit den Fehler hier zusammenhängen? Von der Zeit her müsste es passen.

08/15/19 18:50:26.404 Module MAX: TI CC110X “My-MAX-CC1101”: Warning: Too large packet received: 8A8A044216C5510000000028E40189D0635699C287FFFE02263A7F803E0EB0E5DCC676C48D3F0E42B405B311A445F8747D9334E9E8A7B0A057E8C12931FEA8CEC98A044216C5510000000028E40189D0635699C287FFFE02263A7F803E0EB0E5DCC676C48D3F0E42B405B311A445F8747D9334E9E8A7B0A057E8C12931FEA8CECEC98A044216C55100000000
08/21/19 09:44:34.244 Module MAX: TI CC110X “My-MAX-CC1101”: Warning: Too large packet received: 856904021353D800FA040018EF1E8587D34B2E6591E6443B9C9F0759690F30B2FDA368503284A096F092F8A963B04C8E62E3BA10132E5B8858C501E7E2975B9A126904021353D800FA040018EF1E8587D34B2E6591E6443B9C9F0759690F30B2FDA368503284A096F092F8A963B04C8E62E3BA10132E5B8858C501E7E2975B9A9A126904021353
08/22/19 14:51:15.647 Module MAX: TI CC110X “My-MAX-CC1101”: Warning: Too large packet received: 89F7044216C5510000000028E41E88B3B1DD318F0AF565E2A520D9F59CE8FDA5CD30CCA19BA4F990DC1F8FFFD5B32C785029EC2BCB021A33C46038DABDDB3C4DE4F7044216C5510000000028E41E88B3B1DD318F0AF565E2A520D9F59CE8FDA5CD30CCA19BA4F990DC1F8FFFD5B32C785029EC2BCB021A33C46038DABDDB3C4D4DE4F7044216C551000000
08/22/19 17:45:55.452 Module MAX: TI CC110X “My-MAX-CC1101”: Warning: Too large packet received: 8C34044216C5510000000028E41C88C295C94AB18AD2A115E8A5A8FFC571F08BE37B29804D000C1100AB34382AB9E7D015919F8D06494253C572BD54908A21544E34044216C5510000000028E41C88C295C94AB18AD2A115E8A5A8FFC571F08BE37B29804D000C1100AB34382AB9E7D015919F8D06494253C572BD54908A2154544E34044216C5510000000028E4

Gruß

#2

Hallo @Monteaup,

ich habe mal eine kleine Quelltextanpassung gemacht. Schau mal, ob das Problem mit dem nächsten Nightly noch auftritt.

Viele Grüße

Sathya

Max! Duty Cycle schnell voll, Homegear sendet dauernd an die Geräte?!
#3

Danke schon mal! Werde ich testen sobald ich wieder in DE bin.

Gruß,
Martin.

#4

Find keinen aktuellen build für raspbian_stratch, nur noch buster.

Gruß

#5

https://homegear.eu/downloads.html?version=0.7-testing&system=raspbian_stretch

#6

Der letzte ist vom 10ten September. Das ist vermutlich zu alt.

#7

Ok. Dann muss @sathya was dazu sagen.

#8

Genau, das Testing ist noch zu alt. Aktuelles Nightly ist aber online und sollte funktionieren. Ich werde die Tage ein neues Testing bauen.

#9

Obwohl ich nichts geändert habe, kann die Meldung nie wieder in den logs vor.

Problem habe ich aber trotzdem noch. Das Wandthermostat meldet Verbindungsfehler. Und wenn ich versuche aus der Kommandozeile ein Wert zu setzen, beendet sich der homegear Prozess nicht mehr.

Vorgestern die nightly build installer. Keine Änderung. Heute morgen ging homegear wieder.

Beim nächsten lasse ich Mal strace auf den hängenden Prozess laufen.

#10

Beim nächsten lasse ich Mal strace auf den hängenden Prozess laufen.

Bzw. gdb anhängen:

apt install gdb libc6-dbg libstdc++6-<xx>-dbg
gdb homegear <Prozess-ID>
thread apply all bt
#11

Mit ist noch was aufgefallen. Seid dem die Nightly am laufen habe, hatte ich ständig Verbindungsprobleme (Wifi). Habe es zuerst aufs schlechtes Wlan geschoben. Dann ist mir aufgefallen, dass Samba problemlos ging, Mosquitte mit Verbindungsproblemen und Octoprint (3d Drucker Webinterface Port 5000) auch massive Probleme. Homegear war öfter hängengebliebene.

Jetzt habe ich Octoprint deaktiviert und seid 4 Tagen erstmal keine Probleme mehr. Da scheint sich jemand nicht zu mögen.

#12

Ohne Octoprint lief es jetzt lange durch. Nach einem Neustart hing es aber dann wieder.

GDB:

Thread 28 (Thread 0x62dff350 (LWP 2386)):
#0  0x76f34d3c in __pthread_cond_timedwait (cond=0x663007b0, mutex=0x66300798, 
    abstime=0x62dfd280) at pthread_cond_timedwait.c:200
#1  0x00440618 in __gthread_cond_timedwait (__abs_timeout=0x62dfd278, 
    __mutex=<optimized out>, __cond=<optimized out>)
    at /usr/include/arm-linux-gnueabihf/c++/6/bits/gthr-default.h:871
#2  std::condition_variable::__wait_until_impl<std::chrono::duration<long long, std::ratio<1ll, 1000000000ll> > > (__atime=..., __lock=..., 
    this=<optimized out>) at /usr/include/c++/6/condition_variable:166
#3  std::condition_variable::wait_until<std::chrono::duration<long long, std::ratio<1ll, 1000000000ll> > > (__atime=..., __lock=..., this=<optimized out>)
    at /usr/include/c++/6/condition_variable:106
#4  std::condition_variable::wait_until<std::chrono::_V2::system_clock, std::chrono::duration<long long int, std::ratio<1ll, 1000000000ll> >, Homegear::ScriptEngine::ScriptEngineClient::sendRequest(int32_t, uint64_t, std::__cxx11::string&, std::__cxx11::string&, std::__cxx11::string, BaseLib::PArray&, bool)::<lambda()> > (__p=..., __atime=..., __lock=..., this=<optimized out>)
    at /usr/include/c++/6/condition_variable:129
#5  std::condition_variable::wait_for<long long int, std::ratio<1ll, 1000ll>, Homegear::ScriptEngine::ScriptEngineClient::sendRequest(int32_t, uint64_t, std::__cxx11::string&, std::__cxx11::string&, std::__cxx11::string, BaseLib::PArray&, bool)::<lambda()> > (__p=..., __rtime=..., __lock=..., this=<optimized out>)
    at /usr/include/c++/6/condition_variable:145
#6  Homegear::ScriptEngine::ScriptEngineClient::sendRequest (
    this=this@entry=0x7e866688, scriptId=<optimized out>, scriptId@entry=6, 
    peerId=<optimized out>, peerId@entry=7124646953552277316, user=..., 
    language=..., methodName=..., parameters=..., wait=<optimized out>, 
    wait@entry=true) at ScriptEngine/ScriptEngineClient.cpp:697
#7  0x004437c8 in Homegear::ScriptEngine::ScriptEngineClient::callMethod (
    this=this@entry=0x7e866688, 
    methodName="\374F\340v\000\000\000\000\000\001\000\000\fX8f", '\000' <repeats 12 times>, "q\000\000\000@\000\060f", '\000' <repeats 24 times>, "|X8fXX8f\264---Type

STRACE:

 hängt hier in eine Endlosschleife und wartet auf etwas...
_newselect(5, [4], NULL, NULL, {tv_sec=0, tv_usec=100000}) = 0 (Timeout)��

Nach einen systemctl restart läuft alles wieder sauber.

Gruß

#13

Du möchtest die Formatierungsfunktionen des Forums nutzen…

grafik

#14

Hallo @Monteaup,

methodName="\374F\340v\000\000\000\000\000\001\000\000\fX8f"

das ist zum Beispiel Müll. Allerdings hast du gdb nicht an den Homegearhauptprozess sondern an einen Skriptengineclientprozess gehängt. Ein Threaddump vom Hauptprozess und das dazugehörige Log wären aufschlussreicher…

Auseinanderhalten kannst du die Prozesse mit ps -ejH -1.

Viele Grüße

Sathya