Test js-controller v2.0.x (GitHub)
-
@darkiop Vielen Dank, also nehmen wir die 2.0.33 als nächste Latest Version.
Ich denke mal: Jemand der einen Tag kein ioBroker hat (und das Log ist ja nur einmalig so voll, dann sind es die 20-30 Teilen alle 30Sekunden ... Aber ja ... mal schauen
-
@MathiasJ Ich nutze diesen Thread für Beta Versionen, die - wie korrekt erwähnt - per GitHub direkt installiert werden. Auch nach dem Release der 2.0.25 gab es noch fixes die zur 2.0.29 geführt haben und jetzt als nächstes kommt die 2.0.33 auf NPM ... Alle Versionen dzwischen waren Betas die hier gecheckt wurden.
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
Vielen Dank, also nehmen wir die 2.0.33 als nächste Latest Version.
Keine Ursache!
-
Guten Abend zusammen,
habe soeben meine Slave von 2.0.25 auf 2.0.33 gebracht.
Folgendes habe ich im Terminal entdecken können.
make: *** [Release/obj.target/epoll/src/epoll.o] Fehler 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/usr/lib/node_modules/npm/node_module s/node-gyp/lib/build.js:196:23) gyp ERR! stack at ChildProcess.emit (events.js:198:13) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_proces s.js:248:12) gyp ERR! System Linux 4.19.66-v7+ gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gy p/bin/node-gyp.js" "rebuild" gyp ERR! cwd /opt/iobroker/node_modules/rpi-gpio/node_modules/epoll gyp ERR! node -v v10.16.3 gyp ERR! node-gyp -v v5.0.3 gyp ERR! not ok ../src/unix_dgram.cc: In function ‘void {anonymous}::OnRecv({anonymous}::SocketC ontext*)’: ../src/unix_dgram.cc:121:25: warning: ‘v8::Local<v8::Value> Nan::MakeCallback(v8 ::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’ is de precated [-Wdeprecated-declarations]anbei das log-file.
iobroker.2019-10-16.log
syslog
Das Update habe ich gegen 22.30 Uhr gemacht. -
@e-i-k-e Die üblichen unix-dgram Compile Fehler ... Tut alles?
-
Bis jetzt läuft alles.
Bei diesem Slave hatte ich auch schon des öfters Probleme mit dem rpi-Adapter. Ist dies ein Indiz dafür?
Komplette System soeben auf 2.0.33 redis/redis. Soll noch etwas bestimmtest getestet werden?
-
@e-i-k-e Ja doch epoll ist glaube was was der rpi braucht.
Ansonsten nichts besonderes mehr zu testen
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
Ansonsten nichts besonderes mehr zu testen
Läuft wie geschmiert die 2.0.33
-
Und weils so schön ist 2.0.34 auf GitHub
Die 2.0.33 hatte ein Problem "custom" state Settings (History und so) bei nutzung von "file" für Objekte wieder zu deaktivieren
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
Die 2.0.33 hatte ein Problem "custom" state Settings (History und so) bei nutzung von "file" für Objekte wieder zu deaktivieren
Alla Hopp, dann werf ich mal die Skripte zum Updaten an
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
Und weils so schön ist 2.0.34 auf GitHub
Die 2.0.33 hatte ein Problem "custom" state Settings (History und so) bei nutzung von "file" für Objekte wieder zu deaktivieren
Host "Medion(Test)" is up to date ?
Edit:
Dauerte ein wenig. -
hi, hab immer mal wieder nen System Restart. Bemerke ich nur wegen der Telegramm Meldung & iobroker started telegramm. Hier der log dazu..
Alle Versionen latest und Aktuell...Jemand ne idee
-
@smartboart ENODEV heisst Error NO DEVice und das ganze auf Netzwerkebene ... Was ist das für ein System? Scheinbar war Netzwerk-Device weg? Netzteil ausreichend dimensioniert?
-
@apollon77 Ist ein Multihostsystem mit Redis auf dem Master. file und states. Beide SBC haengen jeweils mittels netzwerkkabel an jeweils 1GB Anschluß des selben Router.
Versorgt werden beide SBC als auch die Fritte ueber eine DC Ups 12v 5A .
Die SBC bekommen davon jeweils mittels 12V auf 5V 3A Umsetzer ihre 5 V.
Spannung wuerde ich ausschliessen. Die DC Ups hat bei angehängter Last eine Autonomie von 30min. Hardware SBC siehe unten. Auslastung > noch Luft nach oben... -
@smartboart Naja ... angenommen allein ein Raspi braucht ggf bis zu 2+A und du hast 3 solche Geräte an 5A hängen ... Ich weiss das ein Raspi in Unterversorgungs-Situationen Chips abschaltet die u.a. Ethernet, WLAN und USB bereistetllen weil ich nicht wie das bei anderen geräten ist.
Schau mal in /var/log/syslog ob zu den Zeitpunkten da was zu sehen ist bitte
-
@apollon77 Nur 2 Geraete mit 5V 3A...entspricht 30W. Ups mit 12V 5A entspricht 60Watt. Glaube nicht dass die Fritte mehr wie 30 Watt zieht.. Ausserdem wuerde das die Ups melden / Ueberlast...Den Tipp werde ich trotzdem Beherzigen und mal ein Messgeraet dran haengen. Den Syslog schaue ich mir an...
-
@smartboart Sagen wir es so: Ich hab schon viele komische Dinge erlebt die nach Tausch oder "upgrade" eines Netzteils plötzlich weg waren
Und vor allem komische Effekte wie "netzwerk plötzlich weg" hatten wir zumindestens bei Systemen wir Raspis nicht nur einmal. Teilweise sind es Lastspitzen die plötzlich auftreten why ever ... Aber /var/log/syslog sollte sowas zeigen -
@apollon77
Im Raspy Slave ist um die Uhrzeit kein Eintrag gemacht worden. Im Master startet diese genau mit dem neustart...schaue gerade nur über vpn mit handy (nano /var/log/syslog) wenn ich zu hause bin lade ich die datei mal hoch... -
@apollon77
so hier der syslog..hier mal ein Auszug..Tauchen Sachen mit Spannungswerten auf...kann es aber nicht wirklich deuten. Google spuckt jede Menge dieser Einträge im Zusammenhang mit dem Rock64 aus.
Oct 18 14:16:35 localhost kernel: [ 1.495918] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree
Oct 18 14:16:35 localhost armbian-ramlog[613]: debug
Oct 18 14:16:35 localhost kernel: [ 1.495942] vcc_sd: unable to resolve supply
Oct 18 14:16:35 localhost kernel: [ 1.495958] vcc_sd: 3300 mV
Oct 18 14:16:35 localhost kernel: [ 1.496208] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree
Oct 18 14:16:35 localhost kernel: [ 1.496233] vcc_sd: regulator get failed, ret=-517
Oct 18 14:16:35 localhost armbian-ramlog[613]: dpkg.log
Oct 18 14:16:35 localhost kernel: [ 1.496250] reg-fixed-voltage sdmmc-regulator: -
@smartboart ohne da jetzt mega tief rein zu schauen klinge das doch mal interessant das irgendwas mit power war und damit kann es exakt das sein das die Netzwerk Hardware mal kurz weg war.
