Mal wieder : eBus

[guinnes]

Hallo
Ich habe gewaltige Probleme mit meinem eBus
Es gibt für Openhab 2.5.xx ein relativ neues Binding ( 2.50.11 ), das ist installiert. Nun kommt es vor, daß die Verbindung einfach stehen bleibt. Im Log steht dann :

Code: Alles auswählen

2021-06-27 13:21:30.492 [ERROR] [dev.ebus.core.EBusLowLevelController] - An IO exception has occured! Try to reconnect eBUS connector ...
java.net.SocketException: Connection reset
	at java.net.SocketInputStream.read(SocketInputStream.java:210) ~[?:1.8.0_252]
	at java.net.SocketInputStream.read(SocketInputStream.java:141) ~[?:1.8.0_252]
	at java.net.SocketInputStream.read(SocketInputStream.java:127) ~[?:1.8.0_252]
	at de.csdev.ebus.core.connection.AbstractEBusConnection.readBytes(AbstractEBusConnection.java:56) ~[bundleFile:?]
	at de.csdev.ebus.core.EBusLowLevelController.run(EBusLowLevelController.java:200) [bundleFile:?]
2021-06-27 13:21:30.498 [WARN ] [dev.ebus.core.EBusLowLevelController] - Retry to connect to eBUS adapter in 5 seconds ...

Das Reconnect funktioniert manchmal nicht. Um das Binding neu zu starten, habe ich folgende Rule geschrieben :

Code: Alles auswählen

rule "eBus Restart Binding"
when
  Item eBusZyklusError received command // Ist ein Schalter, der über einen Timer eingeschaltet wird, wenn mehr als 5 Minuten kein Update vom Binding gekommen ist
then
  if(receivedCommand == ON) {
    var String Restart = executeCommandLine("sudo /usr/bin/ssh -p 8101 -i /home/openhab/openhab.id_rsa openhab@localhost bundle:stop org.openhab.binding.ebus", 10000)
    Thread::sleep(25000)    
    logInfo("eBus", "eBus Stop {}",Restart)
    Restart = executeCommandLine("sudo /usr/bin/ssh -p 8101 -i /home/openhab/openhab.id_rsa openhab@localhost bundle:restart org.openhab.binding.ebus", 10000)
    Thread::sleep(2500)    
    logInfo("eBus", "eBus Restart {}",Restart)
  }
end

Prinzipiell funktioniert die Rule, wie mann am Log sehen kann :

Code: Alles auswählen

2021-06-27 13:24:06.904 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 27 00 1A
2021-06-27 13:24:06.906 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 42 00 EC
2021-06-27 13:24:06.908 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 00 00 89
2021-06-27 13:24:06.910 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 31 00 44
2021-06-27 13:24:06.912 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 30 00 DF
2021-06-27 13:24:06.914 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 01 00 12
2021-06-27 13:24:06.915 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 5D 00 30
2021-06-27 13:24:06.917 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 44 00 80
2021-06-27 13:24:06.919 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Remove polling job for FF 15 B5 09 03 0D 2F 00 03
2021-06-27 13:24:32.082 [INFO ] [.eclipse.smarthome.model.script.eBus] - eBus Stop 

Code: Alles auswählen

2021-06-27 13:24:33.139 [INFO ] [internal.things.EBusTypeProviderImpl] - Load custom 'bundleUrl' configuration bundle 'file:///etc/openhab2/ebus/configuration-bundle.json' ...
2021-06-27 13:24:33.248 [WARN ] [internal.things.EBusTypeProviderImpl] - eBUS command boiler.control.setopdata only contains a setter channel!
2021-06-27 13:24:33.335 [WARN ] [internal.things.EBusTypeProviderImpl] - eBUS command boiler.control.setopdata only contains a setter channel!
2021-06-27 13:24:33.359 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - Use eBUS binding 2.50.11 [eBUS core: 1.1.5, eBUS configuration: 1.1.4]
2021-06-27 13:24:33.365 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS core -> timestamp 202101311144, commit: #79c19b7, build-no: #null
2021-06-27 13:24:33.368 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS configuration -> timestamp 202012271447, commit: #101042c, build-no: #null
2021-06-27 13:24:33.476 [WARN ] [s.internal.handler.EBusBridgeHandler] - Enable advanced logging for eBUS commands!
2021-06-27 13:24:33.521 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "heating.program_heating_circuit_special" every 60 sec. (initial delay 6 sec.)
2021-06-27 13:24:33.524 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "heating.temp_d_day" every 60 sec. (initial delay 13 sec.)
2021-06-27 13:24:33.524 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "heating.temp_hcurve" every 60 sec. (initial delay 4 sec.)
2021-06-27 13:24:33.523 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "controller.temp_room" every 60 sec. (initial delay 16 sec.)
2021-06-27 13:24:33.526 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "heating.program_heating_circuit" every 60 sec. (initial delay 5 sec.)
2021-06-27 13:24:33.527 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "dhw.temp_d_dhw" every 60 sec. (initial delay 1 sec.)
2021-06-27 13:24:33.527 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "heating.temp_d_night" every 60 sec. (initial delay 26 sec.)
2021-06-27 13:24:33.526 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "dhw.program_dhw_circuit" every 60 sec. (initial delay 10 sec.)
2021-06-27 13:24:33.522 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "controller.temp_room" every 60 sec. (initial delay 2 sec.)
2021-06-27 13:24:33.528 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "heating.status_global_system_off" every 60 sec. (initial delay 1 sec.)
2021-06-27 13:24:33.535 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:broadcastguinnes:guinnes:FE ...
2021-06-27 13:24:33.540 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:abgestaubt:guinnes:08 ...
2021-06-27 13:24:35.941 [INFO ] [.eclipse.smarthome.model.script.eBus] - eBus Restart 

