UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Thomas Braun]

@lobomau

Beim P1 kannst du die unofficial Builds versuchen. Steht in meinem HowTo zu nodeJS als Sonderfall dabei. (Siehe meine Signatur)

[lobomau]

@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.

[arteck]

@lobomau sagte in js-controller 4.0 jetzt im BETA/LATEST!:

ja nur drei Instanzen auf dem Pi1.

ja was ... was läuft da ????

[lobomau]

@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.

[arteck]

@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 ist

web-speedy kannst du auf den anderen host schieben

[apollon77]

@arteck Offtopic hier :-)

[gelberlemmy]

@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 !

[Diginix]

@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.

[apollon77]

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 ...

[Thomas Braun]

@apollon77

Wenn jemand der Anwesenden etwas gegen diese Veröffentlichung einzuwenden hat, möge er jetzt sprechen oder auf ewig schweigen.

[Einstein67]

@thomas-braun Jetzt hast du dich als "Standesbeamter" geoutet ;)

[amg_666]

@thomas-braun Also bei so ner Ansage schweige ich lieber :-)
Gruß von meinem sehr ruhigen 4.0.15 Controller

[oFbEQnpoLKKl6mbY5e13]

@apollon77
Kürzlich hatte ein anderer Entwickler in einem anderen Thread den 3.3.22 als "ALT" bezeichnet...
Scheint also soweit zu sein...

[apollon77]

@ofbeqnpolkkl6mby5e13 LOL ;-)) seems so

[Thisoft]

@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 constructor

Zu 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
doorpi

Ich hoffe, es gibt noch Hilfe...

[apollon77]

@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

[Qlink]

@apollon77

Ich habe gerade mein iobroker System (Windows) erfolgreich (hoffe ich zumindest) auf den aktuellen js-controller hochgezogen.

Ich verwende dazu immer die Standard Methode:

vorher sauberer Reboot vom kompletten Server, dann Virenscanner deaktivieren und

ioBroker Konsole: iobroker stop
 iobroker update
 iobroker upgrade self
 iobroker start

In den letzten Jahren hat das bisher immer ohne Fehlermeldungen o.ä. funktioniert.
Heute hat er allerdings folgendes ausgespuckt:

C:\iobroker\iob01>iobroker upgrade self
Update js-controller from @3.3.15 to @4.0.15
NPM version: 6.14.16
npm install iobroker.js-controller@4.0.15 --loglevel error --unsafe-perm (System call)
Server Objects 127.0.0.1:50874 Error from InMemDB: Error: GET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets"]
Server States 127.0.0.1:50875 Error from InMemDB: Error: GET-UNSUPPORTED for namespace meta.: Data=["meta.states.protocolVersion"]
Server Objects 127.0.0.1:50874 Error from InMemDB: Error: GET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.protocolVersion"]
Server States 127.0.0.1:50876 Error from InMemDB: Error: PSUBSCRIBE-UNSUPPORTED for namespace meta.: Data=["meta.*"]
Server Objects 127.0.0.1:50874 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:50874 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:50874 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:50874 Error from InMemDB: Error: SET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets",{"type":"Buffer","data":[49]}]
Could not migrate objects to corresponding sets: Error SET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets",{"type":"Buffer","data":[49]}]
Server Cannot move C:\iobroker\iob01\iobroker-data\objects.json.new to C:\iobroker\iob01\iobroker-data\objects.json: ENOENT: no such file or directory, rename 'C:\iobroker\iob01\iobroker-data\objects.json.new' -> 'C:\iobroker\iob01\iobroker-data\objects.json'. Try direct write as fallback

Es scheint trotzdem alles normal zu laufen und er zeigt mir nun 4.0.15, soweit also erstmal alles gut.
Die oben beschriebene Modifikation vom systeminfo Adapter musste ich noch manuell durchführen, damit der auch wieder läuft. Das passt jetzt scheinbar soweit alles.

Meine Frage: Muss ich mir wegen den o.g. Meldungen Sorgen machen oder zukünftig irgendwelche Probleme erwarten ?
Woher kommt diese Meldung ?

Beste Grüße

[bahnuhr]

@qlink sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Muss ich mir wegen den o.g. Meldungen Sorgen machen

nachlesen unter #1

[Qlink]

@bahnuhr

ups, das hab ich überlesen ... Danke für den Hinweis. Dann ist ja alles gut :)

[bahnuhr]

@qlink sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Dann ist ja alles gut

genau