Oilfox Adapter keine Funktion mehr?
-
@mcm57
ich weiss nicht, was das Problem bei @MarioS ist, aber ich nehme an, dass es sich um das allgemeine Problem mit dem haengen des Tasks handelt.
Hier hilft ein einfaches Script, das den Task killt - wurde hier schon mehrfach gepostet, und ist auf Github hinterlegt..Bei mir laeuft der Adapter Einwandfrei unter js-controller 5.0.12 und latest, Node 18.17.1 usw.. im debian bookworm lxc.
-
@ilovegym OK, das ist eine (für mich) neue Info.
DANKE für deinen Input.Kannst du bitte einen Beitrag beim obigen Issue hinterlassen. Ich kann dann gerne (nach mein em Urlaub) mal checken, ob es für ein Hängen potenzielle Orte gibt (beispielsweise fehlende Timeouts beim Lesen aus dem Netz) und / oder zusätzliche Debug Logs mal einbauen. Wenn dann jemand mit Oilfox hier testen bzw. debug output liefern würde, können wir ev. was bereinigen.
Pollt mich bitte ruhig wenn ich drauf vergesse
Edit:
Ist wohl issue https://github.com/iobroker-community-adapters/ioBroker.oilfox/issues/110Hab das nicht weiter verfolgt, da #97 suggeriert hat, dass eh nichts mehr geht.
closed Process occasionally stuck #110
-
@mcm57
genauso.. bei mir haengt der Process ca alle 2-3 Tage mal.. aber Daten kommen, da gibts keine Probleme.
Wenn es was zu testen / debuggen gibt, sag Bescheid..
-
@ilovegym - und wer sonst noch Zeit / Lust hat:
Bitte gelegentlich mit der neuen BETA Version 4.2.0 testen. Sollte ab morgen im latest Repository verfügbar sein.Die http Request haben nun ein Timeout von 5s - damit sollten Hänger vermieden werden. Da ich allerdings kein oilfox system habe kann ich die Änderungen nicht testen - insbesondere nicht ob es beim Auftreten von Timeouts zu Folgefehlern kommt.
Bitte bei Problemen bitte ein Issue öffnen und das Logfile (und natürlich die Versionen von Adapter, Admin, js-controller, node) mitgeben.
DANKE
P.S. Feedback falls alles läuft ist natürlich auch hilfreich.
-
@mcm57
vielen Dank, hab das Update drauf, da bei mir der Fehler mit dem haengenden Process recht selten und nur alle paar Tage wenn ueberhaupt vorkam...
Die Version 4.2.0 laeuft ohne Fehler bisher, System
Debian Bookworm, Proxmox LXC: CPU: 0,13 % RAM: 64,8 % Betriebszeit: 2d20h Verfügbar: 5.0.12 Installiert: 5.0.12 Ereignisse: ⇥68 / ↦13 Plattform: linux Betriebssystem: linux Architektur: x64 CPUs: 8 Geschwindigkeit: 3192 MHz Modell: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz RAM: 31.3 GB System-Betriebszeit: 2 T. 19:54:59 Node.js: v18.17.0 time: 1694254012130 timeOffset: -120 NPM: 9.6.7 Adapter-Anzahl: 585 Datenträgergröße: 31.2 GB Freier Festplattenspeicher: 24.8 GB Aktive Instanzen: 68 Pfad: /opt/iobroker/ Betriebszeit: 2 T. 19:54:45 -
@ilovegym
Danke fürs Feedback.
Dann ist es zumindest mal keine Verschlechterung.
Wie gagt - ich kann leider nicht selbst testen
-
@mcm57
Hallo,
ich bin gerade dabei mir eine Oilfox anzuschaffen, läuft der Adapter im Moment soweit stabil, dass sich die Anschaffung lohnt ?
Habe hier im Verlauf gelesen, dass es evtl. Probleme geben könnte, da man einen Account benötigt.
Bei mir würde wahrscheinlich nur der Oilfox Pro funktionieren, wird dieser auch unterstützt ?Vielen Dank & Grüße !
-
@maxi885
HalloLeider kann ich dir deine Fragen nicht beantworten. Ich habe 2023 nur ein Timeout zur (möglichen) Behebung des Problems "hängender Adapter" ergänzt. Ich selbst habe keine passende Hardware und keinen (eigenen) ZUgang zum Cloud System.
Ob der Adapter nun stabil läuft kannst du am besten HIER im Forum erfragen. Eine größere Anzahl von Issues existiert derzeit nicht. Da ich nicht weiß welche Modelle der Hardware existieren kann ich dir leider auch nicht zusagen ob eine bestimmte Hardware funktioniert oder nicht. Ev gibts ja hier Anwender die das beantworten können.
Sorry dass ich nicht helfen kann
mcm1957
-
@maxi885 @mcm57
mein Oilfox laeuft seit ueber 2 Jahren problemlos, habe auch den Pro, einmalige Anschaffungskosten waren um die 100 Euro damals, es wird ein Account benoetigt, der Oilfox schickt die Daten an den Server dort, und der Adapter holt die Daten von dort ab.
Also nur local betreiben geht nicht.
Da sich an dem Account/Servern aus Usersicht nichts geaendert hat, gibts keinen Grund, jetzt keinen zu kaufen.Der Adapter laeuft, ab und zu ( ca 1x in der Woche ) haengt der Schedule-Task, was mit einem kleinen Blockly das den Process checkt und notfalls killt, behoben wird.
Leider gibts dazu auch im Debuglog keine Info.
Da ich damit leben kann und das auch selten vorkommt, hat das weder Prio noch einen Grund zum meckern..
Ich wuerde mir wieder einen kaufen.. die Batterie ist immer noch die erste, der wacht einmal am Tag auf und misst, sendet die Daten und legt sich wieder schlafen.Edit:
System: Buanet Docker V9.0.1 auf Synology RS1619xs, Node 18.19, alles latest, DB redis/redis, MACVlan
Lief auch schon in einem LXC, in ner VM (Serverhardware HP DL380 G8, Intel Nuc I5, I7 und I9 ), und auf dem Raspi 3 und 4, auf nem Futro ThinClient, verschiedenen Lenovo- und Dell Laptops mit Debian 10,11,12. ... was man halt so rumliegen hat..
-
@ilovegym said in Oilfox Adapter keine Funktion mehr?:
Der Adapter laeuft, ab und zu ( ca 1x in der Woche ) haengt der Schedule-Task, was mit einem kleinen Blockly das den Process checkt und notfalls killt, behoben wird.
Leider gibts dazu auch im Debuglog keine Info.Falls das wieder mal auftritt wär von Interesse wie sich das äußert. Was tut dein Blockyl dagegen?
Du schreibts es gibgt keine Meldungen im Log. An sich sollte sowohl der Start als auch die Beendigung des scheduled Adapters gelogged werden. Wird der Adapter beim Hänger nicht gestartet? Oder nicht beendet? Gibts "already running" Meldungen?Vielleicht kommen wir dem Problem ja doch ni#och auf die Schliche
-
@ilovegym said in Oilfox Adapter keine Funktion mehr?:
@maxi885 @mcm57
mein Oilfox laeuft seit ueber 2 Jahren problemlos, habe auch den Pro, einmalige Anschaffungskosten waren um die 100 Euro damals, es wird ein Account benoetigt, der Oilfox schickt die Daten an den Server dort, und der Adapter holt die Daten von dort ab.
Also nur local betreiben geht nicht.
Da sich an dem Account/Servern aus Usersicht nichts geaendert hat, gibts keinen Grund, jetzt keinen zu kaufen.Der Adapter laeuft, ab und zu ( ca 1x in der Woche ) haengt der Schedule-Task, was mit einem kleinen Blockly das den Process checkt und notfalls killt, behoben wird.
Leider gibts dazu auch im Debuglog keine Info.
Da ich damit leben kann und das auch selten vorkommt, hat das weder Prio noch einen Grund zum meckern..
Ich wuerde mir wieder einen kaufen.. die Batterie ist immer noch die erste, der wacht einmal am Tag auf und misst, sendet die Daten und legt sich wieder schlafen.Vielen Dank für die schnelle und ausführliche Antwort, das hat mir sehr geholfen, in dem Fall werde ich mir das Pro Modell wohl anschaffen, das kostet allerdings im Moment um die 200-300€, je nach Shop.
-
@mcm57
Das Blockly hab ich hier aus dem Forum, ich kann gerne den Adapter nochmal auf Debug stellen und warten, bis der Fehler wieder auftritt.. aber laut Log beendet er sich ganz normal, aber der Process wird nicht gekillt.. es gibt keine Meldungen von already-running.. das waere ja auch zu einfach..
Hier mal mein Blockly:
<xml xmlns="https://developers.google.com/blockly/xml"> <variables> <variable id="8IP#j[o4.1Dn*G@+NY}y">result</variable> </variables> <block type="schedule" id="o|3zwufTnSrB~a84ZUL=" x="112" y="63"> <field name="SCHEDULE">53 */1 * * *</field> <statement name="STATEMENT"> <block type="exec" id="U$LDpNu3Hqkv/*3dGlp$"> <mutation xmlns="http://www.w3.org/1999/xhtml" with_statement="true"></mutation> <field name="WITH_STATEMENT">TRUE</field> <field name="LOG">log</field> <value name="COMMAND"> <shadow type="text" id=",{T#dWEZj~ZEw~5N0}oB"> <field name="TEXT">ps -C io.oilfox.0 -o pid=</field> </shadow> </value> <statement name="STATEMENT"> <block type="controls_if" id="tk_Ey5LR=C[~:OyIQpJ`"> <value name="IF0"> <block type="logic_compare" id="@`N=Rd9mYCOqUylq/Zft"> <field name="OP">GT</field> <value name="A"> <block type="convert_tonumber" id="_ow[cE(.j{+E]ORf_SEO"> <value name="VALUE"> <block type="variables_get" id="}3n|EdT[1?}7v)|s7Grd"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> <value name="B"> <block type="math_number" id="HqkmoXb^a4?eF*for+BT"> <field name="NUM">0</field> </block> </value> </block> </value> <statement name="DO0"> <block type="debug" id="-7*^4xla36^uNFn61WCO" inline="true"> <field name="Severity">warn</field> <value name="TEXT"> <shadow type="text" id="0Rfo7e3=C:7#JvHiZ}[D"> <field name="TEXT">test</field> </shadow> <block type="text_join" id="sW,lAV{@(]s_ijfz^bOB" inline="true"> <mutation items="2"></mutation> <value name="ADD0"> <block type="text" id="K?tC5KRS3J;1`qpyr.Zl"> <field name="TEXT">Oilfox Process is still running with PID: </field> </block> </value> <value name="ADD1"> <block type="variables_get" id="wYXOd`nim5XU*rfE*cP:"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> <next> <block type="comment" id="2;DilA=cs3U~8*}INZFZ"> <field name="COMMENT">Meldung an Synochat</field> <next> <block type="control" id="=_c1A:]Vp$6.s^h/[ls]"> <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation> <field name="OID">synochat.0.Technik.message</field> <field name="WITH_DELAY">FALSE</field> <value name="VALUE"> <block type="text_join" id="_o,[6D:b{#U~|y_0EY2T" inline="true"> <mutation items="2"></mutation> <value name="ADD0"> <block type="text" id="3}}i0W?{any%JQ:arNLl"> <field name="TEXT">Oilfox Process is still running with PID: </field> </block> </value> <value name="ADD1"> <block type="variables_get" id="Lwgg9qN^0H=vjerfMX$~"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> <next> <block type="timeouts_wait" id=".axMe}DD/sKvon19Dihe"> <field name="DELAY">1000</field> <field name="UNIT">ms</field> <next> <block type="debug" id="85){k)({)30^z0ev=xuI" inline="true"> <field name="Severity">warn</field> <value name="TEXT"> <shadow type="text" id="PM=emth:*ztem/pURd7t"> <field name="TEXT">test</field> </shadow> <block type="text_join" id="btn8wJPQ)`a2jXf`?(yL" inline="true"> <mutation items="2"></mutation> <value name="ADD0"> <block type="text" id="_6_qe^/|8p7xd%CA*3hu"> <field name="TEXT">Trying to kill oilfox process with PID: </field> </block> </value> <value name="ADD1"> <block type="variables_get" id="2`!;McGDH,a_XR[_qaQp"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> <next> <block type="exec" id="+a#UF#~UNvivT%;Y4v!2" inline="true"> <mutation xmlns="http://www.w3.org/1999/xhtml" with_statement="false"></mutation> <field name="WITH_STATEMENT">FALSE</field> <field name="LOG">log</field> <value name="COMMAND"> <shadow type="text" id="AX~Io}N(SP^f!t%:~9G^"> <field name="TEXT">text</field> </shadow> <block type="text_join" id="2IVy`5duT/]i~aFWZRu7" inline="true"> <mutation items="2"></mutation> <value name="ADD0"> <block type="text" id="D[B{R[NEWn+Oh;;}g==Y"> <field name="TEXT">kill </field> </block> </value> <value name="ADD1"> <block type="variables_get" id="edMrxCqM*04O01F9bM44"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> <next> <block type="variables_set" id="@KL.3W/Z1@7,WY$2}1Ev"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> <value name="VALUE"> <block type="math_number" id="C.F#m$cC#G/_R9oXL!wn"> <field name="NUM">0</field> </block> </value> <next> <block type="timeouts_wait" id="qWz9_xKc)`kq`@]D=:22"> <field name="DELAY">2000</field> <field name="UNIT">ms</field> <next> <block type="debug" id="XccE*w!P=Aq`QkhIV!jx" inline="true"> <field name="Severity">warn</field> <value name="TEXT"> <shadow type="text" id="+G9}nw`nSw9`+x4HJ~Wt"> <field name="TEXT">test</field> </shadow> <block type="text" id="FH1Cel*B#@S/mz8?hXVC"> <field name="TEXT">Checking wether Oilfox Process has been actually killed..</field> </block> </value> <next> <block type="exec" id="_(,nJIi7NBy$p4EakkYz" inline="true"> <mutation xmlns="http://www.w3.org/1999/xhtml" with_statement="true"></mutation> <field name="WITH_STATEMENT">TRUE</field> <field name="LOG">log</field> <value name="COMMAND"> <shadow type="text" id="SnTt(Uvz0=j-P!bJt:~-"> <field name="TEXT">text</field> </shadow> <block type="text" id="tK1#.Lw!-Ehbi5hN2Q]L"> <field name="TEXT">ps -C io.oilfox.0 -o pid=</field> </block> </value> <statement name="STATEMENT"> <block type="controls_if" id="0,_:^C%UHA*L:fFT$bh5"> <mutation else="1"></mutation> <value name="IF0"> <block type="logic_compare" id="O]@j..!!(o=BWsd{@9A2"> <field name="OP">GT</field> <value name="A"> <block type="convert_tonumber" id="CS79ATwWPP?cx=IIyQe["> <value name="VALUE"> <block type="variables_get" id="W9Jsvl3whHu6BZ,p0P~n"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> <value name="B"> <block type="math_number" id="qg=g21E9F./9_|g[+7:-"> <field name="NUM">0</field> </block> </value> </block> </value> <statement name="DO0"> <block type="debug" id="5]9n]#C=15G8+?[P{DtH" inline="true"> <field name="Severity">warn</field> <value name="TEXT"> <shadow type="text" id="T({SZg@CwJUmod{TSFC;"> <field name="TEXT">test</field> </shadow> <block type="text_join" id="}4G@gLqJ(w+6}fi!;3nF" inline="true"> <mutation items="2"></mutation> <value name="ADD0"> <block type="text" id="qKD@$7YOy/k.=-/b-gdn"> <field name="TEXT">Oilfox Process is still running with PID: </field> </block> </value> <value name="ADD1"> <block type="variables_get" id="Vhe@W,U+Hwlv?tVkK:!x"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> <next> <block type="comment" id="DIC{ELf]?3g~yitPF=V`"> <field name="COMMENT">Meldung an Synochat</field> <next> <block type="control" id="8il,Wv$QreI,?JXhH7dE"> <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation> <field name="OID">synochat.0.Technik.message</field> <field name="WITH_DELAY">FALSE</field> <value name="VALUE"> <block type="text_join" id="8ElEA`dI$GdyM:mC=e|t" inline="true"> <mutation items="2"></mutation> <value name="ADD0"> <block type="text" id="q-iHjgd)(HEDJ`K8FjAx"> <field name="TEXT">Couldn't kill ...Oilfox Process is still running with PID: </field> </block> </value> <value name="ADD1"> <block type="variables_get" id="%RST{$eL.9h,g,oNc65C"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> </block> </next> </block> </next> </block> </statement> <statement name="ELSE"> <block type="comment" id="(aA3RGTBX|d9a}qj1??^"> <field name="COMMENT">Meldung an Synochat</field> <next> <block type="control" id="++a5A5fN|Zq[^,X6ef~M"> <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation> <field name="OID">synochat.0.Technik.message</field> <field name="WITH_DELAY">FALSE</field> <value name="VALUE"> <block type="text_join" id="Co:zY1_D2hrGuYZ*.j`2" inline="true"> <mutation items="2"></mutation> <value name="ADD0"> <block type="text" id="fr1VZ{89e$p]EL!g}iVu"> <field name="TEXT">Oilfox Process killed! </field> </block> </value> <value name="ADD1"> <block type="variables_get" id="$eeyNK[4fOF4nr7odQSW"> <field name="VAR" id="8IP#j[o4.1Dn*G@+NY}y">result</field> </block> </value> </block> </value> </block> </next> </block> </statement> </block> </statement> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </statement> </block> </statement> </block> </statement> </block> </xml> -
@ilovegym
aber laut Log beendet er sich ganz normal, aber der Process wird nicht gekillt..
Das log (incl. ein paar Zeilen vorher/nachher) würd mich interessieren. Wenn der js-controller eine Beendigung meldet und dann der Prozess noch läuft wär da was sehr suspekt. Dass der Prozess nicht gekillt wird siehst du wahrscheinlich mit ps auf der Commandline - oder?
Wie wirkt sich die Situation aus User Sicht aus? Gibts dann keine Updates mehr? Fehler im Log (a la already running) gibts ja anscheinend nicht.
-
@mcm57
genau, mit ps sieht man, dass der io.oilfox noch laeuft..
und richtig, es gibt dann einfach keine updates mehr..Debug ist an, warten wir mal, wann wieder ne Meldung kommt, dass der Task haengt..
@mcm57 sagte in Oilfox Adapter keine Funktion mehr?:
Das log (incl. ein paar Zeilen vorher/nachher) würd mich interessieren. Wenn der js-controller eine Beendigung meldet und dann der Prozess noch läuft wär da was sehr suspekt. Dass der Prozess nicht gekillt wird siehst du wahrscheinlich mit ps auf der Commandline - oder?
richtig, mit ps sieht man den process.das log interessiert mich auch, aber wie gesagt, bisher war da nie was zu sehen, auch bei anderen Usern, die den Fehler auf Github berichtet haben..
Wie wirkt sich die Situation aus User Sicht aus? Gibts dann keine Updates mehr? Fehler im Log (a la already running) gibts ja anscheinend nicht.
genau, keine Errors, es gibt einfach keine Updates mehr.. bis man das merkt, sind meist ein paar Tage rum..
-
@ilovegym
nochmal kurz eine Frage, sieht so aus, als würde der Nachfolger des Pro-Models nun FoxPressure heißen, sieht auch etwas anders aus.
Würdest du davon ausgehen, dass es trotzdem ohne Probleme funktioniert ?
Und dann gibt es die Geräte ja in ganz vielen Shops bzw. von Firmen, die ja auch Öl ausliefern.
Gibt es da einen Zusammenhang oder ist das völlig egal wo man den kauft ?
z.B. BayWa schreibt, an soll prüfen ob man im Liefergebiet ist, damit man den Funktionsumfang entsprechend nutzen kann.
Ich möchte ja nur den Füllstand aber keine Bestellung auslösen. Ist das unabhängig voneinander, bzw. ist es komplett egal wo ich das Gerät kaufe ?Vielen Dank.
-
den Nachfolger kenne ich nicht, naja, wenn die es anbieten, sollte man schon davon ausgehen, dass es funktioniert, ansonsten schickste das Ding halt wieder zurueck, innerhalb 14 Tagen bei Kauf im Internet ist das ja kein Problem, nennt sich Widerruf, siehe AGB.
Wenn du den im Laden kaufst, gibts kein Rueckgaberecht.Ansonsten gibts ja auch ne Gewaehrleistung und Garantie, solange du in der EU lebst.
Nee, bei mir gabs da keinen Zusammenhang, natuerlich kannste mit nem Haendler n Vertrag machen, dass er automatisch bei einem Stand von X dir n Angebot schickt und ihm Zugriff auf den Account geben.. mach ich nicht..
-
@ilovegym said in Oilfox Adapter keine Funktion mehr?:
den Nachfolger kenne ich nicht, naja, wenn die es anbieten, sollte man schon davon ausgehen, dass es funktioniert, ansonsten schickste das Ding halt wieder zurueck, innerhalb 14 Tagen bei Kauf im Internet ist das ja kein Problem, nennt sich Widerruf, siehe AGB.
Wenn du den im Laden kaufst, gibts kein Rueckgaberecht.Ansonsten gibts ja auch ne Gewaehrleistung und Garantie, solange du in der EU lebst.
Nee, bei mir gabs da keinen Zusammenhang, natuerlich kannste mit nem Haendler n Vertrag machen, dass er automatisch bei einem Stand von X dir n Angebot schickt und ihm Zugriff auf den Account geben.. mach ich nicht..
Die ideale Lösung wäre wahrscheinlich die komplette Inbetriebnahme inkl. iobroker und die Sonde erst dann in den Öltank abtauchen zu lassen
Sonst wird die Retoure schwierig.
Vielen Dank für deine Hilfe ! -
Das Teil misst per Ultraschall, da taucht nix ein..
-
@ilovegym said in Oilfox Adapter keine Funktion mehr?:
Das Teil misst per Ultraschall, da taucht nix ein..
Das Pro- bzw. Pressure-Model schon, hier ist eine Sonde, die den Füllstand per Druck misst, diese wird an einem langen Kabel in den Tank gelassen. Die anderen Modelle würden bei mir wohl nicht funktionieren, ich habe einen Erd-Tank mit einem ein Meter langen Einfüllstutzen, das ist für die Ultraschallvariante zu lang.
-
ah, da glaenze ich mit beispielloser Ahnungslosigkeit..
- wieder was gelernt.. @mcm57
gestern wieder ein Haenger, diesmal hab ich's aber.. der Process holt das erste mal die Daten, und beendet sich, alles gut.. aber ne Minute spaeter startet der Adapter nochmal und bleibt dann beim einloggen haengen...
Habs auf Git dokumentiert:
https://github.com/iobroker-community-adapters/ioBroker.oilfox/issues/122closed Process occasionally stuck - still occuring #122
