js-controller 4.0 jetzt im BETA/LATEST!
-
@e-i-k-e Hat mit controller nix zu tun ... da sist wohl eher admin bzw das Javascriipt von Admin vs ein Admin restart
-
@gelberlemmy Ja log ist eindeutig. Auch um 20:30:42 wurde der Controller beendet. Frage ist nur warum ... wenn du es nicht warst dann schau mal ob in /var/log/syslog was dazu steht um diese Zeit, vllt ja RAM knapp?
Und im Rahmen dieses "alles beenden" hat das SHelly wieder zu lange gebraucht. Also hier bei den Adaptern die solche DB closed werfen schauen ob es neuere Versionen gibt und die ggf probieren - sonst Issues anlegen
-
@apollon77 ich habe gestern mein System geupdatet von 3.3.22 auf 4.0.15. Ich habe keine Probleme, scheint sogar etwas resourcenschonender zu sein.
Ein Problem habe ich: ein slave ist ein Pi1 und hier bekomme nich so einfach node 12 installiert. Noch scheint es ja zu funktionieren. Aber wie lange noch oder kann das jetzt schon zu Problemen führen?Hier sieht man wie beim slave Pi3 die CPU-Temperatur zurückgegangen ist durch das Update des js-controllers von 58°C auf 55°C (jeweils tiefste Temperatur)
Hosts:
-
@lobomau sagte in js-controller 4.0 jetzt im BETA/LATEST!:
Ein Problem habe ich: ein slave ist ein Pi1 und hier bekomme nich so einfach node 12 installiert.
was hast du da laufen ? 3 aktive instanzen ??
-
Beim P1 kannst du die unofficial Builds versuchen. Steht in meinem HowTo zu nodeJS als Sonderfall dabei. (Siehe meine Signatur)
-
@lobomau ioBrokerCT ist der Master, Pi3 und raspberrypi (Pi1) sind die slaves.
Edit: sorry... hatte es falsch verstanden... ja nur drei Instanzen auf dem Pi1.
-
@lobomau sagte in js-controller 4.0 jetzt im BETA/LATEST!:
ja nur drei Instanzen auf dem Pi1.
ja was ... was läuft da ????
-
@arteck hauptsächlich geht es mir da nur um den smartmeter (wo ich jetzt auch nicht weiter updaten kann wegen nodejs 10.x) am Stromkasten. Zusätzlich läuft da noch RPI-Monitor und web-speedy.
-
@lobomau na das ist schon mal ne Aussage..
den smartmeter kannst du per ser2net anbinden dann brauchst du keine iobroker da laufen
mach ich auch so.. für einen adapter lohnt das nicht.. vor allem wenn das Pi1 istweb-speedy kannst du auf den anderen host schieben
-
@arteck Offtopic hier
-
@apollon77 danke für Deine Mühe. Zu wenig RAM kann nicht sein. Meine Maschine hat 6 GB. Ich werde es weiter verfolgen. Aktuell läuft alles ohne Probleme. Keine Ahnung was mein IOBroker dort hatte. Ich werde weiter beobachten. Noch einmal herzlichen Dank !
-
@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:
@gelberlemmy Ja log ist eindeutig. Auch um 20:30:42 wurde der Controller beendet. Frage ist nur warum ... wenn du es nicht warst dann schau mal ob in /var/log/syslog was dazu steht um diese Zeit, vllt ja RAM knapp?
Und im Rahmen dieses "alles beenden" hat das SHelly wieder zu lange gebraucht. Also hier bei den Adaptern die solche DB closed werfen schauen ob es neuere Versionen gibt und die ggf probieren - sonst Issues anlegen
Wenn im Syslog auch der OOM Killer den js-controller beendet hat, könnte es ja ähnliche Ursachen wie bei meinen Auffälligkeiten sein. Dazu müsste @gelberlemmy ebenfalls mal den RAM und die in/out events vom js-controller loggen.
-
Also für inzwischen ca. 3.400 Installationen einer controller 4.x (davon 2.000 auf der letzten 4.0.15) ist es hier sehr ruhig geworden
Die Adapter Backitup, Node-Red und Admin sind inzwischen mit Ihren controller 4.0 optimierten Versionen auch im Stable Repository.
Wenn also hier keiner mit einem guten Argument dagegen kommt geht der 4.0.15 Controller heute Abend ins Stable ...
-
Wenn jemand der Anwesenden etwas gegen diese Veröffentlichung einzuwenden hat, möge er jetzt sprechen oder auf ewig schweigen.
-
@thomas-braun Jetzt hast du dich als "Standesbeamter" geoutet
-
@thomas-braun Also bei so ner Ansage schweige ich lieber
Gruß von meinem sehr ruhigen 4.0.15 Controller -
@apollon77
Kürzlich hatte ein anderer Entwickler in einem anderen Thread den 3.3.22 als "ALT" bezeichnet...
Scheint also soweit zu sein... -
@ofbeqnpolkkl6mby5e13 LOL ;-)) seems so
-
@thisoft sagte in js-controller 4.0 jetzt im BETA/LATEST!:
@apollon77 läuft soweit alles unauffällig
Leider muss ich meine o.g. Aussage revidieren. Ich habe einen Slave (RasPi) auf dem mir das Upgrade auf 4.0.14 offensichtlich den Serialport zerscherbelt haben muss. Sorry, dass ich das erst jetzt gemerkt habe - muss wohl am Alter liegen
Beim Versuch das Script zu starten erhalte ich:
script.js.Stable.DoorPiSeriell: TypeError: SerialPort is not a constructorZu sagen wäre noch dass auf einem anderen Slave-RasPi auf dem 2 Smartmeter-Adapter laufen der Fehler nicht auftritt - deshalb hab ich's eben auch nicht gleich gemerkt.
Ich hab jetzt auch schon versucht mittels Installation des Smartmeter-Adapters auf dem Problem-Slave den SerialPort wiederzubeleben - hat leider auch nicht funktioniert.Hier noch die Config des betreffenden Slave:
doorpi Plattform linux Betriebssystem linux Architektur arm CPUs 4 Geschwindigkeit 700 MHz Modell ARMv7 Processor rev 4 (v7l) RAM 872.67 MB System-Betriebszeit 10:21:09 Node.js v14.18.2 (Es gibt eine neuere Version: v14.19.0) time 1645960071825 timeOffset -60 Anzahl der Adapter 486 NPM v6.14.15 Datenträgergröße 14.54 GB freier Festplattenspeicher 10.29 GB Betriebszeit 10:21:07 Aktive Instanzen 1 location /opt/iobroker/ Hostname doorpiIch hoffe, es gibt noch Hilfe...
-
@thisoft Aaaalso, das hat nun mal gar nichts mit dem js-controller zu tun. Wenn Du nur "serialport" in der Javscript konfig angegeben hast dann installiert er die letzte version ... heisst durch den restart vom JS Adapter hast du jetzt ggf nicht mehr serialport 9 sondern serialport 10 drauf und da gab es (major update lässt grüßen) Breaking changes ... Du musst dein Javascript Skript anpassen. https://serialport.io/docs/guide-upgrade (aber Fragen dazu bitte in nem eigenen Thread. Alternativ nutze serialport@9.2.8 (glaube ich) als dep um zu downgraden beim nächsten Start
