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

[Fabian1]

@ahnungsbefreit ja das meine ich ja! Das ist etwas unglücklich, da der Admin5 voraussetzung für den Javascript Adapter ist, der 100%ig mit dem js-controller 3.3 funktioniert. Also alle die im Moment auf stable sind, kriegen unter umständen Probleme mit ihren skripten. Aber wie apollon geschrieben hat, ändert sich das ja heute abend.

[Jan1]

@pete0815
Hatte sich eben so angehört, das Du ein Restor des IOBroker als was "Großes" empfindest, deshalb auch mein Text dazu.
Ich hatte im Beta auch schon das ein oder andere Mal den Weg über das Kommando gewählt, weil es wenn sonst wirklich alles sauber ist, eben doch wesentlich schneller geht und ausreichend ist um die alte Version wieder herzustellen.

[bb61]

Hi,
gestern Abend von JS-controller 3.2.16 auf 3.3.15 geupdated:

Kurzfassung:
Fehler: KEIN JS-Script mehr in Script-Anzeige bzw. startend / arbeitend, obwohl offenbar alle noch vorhanden!

Dabei keine Fehlermeldung bei Update oder (diesbzgl.) im Betrieb!

Details:
Brav wie in Anleitung beschrieben:

• erst Master, dann die Slaves (1 Host-Master, insg. 8 Slaves, alle Raspi 4b bzw. 3b oder 3, bevor sich wer wundert: ist inkl. Remote angebundene Pflegewohnung der Eltern, lastverteilt wg. Wichtigkeit);
• Alle vorher auf aktuellem Stand gebracht bzgl. Adapter-Updates etc.
• alle Slaves nacheinander durchlaufen lassen, danach sogar erst einzelnes Reboot, bevor nächster dran war
• alles ohne Fehlermeldungen durchgelaufen, sauber wieder gestartet
• und bis auf diverse Wertebereichs- oder -typ-Meldungen auch alles fehlerfrei laufend

ABER nun:

• KEIN JS-Script wird mehr angezeigt unter "Scripts"
• und offenbar auch keins ausgeführt!

Neustart (Adapter, Javascript-Adapter tragende Slaves, Host-Master) bringt nichts,
keine Fehlermeldungen dazu im Log
im Gegenteil:

• Es werden bei Adapter-Neustart alle Script-Verzeichnisse korrekt als "registrierend" aufgelistet,

• unter "Objekte" / "Javascript.n" liegen die Scripts alle noch unverändert da, ebenso auf dem externen Spiegel-Pfad (natürlich nicht auf Raspi-SD-Karte, sondern seit Jahren stabil auf gemountetem dafür exclusivem SSD-Drive im QNAP-NAS)

• Alles funktioniert ansonsten problemlos und performant, auch übergreifend (Alexa-Befehle per IOT-Adapter, Steuerung per Szenen etc.),

nur starten / erscheinen im Editor absolut KEINE SCRIPTS !!:

• weder event-getriggert,
• noch scheduled

Konfiguration:

• REDIS-DB
  auf exclusiver externer USB-SSD-Platte am HOST-Master (Raspi 4b / 8GB RAM), bisher noch nicht verteilt als 3-Disk-REDIS-Cluster
• Javascript.0 (PROD) und .1 (DEV),
  auf je einem Raspi4B/8GB, (zzgl. je einer rpi2-Instanz zur Raspi-Eigenüberwachung) exclusiv laufend
• Script-File-Spiegel für beide Instanzen über Javascript.0

HOST-Master:

• Node.js: v12.21.0
• NPM: 6.14.11

Slave 6 (javascript.1) und Slave 7 (javascript.0):

• Node.js: v12.20.1
• NPM: 6.14.10

---

Woran kann das liegen?