Leider kommt dann sehr häufig folgender Fehler :

Code: Alles auswählen

2021-06-27 13:24:53.852 [ERROR] [dev.ebus.core.EBusLowLevelController] - error!
java.lang.InterruptedException: null
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2072) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1475) ~[?:1.8.0_252]
	at de.csdev.ebus.core.EBusControllerBase.shutdownThreadPool(EBusControllerBase.java:262) ~[bundleFile:?]
	at de.csdev.ebus.core.EBusControllerBase.dispose(EBusControllerBase.java:292) ~[bundleFile:?]
	at de.csdev.ebus.core.EBusLowLevelController.dispose(EBusLowLevelController.java:462) ~[bundleFile:?]
	at de.csdev.ebus.core.EBusLowLevelController.run(EBusLowLevelController.java:245) [bundleFile:?]

Danach habe ich auch keinen Zugriffe per Putty auf Openhab : Der Prompt zur eingabe des Passwortes kommt, danach nichts mehr. ( Passiert aber auch, wenn ich die Rule nicht ausführe, hängt also mit dem 1. Fehler zusammen )

Es hilft dann nur Spannung aus, Spannung ein, 10 Minuten warten, per Putty ( das geht dann wieder ) sudo poweroff und nochmal Spannung aus und wieder an.
Hat jemand eine Idee, was ich noch versuchen kann bzw. woher der ursprüngliche Fehler kommt ?

[udo1toni]

Die Rule ist ein bisschen ungünstig.

Code: Alles auswählen

var Timer tEBusRestart = null
var Boolean bEBusRestart = false
rule "eBus Restart Binding"
when
    Item eBusZyklusError received command ON
then
    if(tEBusRestart !== null) return;
    
    tEBusRestart = createTimer(now.plusMillis(10),[|
        if(bEBusRestart) {
            var String  Restart = executeCommandLine("sudo /usr/bin/ssh -p 8101 -i /home/openhab/openhab.id_rsa openhab@localhost bundle:start org.openhab.binding.ebus", 10000)
            logInfo("eBus", "eBus Restart {}",Restart)
            tEBusRestart = null
            bEBusRestart = false
        } else {
            var String Restart = executeCommandLine("sudo /usr/bin/ssh -p 8101 -i /home/openhab/openhab.id_rsa openhab@localhost bundle:stop org.openhab.binding.ebus", 10000)
            logInfo("eBus", "eBus Stop {}",Restart)
            tEBusRestart.reschedule(now.plusSeconds(25))
            bEBusRestart = true
        }
    ])
end

Da Du das Bndle schon gestoppt hast, ist bundle:restart nicht richtig. Stattdessen solltest Du bundle:start verwenden. Thread::sleep() mit Werten deutlich über 500 ist schlecht und kann durchaus ein Grund für das Versagen der Rule sein (aber nicht sicher ). Deswegen der Umbau auf eine Timer basierte Rule.

Funktioniert der restart-Befehl denn zuverlässig, wenn Du ihn von Hand eingibst?

Das Timeout sollte (da localhost) deutlich niedriger angesetzt werden können, z.B. mit 4 Sekunden statt 10 Sekunden.

[guinnes]

Hallo Udo
Vielen Dank für die schnelle und ( wahrscheinlich ) hilfreiche Antwort

