Guten Morgen allerseits,
nach dem letzten Upgrade auf meinem RPi bekomme ich sowohl beim Klicken im Webfront als auch beim Ausführen von Scripten die Meldung „Fehler - Verbindung zur Schnittstelle ist nicht geöffnet“.
In der Konsole allerdings ist diese Schnittstelle (ich gehe davon aus, dass der KNX-Gateway damit gemeint ist) geöffnet und im Debug sehe ich incoming und outgoing Messages.
Falls jemand eine Idee hat, was los ist: bitte immer her damit 
Gruss,
Jörg
Im Zweifelsfall mal dein KNX Gateway stromlos machen. Wie viele Kanäle hat dein Gateway? Vielleicht nur 1?
paresy
Guten Morgen paresy,
vielen Dank für die schnelle Antwort.
Das Gateway ist ein KNX-Router mit 5 Kanälen und hatte, wie gesagt, einwandfrei funktioniert. Da ich mich momentan in Portugal auf dem Sharkfest befinde und meine Frau nicht an den Schaltschrank lasse, hatte ihh auf eine fernwartungsfreundliche Lösung gehofft…
Das Problem taucht auch mit der 4.4 (Testing) auf.
Gruss aus der Konferenz,
Jörg
Magst du dann mal testen, was passiert, wenn du den I/O Deaktivierst und wieder aktivierst? Du kannst auch im Debug vom Splitter mal schauen - dort stehen Infos warum ggf. die Verbindung fehlgeschlagen ist.
paresy
Hi,
I/O deaktivieren/aktivieren hat keinen Erfolg gebracht. Sowohl vor dem Deaktivieren als auch nach dem Aktivieren wurde im Debugfenster Traffic angezeigt
Splitterdebug zeigte beim Klicken im Webfront sowohl vor dem Deaktivieren als auch nach dem Aktivieren das gleiche Verhalten:
Gruss,
Jörg
Das wirkt sehr danach, als wenn (warum auch immer) alle Kanäle am KNX Gateway belegt sind und unser Versuch zum Verbinden abgelehnt wird. Versuch es sonst nach ein paar Stunden noch mal.
paresy
Das Verhalten hatte ich bei mir und Schwiegereltern auch schon. Das kam meistens nach Neustarts des Dienstes oder Updates.
Durch ein reset des KNX Gateways funktionierte alles wieder.
Gruß,
Peter
Gesendet von iPhone mit Tapatalk
DANKE
Werde heute am Abend mal den LS ziehen lassen…
Danke!!
LS aus und LS an hat den Fehler behoben!!
Gruss aus Protugal,
J.
Einen schönen guten Abend,
so, seit dem letzten Ziehen der LS musste ich diese Prozedur dreimal wiederholen, da die Schnittstelle wieder nicht erreichbar war.
Dieses Verhalten trat nach dem Update auf die aktuelle 4.3 auf und ist auch mit der 4.4 vorhanden.
Ob ein kausaler Zusammenhang zwischen Update und Verhalten besteht, kann ich nicht beurteilen. Ein temporärer Zusammenhang ist allerdings zu bestätigen…
Gruss aus EU,
Jörg
Hallo Zusammen,
meine Schnittstelle hat sich schon wieder aufgehangen mit der Symptomatik „Verbindung zur Schnittstelle ist nicht geöffnet“.
Ich konnte in den Logfiles feststellen, dass Symcon heute allein viermal abgeschmiert ist (der Dienst wird bei Absturz/Aufhängen durch einen Watchdog neu gestartet(Restart=always)). Die Logfiles brechen an verschiedenen Stellen ab.
Anscheinend wird bei einem Neustart die Verbindung zum Schnittstelle nicht getrennt und eine weitere Session neu gestartet, bis diese dann „voll“ sind…
Gibt es eine Möglichkeit, trotz Restart=always ein sauberes Debugging zu bekommen?
Gruss,
Jörg
Ich wüsste gerade leider keine. Zum Tracken von abstürzen wäre dies hier sehr hilfreich: Debugging für Experten (Raspberry Pi, Linux) - Deine Schlussfolgerung, dass die Kanäle durch die Abstürze verbraucht werden, passt auf jeden Fall.
paresy
Guten Morgen paresy,
vielen Dank für die späte Antwort
Dann werde ich den Watchdog mal deaktivieren und das Debugging einschalten.
Gruss aus EU,
Jörg
Guten Morgen zusammen,
nachdem heute morgen die Rollladen nicht öffneten, war mir klar, dass Symcon wieder hängt.
Aber nun habe ich einen Backtrace, mit dem Paresy hoffentlich etwas mehr anfangen kann als ich…
(gdb) bt
#0 0x005ae570 in boost::asio::detail::epoll_reactor::start_op(int, int, boost::asio::detail::epoll_reactor::descriptor_state*&, boost::asio::detail::reactor_op*, bool, bool) ()
#1 0x005afa1c in boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::const_buffers_1, boost::asio::detail::transfer_all_t, boost::_bi::bind_t<void, boost::_mfi::mf2<void, IOClientSocket, std::shared_ptr<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, boost::system::error_code const&>, boost::_bi::list3<boost::_bi::value<IOClientSocket*>, boost::_bi::value<std::shared_ptr<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, boost::arg<1> (*)()> > >::operator()(boost::system::error_code const&, unsigned int, int) ()
#2 0x005ad980 in IOClientSocket::startWriting(std::shared_ptr<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >) ()
#3 0x005aecb8 in boost::asio::detail::completion_handler<boost::_bi::bind_t<void, boost::_mfi::mf1<void, IOClientSocket, std::shared_ptr<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, boost::_bi::list2<boost::_bi::value<IOClientSocket*>, boost::_bi::value<std::shared_ptr<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int) ()
#4 0x005a9668 in std::thread::_State_impl<std::_Bind_simple<IOClientSocket::Connect()::{lambda()#2} ()> >::_M_run() ()
#5 0x7674e9dc in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#6 0x76f95fc4 in start_thread (arg=0x5d9ff430) at pthread_create.c:335
Backtrace stopped: Cannot access memory at address 0x14fcb312
Falls Du/Ihr noch mehr Informationen benötigt, einfach fragen
Gruss aus EU,
Jörg
Kurze Frage noch: Der RPi läuft noch mit Jessie oder schon mit 4.4 und Stretch?
paresy
Sorry, mein Fehler:
Stretch und 4.4
Gruss aus EU,
Jörg
Gibt es schon erste Erkenntnisse??
Gruss aus EU,
Jörg
Noch nichts handfestes. Bin aber dran!
paresy
Danke sehr!
Magst du die aktuelle Beta der 4.4 mal testen? Ich habe dort mal die Bibliothek aktualisiert, die bei dir den Fehler zu verursachen scheint.
paresy