• ich habe KEINE JS-Instanz auf dem HOST-Master! Der hat wichtigeres zu tun: Alle Infos, Geräte und REDIS koordinieren! (Backitup meckert darüber zwar beim Konfigurieren der JS-Sicherung "keine JS-Instanz auf HOST (er kann ja nur auf Master intalliert werden), tut's dann aber doch.)

• Ich habe noch nicht versucht, die Scripts neu einzuspielen. Sie sind ja (eigentlich) noch da..... Es erscheint eher, als wenn da wo ein "enabled" für die (sauber gün erscheinende) JS-Instanzen aus ist, finde aber nix dazu

• keinen Bock / Zeit, schon wieder alles neu aufzusetzen! Noch etwas gefrustet von letztem Raspi-(3 -> 4) Transfer, als kein Einspielen einer Sicherung / auch nicht gespeicherte JS ging, sondern alle gut 100 Skripts brav neu einzeln aus dem alten Spiegel per copy/paste neu angelegt werden mussten.... Wochen knapper Zeit für Weiterentwicklung / Veröffentlichung hier verloren! Nun schon wieder???? grrrrrr.....

---

Nebenkriegsschauplätze

hier noch der Vollständigkeit halber einige andere Fehler (Werte-max- oder Typ-Fehler):

• HM-RPC: HM-IP-Heizungsthermostaten (HmIP-eTRV-2) Level Ventilöffnung max = 1.01, aber real Integer-Prozentwert (0..100) kommend
• HM-RPC: Cux / bei allem enocean-Devices (bei mir alle Hoppe-Fenstergriffe bzw. Solar-Magnetkontakte an Velux-Fenstern): max-Wert bei Chn 0: RSSI_PEER auf 0, ankommende Werte aber Integer > 0, der Min-Wert steht auf negativ (-255), offenbar missinterpretierter Wertebereich?
  Update: Betrifft NICHT auch alle FS-20- oder HMS-100-Funk-Devices per Cux, da kommen RSSI-PEER-Werte wirklich negativ, max=0 rein!
• Netatmo / alle Wetterstations-Geräte: ....LastUpdate" has to be type "datetime" but received type "string"
• Roomba: refreshedTimestamp" has to be type "string" but received type "number"
  dto bei: commands.last.timestamp und states.signal,
• Luftdaten: location.longitude" has to be type "number" but received type "string"
  dto bei location.latitude und location.altitude

[Fabian1]

@bb61 Welche Version des Javascript Adapters und welche Admin version. Ich würde an deiner Stelle mal kurz auf beta umstellen und auf Admin5 und danach den javascript Adapter auf 5.2.8 updaten. Beides kommt heute abend sowieso ins stable.

[bb61]

@fabian1
wurden beide gestern abend noch VORHER aktuell (stable) gemacht, so nicht schon längst passiert:

Admin: 4.2.2 (HOST-Master als auch Slaves mit JS-Instanz)
JS: 5.1.3

[bb61]

wg. Beta benutzen:
ähm..... wenn ich Zeit dafür hätte, gerne. Aber es geht hier um ausgefallene Benachrichtigung bei Vitalüberwachung und Notfall. Ich darf mich jetzt ins Auto setzen und 250km entfernt klassische Technik wieder hochfahren und Pflegedienst "uminformieren".

Danach sicher nicht noch mehr "rumexperimentieren" werde. Das ging monatelang gut und sehr stabil! Wenn, dann maximal Rück-Downgrade auf alten Stand wie von Apollon oben beschrieben, das aber auch nicht vor Ende nächster Woche (ab mo auf Dienstreise....) Wenn, dann passt sowas natürlich BESTENS! :-(((

[bb61]

...und ganz sicher nicht noch ne weitere Baustelle an weiterer Kernkomponente aufmachen werde. Bei uns in der Firma wäre so etwas .... naja derjenige nicht mehr lange da.

Ich wollte nur fix das Problem loswerden und WARNEN was da an sauberen Systemen passiert!

Mitarbeit / eigene weitere Recherche und Versuche gerne, aber erst wenn ich wieder da bin. Real Live hat Prio!

[Jan1]

@bb61
Hast kein Backup vorher gemacht?
Wenn ein Backup vorhanden, sollte das Problem sehr schnell wieder vergessen sein.

[bb61]

selbstverständlich Backup gemacht.
Aber um 22:30 erstmal abgebrochen (weil eh nix mehr sehen konnte) und heute morgen ARBEITEN musste. Dann erst mal hier gelesen (man hofft ja auf triviale Lösung), und euch sofort informiert über Problem. Einspielen ist auf 9 Raspi nicht in wenigen Sekunden getan, noch dazu bei ungewissem Ausgang. Dafür jetzt keine Zeit und Gelegenheit mehr habe, gleich vom Büro aus fahren muss, wenn ich Pflegedienst noch erreichen will. Es ist Freitag...

[Wildbill]

@jan1 Backup hin oder her. Eines ist richtig: Wenn man für ein Produktivsystem stable benutzt, wie es auch empfohlen wird, so sollte bei einem Update danach alles laufen. Auch ich finde es mehr als merkwürdig, dass man nun quasi gezwungen wäre, den Admin und Javascript auf beta zu ziehen, nur damit das stable-Update des JS-Controller keine Probleme macht. Andersrum wäre die Update-Reihenfolge iMHO korrekter gewesen.
Gruß, Jürgen

[Jan1]

@bb61
Ok, hört sich nach Stress an. Viel Erfolg und trotzdem ein schönes WE.
Wobei die Backups installieren sich ja quasi von alleine, wenn der Restor mal gestartet ist, ob danach der ganze Master/Slave Kram richtig läuft ist was anderes.

[Homoran]

@jan1 sagte in js-controller 3.3 jetzt im STABLE!:

ob danach der ganze Master/Slave Kram richtig läuft ist was anderes.

hat er bei mir immer, da die Slave Daten mit drauf sind und vom Master verteilt werden (richtige Multihost-Installation vorausgesetzt!)

[bb61]

@Jan1
dafür müßte ich vor Ort an der Anlage sein (auch 8km weg vom Büro + Feierabendverkehr in Gegenrichtung).

Danke für die Wünsche! Euch auch ein schönes WE. Ich muss nun los, vielleicht in der Nacht mal Gelegenheit habe wieder hier wenigstens zu lesen....

[Ein ehemaliger Benutzer]

@bb61 said in js-controller 3.3 jetzt im STABLE!:

Ich wollte nur fix das Problem loswerden und WARNEN was da an sauberen Systemen passiert!

Danke! Wie auch von @Fabian1 beschrieben erledigt sich die Kategorie bzw. dieses aktuelle Mischkonstrukt eh heute Abend. Das hätte aber so bei mir voll zu geschlagen und ich warte so lieber noch einen Moment ab.

Das geschilderte Verständnis was Stable bedeutet bzw. ich darunter erwarte, kann ich durchaus nachvollziehen, will aber da Freeware nicht weiter ausführen (Kann nicht Goldstandard erwarten, aber nix dafür zahlen. Wobei das auch nur die halbe Wahrheit ist. Alleine aus Respekt vor Eurer Arbeit sollte man vernünftig damit umgehen, finde ich) und ich bin froh bzw. bleibe hauptsächlich bei stable, da ich nicht erfahren genug bin um beta zu handeln (jedenfalls das was ich unter beta erwarte). Will damit auch sagen, dass zwischen Stable und Beta ein anderer Nutzerkreis auf die Software trifft.

Edit: Um wieder positiv abzuschließen. Im Info Adapter wird eindeutig beschrieben/darauf hingewiesen, man soll hier im Forum/Beitrag nachlesen bevor man auf js 3.3 updatet. Somit ist man gewarnt solange man lesen kann.

[Homoran]

@bb61 sagte in js-controller 3.3 jetzt im STABLE!:

dafür müßte ich vor Ort an der Anlage sein

Nur zum Verständnis:
für das Upgrade des Controllers warst du auch vor Ort?

Das Downgrade läuft ja im Prinzip den gleichen Weg

[NathanDrake]

Vielen Dank für die neue Version!
Von STABLE kann da wohl nicht wirklich die Rede sein? Zum Glück habe ich das hier alles noch gelesen und lasse die Finger davon, da ich mir sicherlich nicht das WE versauen möchte.
Ich würde mir wirklich wünschen, wenn der ioBroker mal zu einem System heranwächst, welches sich einfach updaten lässt ohne sich stundenlang damit zu beschäftigen welche sonstigen Versionen vorher upgedatet werden müssen oder wo NPM, Node.js hochgezogen werden müssen etc.. Hört alles sehr nach Bastelkram an. Wirklich anwenderfreundlich ist das ganze auf jeden Fall nicht. Oder soll ioBroker nur für IT-Nerds sein?
Entschuldigung für die Kritik, aber das musste mal raus. Aus dem Blickwinkel eines normalen ioBroker Anwenders!

[Homoran]

@nathandrake sagte in js-controller 3.3 jetzt im STABLE!:

Von STABLE kann da wohl nicht wirklich die Rede sein?

wie kommst du darauf?
der js-controller 3.3 läuft stabil

[NathanDrake]

@homoran Das stimmt wahrscheinlich. Aber ioBroker läuft nicht stabil damit. Da es einfach zu viele Abhängigkeiten gibt. Eben der Nachteil von einem modularen System.

[Kasi-m3]

Tesla Adapter ==> kein Token mehr!

Bisher habe ich noch nichts über den Tesla Adapter gelesen. Ich habe seit dem Update das Problem, dass der Tesla Adapter nicht mehr läuft. Da mein Token noch gültig war, der Adapter aber nicht mehr mit meinem Auto kommuniziert hat, habe ich versucht, einen neuen Token zu erstellen. Das hat nicht geklappt: "no response"!
Ich habe jetzt alles durchprobiert. Adapter-Instanz neu installiert, mit und ohne 2FA, 24h abwarten....... Jetzt weiß ich nicht mehr weiter, immer ERROR "no response".

Also, Tesla-Adapter geht bei mir nicht mehr! Tipps?

ioBroker (Node 12.22.4, NPM 6.14.14, js-controller 3.3) auf NUC in Proxmox Ubuntu-VM 20.04.2

[Wildbill]

@homoran Ich denke, er meint das, was ich oben auch schon geschrieben hatte: Dass man bei einem stable-Update des JS-Controller nicht plötzlich beta-Updates anderer Adapter einspielen müssen sollte, um ein insgesamt stabiles System zu haben. Und dazu zählen für mich auch warnings oder errors im Log, auch wenn augenscheinlich alles laufen zu scheint (wobei es das ohne manuelles Eingreifen an bestimmten Punkten auch nicht so war).

Aber ja, irgendwann war der Zeitpunkt für das umfangreiche Update erreicht und in einem halben Jahr hat sich auch der letzte wieder beruhigt.
Deshalb auch von mir Danke und großen Respekt an alle Beteiligten. Für ein kostenloses (oder allenfalls mal mit Spenden von mir und anderen bedachtes) System große Klasse.

Gruß, Jürgen