NEWS
Test js-controller v2.0.x (GitHub)
-
Also, hier mal ein kleiner Zwischenstand:
Ich habe den iobroker-hwr neu aufgesetzt - mit dem aktuellen Rasbian lite + Node 10 + iobroker 2.0.22.
Und, du wirst es nicht glauben, das IPv4/Reconnect Thema scheint hier erledigt zu sein ... also liegt die Vermutung nahe das es an Diet Pi lag ... Habe nun mehrmals schon den Master abgewürgt, und jedes mal nachdem er wieder hochgefahren war, war auch der Slave wieder verbunden.
Der automatische Restart unter systemd auf dem RPI funktioniert ebenfalls.
Werd das jetzt mal so über Nacht laufen lassen und Morgen dann nochmal den Skript Export testen (aktuell kommt da immer noch der Hinweis auch auf die fehlende Package.zip).
-
@Stabilostick Ich frage mich aber gerade was hier seitens Diet Pi eingespart wurde damit es zu diesem Verhalten gekommen ist. Immerhin bleibt die Erfahrung :)
@darkiop
OT: Du warst der Auslöser :grinning: -> https://forum.iobroker.net/post/307432 -
@darkiop Cooooool, wieder ein Thema was sich "von selbst erledigt" ;-)
Ok, das was ich gefixt habe waren ungültige Downloads (also ZIP Files die keine waren).
Das es gar nicht ging hatte ich nicht@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
Cooooool, wieder ein Thema was sich "von selbst erledigt"
Ja, wobei hier immerhin die Erkenntnis mit IPv6 herauskam ... :)
Ok, das was ich gefixt habe waren ungültige Downloads (also ZIP Files die keine waren).
Das es gar nicht ging hatte ich nichtDas schau ich mir heut nochmal mit 1.5 - dazu bin ich gestern leider nicht mehr gekommen.
Blöderweise sind mir heute Nacht auch sämtliche ioboker Container stecken geblieben (um 23 Uhr liefen sie noch :)) - d.h. meine Beobachtung über Nacht muss ich auf Morgen schieben.
Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
@darkiop sagte in [Aufruf] js-controller 2.0 Beta Test:
Das schau ich mir heut nochmal mit 1.5 - dazu bin ich gestern leider nicht mehr gekommen.
Unter 1.5 passiert einfach mal gar nichts .... keine Meldung über eine fehlende Package.zip, keine Logs ... :)
Also ich würde mal behaupten der Fehler liegt hier nicht bei der 2.0.x
Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
bei mir funktioniert der g-homa Adapter nicht mehr. Hat den jemand im Einsatz und hat Probleme seit js-controller 2.x?
Wenn ich anschalten will schaltet er gleich wieder aus. Dabei zappelt der VIS-Schalter (fancyswitch - Giva Labs iButton) paar mal hin- und her. Schaltbefehl über telegram geht auch nicht mehr und füht zum selben Problem. Ich habe auch dabei alle javascript Adapter ausgeschaltet um hier Fehler auszuschließen.
Log sagt:g-homa.0 2019-10-05 14:52:23.574 debug (3918) system.adapter.admin.1: logging true g-homa.0 2019-10-05 14:51:29.908 debug (3918) powerFactor in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:29.908 debug (3918) power in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:29.907 debug (3918) current in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:29.907 debug (3918) voltage in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:29.810 debug (3918) voltage != null: false g-homa.0 2019-10-05 14:51:29.810 debug (3918) power != null: false g-homa.0 2019-10-05 14:51:29.810 debug (3918) powerFactor != null: false g-homa.0 2019-10-05 14:51:29.810 debug (3918) current != null: false g-homa.0 2019-10-05 14:51:29.809 debug (3918) extendPlug: type = normal, energyMeasurement != null: true g-homa.0 2019-10-05 14:51:29.806 debug type: normal g-homa.0 2019-10-05 14:51:29.806 debug switched from: remote g-homa.0 2019-10-05 14:51:29.806 debug state: off g-homa.0 2019-10-05 14:51:29.806 debug (3918) Got updated info for Plug 4ce7ac: g-homa.0 2019-10-05 14:51:28.616 debug (3918) powerFactor in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:28.615 debug (3918) power in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:28.615 debug (3918) current in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:28.614 debug (3918) voltage in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:28.553 debug (3918) voltage != null: false g-homa.0 2019-10-05 14:51:28.553 debug (3918) power != null: false g-homa.0 2019-10-05 14:51:28.552 debug (3918) powerFactor != null: false g-homa.0 2019-10-05 14:51:28.552 debug (3918) current != null: false g-homa.0 2019-10-05 14:51:28.552 debug (3918) extendPlug: type = normal, energyMeasurement != null: true g-homa.0 2019-10-05 14:51:28.549 debug type: normal g-homa.0 2019-10-05 14:51:28.549 debug switched from: remote g-homa.0 2019-10-05 14:51:28.549 debug state: off g-homa.0 2019-10-05 14:51:28.549 debug (3918) Got updated info for Plug 4ce7ac: g-homa.0 2019-10-05 14:51:28.500 debug (3918) powerFactor in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:28.500 debug (3918) power in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:28.499 debug (3918) current in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:28.499 debug (3918) voltage in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:28.405 debug (3918) voltage != null: false g-homa.0 2019-10-05 14:51:28.404 debug (3918) power != null: false g-homa.0 2019-10-05 14:51:28.404 debug (3918) powerFactor != null: false g-homa.0 2019-10-05 14:51:28.404 debug (3918) current != null: false g-homa.0 2019-10-05 14:51:28.403 debug (3918) extendPlug: type = normal, energyMeasurement != null: true g-homa.0 2019-10-05 14:51:28.400 debug type: normal g-homa.0 2019-10-05 14:51:28.400 debug switched from: remote g-homa.0 2019-10-05 14:51:28.400 debug state: on g-homa.0 2019-10-05 14:51:28.400 debug (3918) Got updated info for Plug 4ce7ac: g-homa.0 2019-10-05 14:51:27.392 debug (3918) powerFactor in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:27.392 debug (3918) power in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:27.392 debug (3918) current in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:27.391 debug (3918) voltage in plug.energyMeasurement => false g-homa.0 2019-10-05 14:51:27.335 debug (3918) voltage != null: false g-homa.0 2019-10-05 14:51:27.335 debug (3918) power != null: false g-homa.0 2019-10-05 14:51:27.335 debug (3918) powerFactor != null: false g-homa.0 2019-10-05 14:51:27.335 debug (3918) current != null: false g-homa.0 2019-10-05 14:51:27.334 debug (3918) extendPlug: type = normal, energyMeasurement != null: true g-homa.0 2019-10-05 14:51:27.332 debug type: normal g-homa.0 2019-10-05 14:51:27.332 debug switched from: remote g-homa.0 2019-10-05 14:51:27.332 debug state: on g-homa.0 2019-10-05 14:51:27.332 debug (3918) Got updated info for Plug 4ce7ac: g-homa.0 2019-10-05 14:51:13.232 debug (3918) system.adapter.admin.1: logging false g-homa.0 2019-10-05 14:49:15.644 debug (3918) powerFactor in plug.energyMeasurement => false g-homa.0 2019-10-05 14:49:15.644 debug (3918) power in plug.energyMeasurement => false g-homa.0 2019-10-05 14:49:15.643 debug (3918) current in plug.energyMeasurement => false g-homa.0 2019-10-05 14:49:15.642 debug (3918) voltage in plug.energyMeasurement => false g-homa.0 2019-10-05 14:49:15.519 debug (3918) voltage != null: false g-homa.0 2019-10-05 14:49:15.519 debug (3918) power != null: false g-homa.0 2019-10-05 14:49:15.519 debug (3918) powerFactor != null: false g-homa.0 2019-10-05 14:49:15.518 debug (3918) current != null: false g-homa.0 2019-10-05 14:49:15.518 debug (3918) extendPlug: type = normal, energyMeasurement != null: true g-homa.0 2019-10-05 14:49:15.516 debug type: normal g-homa.0 2019-10-05 14:49:15.516 debug switched from: remote g-homa.0 2019-10-05 14:49:15.516 debug state: off g-homa.0 2019-10-05 14:49:15.516 debug (3918) Got updated info for Plug 4ce7ac: g-homa.0 2019-10-05 14:49:14.392 debug (3918) powerFactor in plug.energyMeasurement => false g-homa.0 2019-10-05 14:49:14.392 debug (3918) power in plug.energyMeasurement => false g-homa.0 2019-10-05 14:49:14.392 debug (3918) current in plug.energyMeasurement => false g-homa.0 2019-10-05 14:49:14.391 debug (3918) voltage in plug.energyMeasurement => false g-homa.0 2019-10-05 14:49:14.294 debug (3918) voltage != null: false g-homa.0 2019-10-05 14:49:14.293 debug (3918) power != null: false g-homa.0 2019-10-05 14:49:14.293 debug (3918) powerFactor != null: false g-homa.0 2019-10-05 14:49:14.292 debug (3918) current != null: false g-homa.0 2019-10-05 14:49:14.292 debug (3918) extendPlug: type = normal, energyMeasurement != null: true g-homa.0 2019-10-05 14:49:14.289 debug type: normal g-homa.0 2019-10-05 14:49:14.289 debug switched from: remote g-homa.0 2019-10-05 14:49:14.289 debug state: off g-homa.0 2019-10-05 14:49:14.289 debug (3918) Got updated info for Plug 4ce7ac:@lobomau sagte in [Aufruf] js-controller 2.0 Beta Test:
Hat den jemand im Einsatz und hat Probleme seit js-controller 2.x?
Habs gerade nochmal bei mir probiert. Keine Probleme. Wüsste auch nicht, was Controller 2.0 damit zu tun haben könnte.
Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
Cooooool, wieder ein Thema was sich "von selbst erledigt"
Ja, wobei hier immerhin die Erkenntnis mit IPv6 herauskam ... :)
Ok, das was ich gefixt habe waren ungültige Downloads (also ZIP Files die keine waren).
Das es gar nicht ging hatte ich nichtDas schau ich mir heut nochmal mit 1.5 - dazu bin ich gestern leider nicht mehr gekommen.
Blöderweise sind mir heute Nacht auch sämtliche ioboker Container stecken geblieben (um 23 Uhr liefen sie noch :)) - d.h. meine Beobachtung über Nacht muss ich auf Morgen schieben.
-
@darkiop sagte in [Aufruf] js-controller 2.0 Beta Test:
Das schau ich mir heut nochmal mit 1.5 - dazu bin ich gestern leider nicht mehr gekommen.
Unter 1.5 passiert einfach mal gar nichts .... keine Meldung über eine fehlende Package.zip, keine Logs ... :)
Also ich würde mal behaupten der Fehler liegt hier nicht bei der 2.0.x
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
und was war der Grund ?
Wofür? Für den Container Crash? Da verdächtige ich das automatische Docker Image Update mit containrrr/watchtower.
dann ist das irgendwas generelleres. Kann es was mit Master/Slave zu tun haben? Wo läuft JavaScript Adapter? Master oder Slave?
Ich habe da aktuell 3 Laufen - alle auf dem Master (1 = Produktive Skripte, 2 = Test, 3 = noch ein Relikt von dem Log-Skript, das könnte mal auf 1 geschoben werden).
Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
und was war der Grund ?
Wofür? Für den Container Crash? Da verdächtige ich das automatische Docker Image Update mit containrrr/watchtower.
dann ist das irgendwas generelleres. Kann es was mit Master/Slave zu tun haben? Wo läuft JavaScript Adapter? Master oder Slave?
Ich habe da aktuell 3 Laufen - alle auf dem Master (1 = Produktive Skripte, 2 = Test, 3 = noch ein Relikt von dem Log-Skript, das könnte mal auf 1 geschoben werden).
-
@darkiop Ok, Ansonsten: Wenn init.d dann schau mal ob in /opt/iobroker/node_modules/iobroker.js-controller/lib ein iobroker.pid File liegt wenn der sauber gestartet wurde und läuft. Wenn ja sollte das restart eigentlich tun. Wenn nein ist da was komisch
Gerne, melde mich heut Nachmittag. Habe durch das Testing die letzten Tage auch einiges dazugelernt - wieso also jetzt aufhören? :D
Oben hattest du mal auf einen anderen Beitrag geschrieben:
Alternativ leg doch mal ein Subscribe im Javascript adapter auf den relevanten State und logge alle Änderungen mit state.val, state.ack und state.from Vllt wird man daraus schlauer
War damit gemeint ein Skript anzulegen welches die States überwacht oder gibt es irgendwo ne Subscribe Funktion die ich bisher übersehen habe?Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
Gerne, melde mich heut Nachmittag. Habe durch das Testing die letzten Tage auch einiges dazugelernt - wieso also jetzt aufhören? :D
Oben hattest du mal auf einen anderen Beitrag geschrieben:
Alternativ leg doch mal ein Subscribe im Javascript adapter auf den relevanten State und logge alle Änderungen mit state.val, state.ack und state.from Vllt wird man daraus schlauer
War damit gemeint ein Skript anzulegen welches die States überwacht oder gibt es irgendwo ne Subscribe Funktion die ich bisher übersehen habe?@darkiop sagte in [Aufruf] js-controller 2.0 Beta Test:
War damit gemeint ein Skript anzulegen welches die States überwacht oder gibt es irgendwo ne Subscribe Funktion die ich bisher übersehen habe?
Jupp ein skript und dann per "on('...state'..." auf änderungen anmelden und loggen
-
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Bringt es vielleicht etwas meine Flows zu sichern und Node-RED mal kpl. zu de-/neuinstallieren? Ev. hat es bei dem testen einfach nur bei mir was zerschossen...
versuch das mal.
Die Meldung zeigt das er versucht zum Port 1880 von node-red zu verbunden und der Server das ablehnt.
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Bringt es vielleicht etwas meine Flows zu sichern und Node-RED mal kpl. zu de-/neuinstallieren? Ev. hat es bei dem testen einfach nur bei mir was zerschossen...
versuch das mal.
Die Meldung zeigt das er versucht zum Port 1880 von node-red zu verbunden und der Server das ablehnt.
Zwar irgendwie gehofft, aber insgeheim befürchtet: kein Node-RED Dashboard :(
Hast du deine Tests mit file/file und npm 6.11.3 32Bit gefahren? Irgend etwas muss es ja sein, dass es nicht will...
Oder "Haken dran" und schauen ob es beim Release nur bei mir bleibt :)LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Bringt es vielleicht etwas meine Flows zu sichern und Node-RED mal kpl. zu de-/neuinstallieren? Ev. hat es bei dem testen einfach nur bei mir was zerschossen...
versuch das mal.
Die Meldung zeigt das er versucht zum Port 1880 von node-red zu verbunden und der Server das ablehnt.
Zwar irgendwie gehofft, aber insgeheim befürchtet: kein Node-RED Dashboard :(
Hast du deine Tests mit file/file und npm 6.11.3 32Bit gefahren? Irgend etwas muss es ja sein, dass es nicht will...
Oder "Haken dran" und schauen ob es beim Release nur bei mir bleibt :)Bitte benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Immer Daten sichern! -
@sigi234 Es geht um node-red Dashboard was nicht tut ... bei SBorg ;-) (sorry)
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@sigi234 Es geht um node-red Dashboard was nicht tut ... bei SBorg ;-) (sorry)
Ups, aber das geht auch.
-
:)
Bei mir ging es ja vorher auch noch... ;) -
No risk, ...
Node-RED :+1:
Dashboard :-1: (leider, leider...) -
In diesem Post werden wir FAQ-artig öfter vorgekommene Fragen, Antworten, Tips und Tricks sammeln ...
1. Wie lang soll der Beta-test laufen?
Wir peilen aktuell ca. 2 Wochen ür den Beta Test an und wollen Anfang Oktober den js-controller 2.0 gern im Latest Repository veröffentlichen.2. Ich bekomme nach dem Start von ioBroker einen Fehler im Log das pids.txt nicht geschrieben werden konnte. Was kann ich tun?
Der Fehler tritt auf wenn der Nutzer unter dem ioBroker gestartet wurde das genannte File nicht schreiben kann. Dies kann passieren wenn ioBroker aus Versehen als Root o.ä. gestartet wurde oder die Dateirechte dieser Datei verbogen sind. Die einfachste Abhilfe hier ist der Installation-Fixer (siehe oben im Text). Alternativ Bitte die Datei einfach löschen wenn ioBroker nicht läuft und dann sollte Sie beim nächsten Start korrekt angelegt werden.3. Ich habe trotz der Warnungen bei
iobroker setup customauf einem Slave auch Daten migriert und nun funktioniert nichts mehr. Was kann ich tun?
Bei der Migration wird ein Backup erstellt. Dieses ist auf der Master-Host imbackupsVerzeichnis gespeichert und hat am Ende des Namens "-migration" angehängt. Um den Datenstand von der Master-Migration wieder herzustellen muss dieses Backup mittelsiobroker restore <Filename>wieder eingespielt werden.
Danach alle Slave-Hosts umstellen und am Ende auf dem Master einiobroker upload allausführen.4. Wie muss ich ein Skript was bisher in iobroker-data/files direkt geschrieben hat umbauen?
Das Skript sollte die writeFile Methode nutzen. Details auch https://forum.iobroker.net/post/307537Seitdem ich den js.controller auf 2.0 geupdated habe, funktioniert mein Backitup Adapter völlig unkontrolliert mit folgenden Problemen.
1. Standard Backup:
Die Sicherung erfolgt nur mit der Zigbee Datenbank, alles andere fehlt.2. Komplett Backup:
Es wird ein Backup ZIP Datei erstellt und auf den NAS Server geschoben, aber im ioBroker nicht gelöscht.Wo liegt der Fehler?
Danke.
-
Seitdem ich den js.controller auf 2.0 geupdated habe, funktioniert mein Backitup Adapter völlig unkontrolliert mit folgenden Problemen.
1. Standard Backup:
Die Sicherung erfolgt nur mit der Zigbee Datenbank, alles andere fehlt.2. Komplett Backup:
Es wird ein Backup ZIP Datei erstellt und auf den NAS Server geschoben, aber im ioBroker nicht gelöscht.Wo liegt der Fehler?
Danke.
Support us
715
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge