[Neuer Adapter] SelveRF
-
@rintrium bin echt froh dass sich jemand endlich die Zeit genommen hat daran zu arbeiten. Ich habe das Adapter bei mir auch installiert und ne neue Instanz angelegt. Leider fangen dann direkt die Fehlermeldungen an. Hier die Debug Logs:
Bin leider nicht der super Entwickler also kann auch nicht sagen was da schief geht. Hoffe die Logs helfen. Wenn ich weitere Infos geben soll, lass es mich wissen und ich helfe gerne!
Schöne Grüße!
EDIT / UPDATE:
soweit ich sehen kann, geht alles relativ ok aber die Methode "selve.GW.device.getInfo" (<methodCall><methodName>selve.GW.device.getInfo</methodName><array><int>8</int></array></methodCall>) hat ein Problem. Wenn ich das selbe Befehl "manuell" ausführe, bekomme ich diese Antwort:<methodResponse><array><string>selve.GW.device.getInfo</string><int>8</int><int>265802</int><string>Kitchen</string><int>1</int><int>1</int></array></methodResponse> -
@mrfenyx mhh, der Adapter tut eigentlich was er soll (abseits davon, dass ich bei dem reconnect noch eine Verzögerung einbauen sollte).
Aus meiner Erfahrung ist das Gateway manchmal ein bisschen "zickig", wenn zu schnell Nachrichten gesendet werden (deutet hier für mich insbesondere drauf hin, dass der manuell abgesetzte Befehl problemlos durchläuft). Ich baue später Mal ein paar Verzögerungen ein, vielleicht löst das das Problem schon. Sicherheitshalber baue ich mal fürs Debugging auch eine Abfrage der Firmware Version des Gateways ein, vielleicht haben wir da auch noch einen Unterschied.Auf was für einem System hast du ioBroker laufen? Entwicklung und Produktiv ist bei mir Linux.
Bei einem Adapter Neustart hängt er sich bei dir immer in gleicher Weise auf?
-
@rintrium bei mir läuft es auch auf Linux (RaspberryPi 4 mit RaspbianOS, alles up-to-date). Der Stick von Selve ist auch am selben RasPi verbunden.
Die gwFirmwareVersion vom Gateway ist 36.6.4.2.
Die Response vom getVersion ist<methodResponse><array><string>selve.GW.service.getVersion</string><int>24</int><int>6</int><int>4</int><int>2</int><int>0</int><string>GW-USB-00F09E40</string><int>2</int></array></methodResponse> -
@rintrium said in [Neuer Adapter] SelveRF:
Bei einem Adapter Neustart hängt er sich bei dir immer in gleicher Weise auf?
ja, leider jedes mal
-
@mrfenyx Ich habe jetzt an dem Adapter einige Anpassungen vorgenommen. Sollte es wirklich nur am zu schnellen Senden von Nachrichten liegen, müsste sich das mit der neuen Version erledigt haben.
Ich habe sicherheitshalber noch in der Dokumentation des Moduls SerialPort nachgelesen, ob es da Besonderheiten für Raspbian gibt. Könntest du überprüfen, ob das bei dir entsprechend eingerichtet ist (eventuell auch schon vor Update des Adapters)? Ich kopiere mal die Anweisungen aus der Doku:
EDIT:
In der Version ist noch ein Bug drin. Noch nicht installieren. Ergänze ich noch.EDIT2:
Ist korrigiert. Version 0.3.7 enthält die Anpassungen und ist bei mir lauffähig. Unsere Gateway Firmwareversionen sind übrigens gleich. -
@rintrium Hi, Serial Port ist auf der Raspi schon aktiv, ansonsten könnte auch FHEM nicht mit das Gateway kommunizieren. Ich habe es sicherheitshalber nochmal "aktiviert" aber die Optionen waren schon so eingetragen.
Ich habe die 0.3.7 installiert aber leider schlägt es jetzt schon beim Ping fehl
selverf.0 2021-09-19 18:31:20.223 info Terminated (ADAPTER_REQUESTED_TERMINATION): Could not reestablish connection with gateway after 3 tries selverf.0 2021-09-19 18:31:20.221 warn Did not receive a method response from gateway within 400ms. Connection is probably lost selverf.0 2021-09-19 18:31:19.820 debug Sending message to gateway: <methodCall><methodName>selve.GW.service.ping</methodName></methodCall> selverf.0 2021-09-19 18:31:19.819 info Serialport connection established. Testing connection with gateway. selverf.0 2021-09-19 18:31:19.810 warn Trying to reestablish connection with gateway. Try number 3 selverf.0 2021-09-19 18:31:19.810 warn Did not receive a method response from gateway within 400ms. Connection is probably lost selverf.0 2021-09-19 18:31:19.409 debug Sending message to gateway: <methodCall><methodName>selve.GW.service.ping</methodName></methodCall> selverf.0 2021-09-19 18:31:19.408 info Serialport connection established. Testing connection with gateway. selverf.0 2021-09-19 18:31:19.398 warn Trying to reestablish connection with gateway. Try number 2 selverf.0 2021-09-19 18:31:19.397 warn Did not receive a method response from gateway within 400ms. Connection is probably lost selverf.0 2021-09-19 18:31:18.996 debug Sending message to gateway: <methodCall><methodName>selve.GW.service.ping</methodName></methodCall> selverf.0 2021-09-19 18:31:18.995 info Serialport connection established. Testing connection with gateway. selverf.0 2021-09-19 18:31:18.988 warn Trying to reestablish connection with gateway. Try number 1 selverf.0 2021-09-19 18:31:18.987 warn Did not receive a method response from gateway within 400ms. Connection is probably lost selverf.0 2021-09-19 18:31:18.584 debug Sending message to gateway: <methodCall><methodName>selve.GW.service.ping</methodName></methodCall> selverf.0 2021-09-19 18:31:18.582 info Serialport connection established. Testing connection with gateway. selverf.0 2021-09-19 18:31:18.496 info starting. Version 0.3.7 in /opt/iobroker/node_modules/iobroker.selverf, node: v12.22.6, js-controller: 3.3.18 -
@mrfenyx Hast du zufällig noch etwas anderes laufen, was das Gateway anspricht? Wenn bei mir noch FHEM an ist (hatte ich vorher benutzt, um das Gateway in ioBroker zu integrieren), dann erhalte ich exakt das gleiche Fehlerbild.
-
@rintrium
"Serial Port" :)) normal dass es nicht geht wenn es noch etwas benutzt und bei mir war es tatsächlich FHEM. Es geht!
Danke und sorry! Müsste man vielleicht irgendwo dokumentieren dass FHEM bitte ausgeschaltet sein soll:$ sudo systemctl stop fhem.serviceUm sicher zu sein dass es ausgeschaltet bleibt:
$ sudo systemctl disable fhem.service -
@mrfenyx Ich ergänze es bei Gelegenheit in der Adapterbeschreibung, dass nichts Anderes auf den SerialPort zugreifen darf. FHEM an sich wäre ja unproblematisch, wenn es eben nicht auf das Gateway zugreifen würde. Wenn FHEM sonst noch für was gebraucht wird, dann müsste also nur das Selve Modul dort deaktiviert werden vermute ich. Ich hätte auch nicht gedacht, dass sich der Serialport überhaupt ein zweites mal parallel öffnen lässt, aber scheinbar blockiert zumindest FHEM das nicht.
Und noch mal Glück gehabt, bei mir hat sich nur durch einen Stromausfall FHEM in einem Docker-Container reaktiviert, ansonsten hätte ich das Fehlerbild niemals nachvollziehen können
Gibst du mir bei Gelegenheit Rückmeldung, ob der Adapter dann bei dir stabil läuft?
Wenn er stabil läuft und Interesse besteht, kann ich die iveo und Sensorkompatibilität noch hinzufügen. -
@rintrium also bislang läuft es ganz gut. Habe eigentlich alle meine Rollladen Controlls in Vis zu den Datenpunkten von deinem Adapter gewechselt. Alles top! Falls sich etwas ändert oder nicht mehr geht, gebe ich dir bescheid.
Ich benutze nur commeo (keine iveo) und auch keine Sensoren also wenn du die implementierst müsste jemand anders diese testen.
Nochmal vielen Dank! Ich kann nun FHEM loswerden! Yipeee! -
Würde mich gerne als iveo Tester zur Verfügung stellen.
Habe aktuell 12 Rolladen (iveo) in FHEM und steuere sie per FHEM Integration, würde das aber gerne direkt zu ioBroker umziehen.
Leider fehlt es mir noch an ioBroker Dev Skills, um eine Version für iveo zu bauen.
Ich habe damals die erste Version des Moduls Selve für FHEM entwickelt, aktuell aber habe ich leider keine Zeit um mich mit dem Thema Integration Selve in ioBroker zu kümmern.
Wäre aber super wenn du auch iveo Rolläden integrieren könntest.
Wie gesagt, zum Testen würde ich mich bereit erklären.Gruß,
-
@jostereo ich habe gerade eine neue Version veröffentlicht, die nun (hoffentlich
) auch mit den iveo Aktoren und Sensoren umgehen kann. Da ich keinerlei Möglichkeit habe den Code zu testen, kann es gut sein, dass es kleinere oder größere Bugs gibt. Dann bitte einfach mit Debug-Log hier posten und ich gucke was ich tun kann.@mrFenyx mit dem Update habe ich den SerialPort so eingestellt, dass ein paralleles Öffnen aus unterschiedlichen Anwendungen einen Fehler schmeißen müsste. Das ist dann wahrscheinlich noch etwas praktischer als ein Eintrag in der Readme (die ich aber auch beizeiten etwas ausführlicher schreiben muss). ...wenn man nur vorher mit allen Fehlern rechnen könnte
-
Vielen Dank schonmal für den Adapter.
Die Steuerung funktioniert für meine 12 Rolläden.
Die Übernahme der Namen aus der Konfiguration des Sticks, funktionierte auch prima.
Habe nur 1 - 2 Warning Meldungen im LOG, habe es dir mal angehangen.Zum Verständnis hätte ich aber noch 2 Fragen:
-
Wenn ich auf einen Rolladen state z.b. "down" true oder false setze, wird der Befehl ausgeführt, d.h. es ist egal ob true oder false.
Ist das so gewollt? -
Gebe es die Möglichkeit den letzten Befehl (down, up, drivePos1, drivePos2, stop) in den jeweiligen Objekten zu speichern, so dass man weiß welcher Befehl als letztes an das Rollo ging?
Ansonsten wie gesagt schonmal vielen Dank.
Bin dann noch einen Schritt weiter weg von FHEM, dank dir.
iobroker.current.log -
-
@rintrium ich bekommen manchmal diese Meldung:
Not implemented method call message from gateway: {"methodCall":{"methodName":["selve.GW.event.sender"],"array":[{"int":["0","2"],"string":["Gateway No.01"]}]}}Ich gehe davon aus dass es gewollt und geplant und dass in zukünftigen Updates die Methode implementiert wird, oder?
EDIT:
soweit ich sehe ist dieses Event eine Nachricht die vom Gateway generiert wird falls ein Sender ein Ereignis erzeugt. Ist also nicht so wichtig (mehr in der Richtung INFO).
In meinem Fall sagt es dass das Gateway automatisch Rollladen heruntergefahren hat (was eigentlich stimmt ) -
@rintrium da ich ein bisschen Zeit hatte, habe ich das hier geschrieben:
Die Event Beschreibungen habe ich von hier übernommen / übersetzt: https://www.rolladen-shop.de/media/pdf/0b/c0/ca/USB-RF-Stick_XML-Spezifikation_Rev_2-0-2-GER.pdf, Kapitel 7.1.4. Bin mir nicht sicher ob das so passt da ich noch nie JS geschrieben habe aber vielleicht hilft es. Könnte in SelveUSBGateway.js irgendwo um die Zeile 543 reinpassen, denke ich. -
@mrfenyx Ich füge die (Events für die) Sender mit einem weiteren Update ein. Ich kann aber aktuell noch nicht versprechen wann genau. Danke auf jeden Fall schonmal für den Code, den nehme ich dann als Basis
@jostereo Zunächst schön, dass es funktioniert. Eine Rückfrage habe ich noch: laut Log wurden bei dir zehn Rollläden erkannt, du schreibst aber, dass du zwölf hast. Werden die Datenpunkte trotzdem für zwölf Rollläden gesetzt? Die Warnmeldungen sind grundsätzlich nicht schlimm, alles was das Gateway nicht oder nicht schnell genug quittiert wird nach Schließen und Wiederaufbau der Verbindung erneut gesendet. Ab und an braucht das Gateway einfach einen Moment länger..
Zu deinen Fragen:
1: Ja, das ist so gewollt, da die Datenpunkte als Button ausgelegt sind. Jedes zuweisen eines Wertes sorgt sozusagen dafür, dass der Button "gedrückt" wird.
2: Kann ich für die nächste Version vorsehen. Es würde dann aber wirklich nur der letzte Befehl angezeigt, der über das Gateway lief. Wurde der Rollladen also per Schalter betätigt kann das nicht berücksichtigt werden (zumindest sehe ich dafür keine Möglichkeit). -
@rintrium ich probiere es gerade bei mir lokal und gib bescheid ob es läuft. Falls ja, kann ich ein Pull Request machen, wenn du das willst. Habe das Format der Logs auch ein bisschen "verbessert", z.B.:
case "0": this.adapter.log.info("Sender " + senderName + " with ID: " + senderID + ", reports no events available. (Status after startup)"); break;Ich sag dir morgen ob es funktioniert hat, nachdem ein Event getriggered wird.
-
Bezüglich der Rolladenanzahl muss ich mich korrigieren.
Habe aktuell nur 9 Rolladen im Gateway konfiguriert, deswegen ist die Anzahl der angelegten Rolladen durch das Modul auch richtig.Bezüglich meines 2. Punktes:
Der letzte Befehl der per ioBroker an das entsprechende Rollo gesendet wurde, sollte theortisch ja der Status des Rolladen sein.
Da iveo Rolläden leider Unidirektional sind, können Sie den Status ja nicht zurückmelden, deswegen würde es reichen den letzten Befehl "up, down, stop..." in einem DP zu speichern pro Rollo.Ich bin allerdings aus der Doku nicht 100% schlau geworden ob iveo auch die Gateway Events unterstützt. Nach meiner Ansicht erzeugt das Gateway für einen Befehl einen Event, allerdings weiß ich nicht ob solch ein Event auch erzeugt wird, wenn man die "normalen" Fernbedienung nutzt.
-
@rintrium Habe die Änderungen bei mir implementiert und lokal getestet. Hatte versucht ein Pull Request zu erstellen aber habe kein Zugriff. Wie soll ich dir am besten diese geben? patch.diff? Soll ich für das Projekt ein Fork machen? Was ist dir lieber?
EDIT: habe ein fork gemacht und dann ein PR erstellt -> https://github.com/Rintrium/ioBroker.selverf/pull/18
-
Ich habe gerade die Version 0.5.0 fertiggestellt.
@mrfenyx Ich habe deinen Code in der neuen Version integriert (wenn auch etwas umgeschrieben). Sender werden nun ebenfalls als Datenpunkte zur Verfügung gestellt. Meines Erachtens müssten sich darüber nun die Sender nutzen lassen, um beliebige Aktionen durch ioBroker durchzuführen.
@jostereo Bei den Iveo Aktoren ist nun ein Datenpunkt vorhanden, der das letzte Kommando speichert.