Die Rule ist ein bisschen ungünstig.

Dachte ich mir, ich programmiere normalerweise Delphi, und C/C++ bzw. Java muß ich mir im Internet zusammensuchen

Da Du das Bndle schon gestoppt hast, ist bundle:restart nicht richtig. Stattdessen solltest Du bundle:start verwenden.

Auch das habe ich so im Internet gefunden ( Frag mich aber nicht, wo ? )

Funktioniert der restart-Befehl denn zuverlässig, wenn Du ihn von Hand eingibst?

Wenn ich mit Putty auf das System komme, dann meistens, aber ich komme ja nicht drauf

Das Timeout sollte (da localhost) deutlich niedriger angesetzt werden können, z.B. mit 4 Sekunden statt 10 Sekunden.

Ich will dem Bundle die Zeit geben, auch wirklich runter zu fahren bzw. auch wirklich komplett zu starten

[guinnes]

Nachtrag :
Wenn ich die Rule "von Hand" auslöse ( Schalter eBusZyklusError einfach umschalte ) wird der eBus gestoppt und nach 25 Sekunden neu gestartet und läuft dann auch. Die Frage ist nun, was passiert, wenn wirklich ein Fehler auftritt ( Bleibt nur abzuwarten ).
Trotzdem : Die geänderte Rule sieht "richtiger" aus. Danke nochmal dafür

[udo1toni]

Immer gerne.

openHAB braucht nur Sekundenbruchteile, um ein Binding runterzufahren. Ebenso ist das Hochfahren in Bruchteilen von Sekunden erledigt.

Vermutlich müsste man ein wenig auf Systemseite suchen, was mit der Schnittstelle selbst passiert. Eventuell könnte etwas im Systemlog stehen,

Code: Alles auswählen

sudo journalctl |grep <name der schnittstelle>

wobei <name der schnittstelle> z.B. mit ttyS0 oder so ersetzt wird. Eine andere Möglichkeit wäre

Code: Alles auswählen

dmseg

gerne auch kombiniert mit grep, um die Anzeige einzugrenzen.

EDIT: dmesg

[guinnes]

openHAB braucht nur Sekundenbruchteile, um ein Binding runterzufahren. Ebenso ist das Hochfahren in Bruchteilen von Sekunden erledigt.

Wenn ich Start bzw. Stop von Hand eingebe, dauert es ca. 1-2 Sekunden, bis der Prompt wiederkommt, darum die etwas längere Zeit

Code: Alles auswählen

sudo journalctl |grep <name der schnittstelle>

wobei <name der schnittstelle> z.B. mit ttyS0 oder so ersetzt wird.

Dürfte schwer sein, die Schnittstelle ist WLan

Eine andere Möglichkeit wäre

Code: Alles auswählen

dmseg

gerne auch kombiniert mit grep, um die Anzeige einzugrenzen.

dmseg : Befehl nicht gefunden

[udo1toni]

hihi... Buchstabendreher... dmesg sollte es heißen...

[guinnes]

dmesg sollte es heißen...

Hab ich mir jetzt angesehen : Kann ich nix mit anfangen. Sieht so aus, als ob das ein Boot-Log ist

[udo1toni]

dmesg liefert die Kernel-Meldungen. Wenn ein Gerät weg fliegt, sollte man das dort sehen können, genauso, wenn es wieder kommt.

Achso... ist ja Netzwerk...

Ist da nichts weiter beteiligt? eBus ist doch nicht Ethernet, da muss doch was dazwischen?

[guinnes]

Ist da nichts weiter beteiligt? eBus ist doch nicht Ethernet, da muss doch was dazwischen?

Da ist noch ein selbstgelöteter eBus-Adapter (Schaltung ) mit einem Wemos zur Verbindung mit dem WLan dazwischen. Auf dem Wemos ist die Software von John30 ( neuste Version für den Adapter 3 ).
Aber ich habs auch mit dem eBus-Adapter 3 (Schaltung) versucht, das Ergebniss war deutlich schlimmer, da die Schaltung alles andere als stabil ist.
In jedem Fall weden die eBus-Signale über WLan verschickt und landen dadurch auf dem Rasbpi.

Wie dem auch sei, seit 2 Tagen ist Ruhe, aber das heisst nix, das letzte Mal hat das Zeug ne ganze Woche getan, jetzt kann ich nur noch abwarten.

Zu der ursprüglichen Fehlermeldung ( java.net.SocketException: Connection reset ) kannst du nchts sagen ?