NEWS
Test Adapter EnOcean v0.5.x
-
@andy61 Hallo, es hat mir doch keine Ruhe gelassen. Ich habe in einer VM auf einer anderen Synology die Homatic Raspberry-Instanz mit CuxD laufen. Dort wird beim duchleiten von USB der FAM-USB sofort erkannt (habe aber keinen Key). Grundsätzlich funktioniert also mein Vorhaben.
Meine Frage: hat jemand den Adapter mit der Eltako FAM-USB schon am laufen? Eine Bestätigung habe ich bisher leider nicht gefunden.
Bei der Auswahl der Schnittstelle wird nur /dev/ttyUSB0 (hier steckt der Stick) angezeigt. In der VM sehe ich richtig den Namen. Ist das korrekt?
Im log (debug) ist folgendes:sendTo "getEEPList" to system.adapter.admin.0 from system.adapter.enocean.0
sendTo "getDevices" to system.adapter.admin.0 from system.adapter.enocean.0
sendTo "listSerial" to system.adapter.admin.0 from system.adapter.enocean.0
info ["/dev/ttyUSB0","/dev/ttyUSB1"]
Sent data: 5500010005700309
info starting. Version 0.5.1 in /opt/iobroker/node_modules/iobroker.enocean, node: v14.17.2, js-controller: 3.3.15Hilft das evtl. weiter?
LG
Andreas -
@jey-cee said in Test Adapter EnOcean v0.5.x:
Wird im Log eine Meldung, "Trying to reconnect. Attempt no. " ausgegeben?
Nein, dort steht nur "(796) The TCP port was closed."
Habe es nochmal auf anderem System getestet, Verhalten bleibt wie oben beschrieben. Starte ich den Enocean-Adapter manuell neu, ist alles top.
-
@andy61 sagte in Test Adapter EnOcean v0.5.x:
Meine Frage: hat jemand den Adapter mit der Eltako FAM-USB schon am laufen? Eine Bestätigung habe ich bisher leider nicht gefunden.
Ist egal welches device du hast, die benutzen alle den gleichen Mikroprozessor mit fertiger Firmware.
@andy61 sagte in Test Adapter EnOcean v0.5.x:
Bei der Auswahl der Schnittstelle wird nur /dev/ttyUSB0 (hier steckt der Stick) angezeigt. In der VM sehe ich richtig den Namen. Ist das korrekt?
Ja das ist Korrekt so du siehst den Pfad zum Gerät.
@andy61 sagte in Test Adapter EnOcean v0.5.x:
info ["/dev/ttyUSB0","/dev/ttyUSB1"]
Da werden 2 USB Geräte angezeigt und da ich im Log keine Antwort vom Stick sehe geh ich davon aus das USB0 nicht der FAM_USB ist.
Wenn du Firefox benutzt kann es sein das du die Zweite Auswahl nicht angezeigt bekommst, das ist ein Problem mit Firefox. -
@iobaer @tobitobsta könnt ihr bitte die Version 0.5.3 testen?
-
@jey-cee said in Test Adapter EnOcean v0.5.x:
@iobaer @tobitobsta könnt ihr bitte die Version 0.5.3 testen?
getan - vielen Dank!
ich habe den Staufix erstmal "entkoppelt" (ob das nötig war, weiß ich nicht).
Dann habe ich über drop down den Staufix hinzugefügt und wie beschrieben, das Fenster geschlossen.
Dann direkt das Staufix "koppeln" ausgelöst.
es taucht kein Gerät in der Liste auf.
-
Antwort wegen ser2net kommt noch (teste da gerade noch etwas, bevor ich Rückmeldung gebe), nur vorab:
Sind diese WARN-Meldungen bei Adapter-Installation bekannt (Debug-Ausgabe aktiv)?
npm install Jey-Cee/ioBroker.enocean#3274815fff77bcca0a7aa3449e34213fcfb97e49 --prefix "/opt/iobroker" (System call) npm WARN deprecated gulp-util@3.0.8: gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5 npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/fsevents):npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.7 (node_modules/osx-temperature-sensor):npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.7: wanted
-
@tobitobsta bei dir taucht ein Fehler auf den ich nicht nachvollziehen kann. Als Folge wird der Staufix nicht angelernt.
Kannst du Mal im Browser die Konsole, Taste F12 drücken, öffnen und dann das anordnen Auslösen und mir das was in der Konsole Ausgegeben wird hier Posten. -
@iobaer sagte in Test Adapter EnOcean v0.5.x:
Sind diese WARN-Meldungen bei Adapter-Installation bekannt (Debug-Ausgabe aktiv)?
Nein, das sind aber auch keine direkten Abhängigkeiten vom Adapter. Wenn dann bringen andere Module die mit.
-
@jey-cee said in Test Adapter EnOcean v0.5.x:
@tobitobsta bei dir taucht ein Fehler auf den ich nicht nachvollziehen kann. Als Folge wird der Staufix nicht angelernt.
Kannst du Mal im Browser die Konsole, Taste F12 drücken, öffnen und dann das anordnen Auslösen und mir das was in der Konsole Ausgegeben wird hier Posten.entschuldige meine Unwissenheit - ich bin mir nicht sicher was genau ich machen soll.
Was ich jetzt getan habe:- leerer Browser
- f12 gedrückt
- iobroker-admin geladen
- instanzen tab aufgerufen
- enocean instanz einstellungen aufgerufen
- neues Gerät
- Kessel/Staufix auswählen
- Gerät hinzufügen
- Koppeln am Staufix ausgelöst
das kam in der Konsole dazu:
-
@tobitobsta passt das war genau was ich wollte, leider seh ich auch hier keinen Hinweis darauf wo der Fehler herkommt.
-
@jey-cee said in Test Adapter EnOcean v0.5.x:
@iobaer @tobitobsta könnt ihr bitte die Version 0.5.3 testen?
Sooooo .... erstmal vielen Dank für die schnelle Anpassung
Ergebnisse:
-
Starte ich den per ser2net angebundenen Raspi, mit dem der Enocean-Stick verbunden ist, nun neu ("reboot"), geht - wie auch zuvor - die Enocean-Instanz auf gelb. Sobald der Raspi wieder da ist und ser2net läuft, verbindet sich Dein Adapter wieder ordnungsgemäß und schaltet auf grün um. Dein Update hat den Fehler also behoben. Nicht getestet habe ich, wie lange die Unterbrechung maximal sein dürfte (Du hast ja glaub nur eine begrenzte Zahl von Reconnect-Versuchen eingebaut).
-
Ich habe testweise mal im Switch den Port des Raspis disabled. Das merkt die Enocean-Instanz nicht, sie bleibt grün - auch, wenn Befehle abgesetzt werden. Erst nach einem Neustart der Enocean-Instanz bleibt diese auf gelb, da sie dann natürlich die Verbindung zum Raspi (= Enocean-Stick via ser2net) aufbauen möchte und dies nicht gelingen kann, da der Port ja geblockt ist. Umgekehrt genauso: aktiviere ich den Port wieder, bemerkt dies die Enocean-Instanz nicht - die Kommunikation funktioniert eben einfach wieder. Eine kurze Google-Recherche ergab, dass dies wohl ein bekanntes Verhalten bei ser2net zu sein scheint und erstmal nichts mit Deinem Adapter zu tun hat. Als Workaround kann man als User ja z.B. in dem Fall den externen Raspi regelmäßig anpingen und prüfen, ob dieser noch erreichbar ist. Kommt immer auch drauf an, wie kritisch das alles ist. Durch die externe Anbindung via ser2net hat man sich natürlich zwangsläufig ein paar mögliche Fehlerquellen eingebaut, die man ggf. zumindest teilweise selber abfangen kann. Bei mir geht es aber derzeit nicht anders, da ich den ioBroker nun als virtuelle Debian-Maschine unter Hyper-V nutze (kann ich grundsätzlich jedem empfehlen - da willst Du nie wieder mit einem Raspi arbeiten) und man in Hyper-V keine USB-Geräte durchschleifen kann ...
Edit: An der Stelle ist mir noch aufgefallen: ändere ich während der Switch-Port geblockt ist (also Deine Instanz nicht mit dem Enocean-Stick kommunizieren kann) z.B. von einem FSR14-4x CMD von 0 auf 1 oder umgekehrt, dann wird der Wert grün (Bestätigt=true), obwohl der Befehl ja tatsächlich nicht ausgeführt wurde. Wenn ich mich richtig erinnere, hast Du dieses Verhalten vor einigen Monaten zumindest beim direkten Betrieb des Sticks als USB-Gerät abstellen können?
Danke Dir!
-
-
@iobaer die Thematik in 2 ist mir schon bewusst gewesen, aber mir ist als Lösung nur eingefallen regelmäßig einen Befehl (als Ping) zu senden. Es wäre ja möglich das nur ser2net auf dem pi nicht mehr läuft, dann bringt ein normaler Ping nichts.
Das ich hier Sinnvollerweise noch prüfen kann ob der Befehl auch vom Stick Quittiert wird, hatte ich noch nicht auf dem Schirm.
Meine Befürchtung ist das ich damit ein größeres Fass auf mache.
Der Plan war aber schon das auch Um zu setzen. -
@jey-cee Ich muss zugeben, ich hab nicht alles gelesen, ggf. geht meine Lösung auch komplett am Ziel vorbei. Aber vielleicht hilft es ja.
In Z-Wave hatte ich auch ein Thema mit "Disconnect zu ser2net" erkennen und habe es mit diesem PR gelöst:
https://github.com/zwave-js/node-zwave-js/pull/2601/filesKern des ganzen war die Zeile
serial.setKeepAlive(true, 2500);
(Timeout nach Bedarf anpassen), welche einen "ping" auf Verbindungs-Ebene einrichtet und Reaktion auf das
"close"
event.Getestet hab ich das mit ser2net beenden sowie Kabel am Pi ziehen, beides während der Adapter verbunden ist. Nach kürzester Zeit wird die Verbindung als getrennt erkannt.
-
@jey-cee said in Test Adapter EnOcean v0.5.x:
Das ich hier Sinnvollerweise noch prüfen kann ob der Befehl auch vom Stick Quittiert wird, hatte ich noch nicht auf dem Schirm.
Toll wäre es auf jeden Fall, weil dann das Verhalten wie beim lokal angeschlossenen USB-Stick wäre
Danke!
-
@alcalzone danke das ist glaube ich ziemlich genau das was mir weiterhilft.
-
@tobitobsta ich würde vorschlagen das ich mal per Any Desk bei dir drauf schau um den Fehler zu Untersuchen, damit wir da Zeitnah eine Lösung finden.
Schreib mir am besten eine email mit deiner Telefonnummer an jey-cee@live.com.
-
@jey-cee said in Test Adapter EnOcean v0.5.x:
@tobitobsta ich würde vorschlagen das ich mal per Any Desk bei dir drauf schau um den Fehler zu Untersuchen, damit wir da Zeitnah eine Lösung finden.
Schreib mir am besten eine email mit deiner Telefonnummer an jey-cee@live.com.
Wow! Danke! Liege gerade ziemlich flach aber melde mich sobald ich wieder sicher am PC sitzen kann. VG
-
Ich habe heute mal statt ser2net den Multihost-Betrieb aufgesetzt, d.h. die Enocean-Instanz des Adapters von @Jey-Cee auf den Raspi verschoben und dort als lokales Gerät den Enocean-Stick eingebunden - funktioniert wunderbar. Das einfach mal als Info und weitere Alternative.
-
Bei mir sind die Aktoren noch aus der Anfangszeit mit "Sender_ID" und "baseIDoffset" angelegt - kann das so bleiben? Funktioniert einwandfrei - ich frage nur vor dem Hintergrund zukünftiger Aktualisierungen. Danke.
-
@iobaer ja das wird auch immer noch verwendet.ich hab nicht vor daran etwas zu ändern.