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

[apollon77]

@arteck Alle Fälle die ich bisher gesehen habe waren entweder:

• 1.5er Slave an 2.0er controller
• Adapzer-Zombie-Prozess vor Upgrade nicht beendet (damit 1.5er Adapter an 2.0er controller)
• Hängender iobroker Backup Prozess (damit 1.5er Backup an 2.0er controller).

Zu dem tankerkoenig habe ich ausser das es so war seitdem nichts mehr gehört und damit sage ich ehrlich: Wer mit beweist das mit einem Frisch gestarteten und sauber geupdatetem System (ggf wenn unsicher nochmal von npm drüber, "Iobroker version" ausgabe und so) es auftritt dann muss man reinschauen.

Ansonsten behaupte ich: Da läuft irgendwo noch ein 1.5er Prozess

[Linedancer]

Danke für den Schubs in die richtige Richtung. Hab den Netzwerk Stecker am Raspi gezogen und schon waren die Log Einträge weg obwohl der Raspi sagt "iobroker is not running". Dann werd ich dort mal den iobroker deinstallieren.
Ich hatte natürlich gelesen das bei Multihost der Slave zuerst aktualisiert werden soll, hab das aber ignoriert, da ich ja kein Multihost Betrieb mehr hatte.

Ansonsten kann ich auch hier nur nochmal Danke sagen für euren Einsatz nicht nur hier bei meinem Problem, sondern generell bei der ständigen Weiterentwicklung und Verbesserung.

[apollon77]

@Linedancer sagte in js-controller 2.0 ab sofort im Latest Repo:

obwohl der Raspi sagt "iobroker is not running"

Die Meldung besagt NICHT das kein Prozess löuft, sondern nur ob der ioBroker funktional ist (im Falle eines Slaves auch das er mit dem Master verbunden ist).

[Linedancer]

So, iobroker ist runter vom Raspi. Alles wieder OK und nebenbei hab ich wieder was gelernt. Hatte "iobroker is not running" immer anders interpretiert.

[MathiasJ]

Eine Frage am Rande:
Wie viele Slsve gehen eigentlich maximal beim Multihost-System?

[arteck]

@MathiasJ viele

[Ein ehemaliger Benutzer]

@arteck sagte in js-controller 2.0 ab sofort im Latest Repo:

@MathiasJ viele

im Chuck Norris Mode sogar alle

[MathiasJ]

Haha..... Bei der CCU gehen nur 3.....
deshalb die Frage, weil ich evtl ein paar machen will, die die Glasbruchmelder überwachen.....

[nieIP]

@nieIP sagte in js-controller 2.0 ab sofort im Latest Repo:

@apollon77 sagte in js-controller 2.0 ab sofort im Latest Repo:

@sissiwup bitte Screenshot der Widget konfig genau da bei den signalbilder zeigen.

siehe Post 477

Ich glaube die Lösung gefunden zu haben.
Im Widget ist bei
Griff-Sensor lowbat[1]
der folgende Eintrag aus dem Projekt das mit js-controller 1.x angelegt wurde
DG_SZ_F2_FDK:0.LOW_BAT

Wenn ich jetzt mit js-controller 2.x den gleichen Datenpunkt noch einmal per Mausklick aus der Liste auswähle steht dort
hm-rpc.1.0007D5699E98AF.0.LOW_BAT
und das falsche Symbol ist weg.

[paul53]

@nieIP sagte:

DG_SZ_F2_FDK:0.LOW_BAT

Das ist der Name.

@nieIP sagte in js-controller 2.0 ab sofort im Latest Repo:

hm-rpc.1.0007D5699E98AF.0.LOW_BAT

Möchtest Du dafür keinen Alias verwenden ? Das würde sich bei einem Austausch (Defekt) gut machen.

[nieIP]

@paul53 sagte in js-controller 2.0 ab sofort im Latest Repo:

@nieIP sagte:

DG_SZ_F2_FDK:0.LOW_BAT

Das ist der Name.

@nieIP sagte in js-controller 2.0 ab sofort im Latest Repo:

hm-rpc.1.0007D5699E98AF.0.LOW_BAT

Möchtest Du dafür keinen Alias verwenden ? Das würde sich bei einem Austausch (Defekt) gut machen.

Mit js-controller 1.x hat die Verwendung des Namens nicht dazu geführt, dass ein falsches Batt Low Symbol angezeigt wurde.
Wenn ich den Namen verwenden könnte, würde ich kein Alias brauchen, da der Name beim Gerätetausch nicht verändert wird.

BTW ich hatte den Namen in das Feld nicht eingetragen, sondern beim Erstellen der View mit der Maus aus der Datenpunktliste selektiert.
Heute war es eigentlich nur ein Versuch den Datenpunkt mal zu löschen und neu zuzuweisen und dabei ist mir der Unterschied aufgefallen.

[paul53]

@nieIP sagte:

Wenn ich den Namen verwenden könnte, würde ich kein Alias brauchen

Mir ist nicht bewusst, dass in Vis jemals die Datenpunktzuweisung per Name erfolgen konnte. Der Name wird lediglich angezeigt.

[sissiwup]

@MathiasJ sagte in js-controller 2.0 ab sofort im Latest Repo:

Haha..... Bei der CCU gehen nur 3.....
deshalb die Frage, weil ich evtl ein paar machen will, die die Glasbruchmelder überwachen.....

Ne, bei der CCU3 gehen mehr. Habe aktuell 4 im Einsatz.

[apollon77]

@MathiasJ es gibt technisch kein echtes Limit. effektiv hängt es davon ab wie viele Netzwerk Verbindungen dein host (der Master) abkann. Das muss man dann irgendwann tweaken ... aber da wärst Du dann schon bei ein paar tausend hosts oder Adaptern ;-))

Und ab irgend einem Punkt wirst du redis als DB brauchen.

[apollon77]

@nieIP mir wäre auch neu das das mal tat. Daher die Frage: hast du jemals das lowbat gesehn? ;-)) scheinbar - und das passt zur Erkenntnis von sissiwup: ungültige ids führen scheinbar dazu das es angezeigt wird.

[apollon77]

@nieIP ps: auch mit Vis 1.2.2 noch?

[apollon77]

Guten Abend

ab sofort ist die 2.0.39 im Latest Repo. Es sind noch ein paar Kleinere Fixes dazugekommen:

• (Apollon77) "upgrade name" for a controller will return an error to use "upgrade self"
• (Apollon77) "upgrade all" will no longer update controller too
• (Apollon77) add some more checks in adapter.js for existence of states/objects
• (Apollon77) enhance iobroker setup custom for Redis sentinel usage
• (Apollon77) make sure flot store works again also with objects with empty names

[MathiasJ]

@apollon77
Dankeschön.
Das heißt für meine Zwecke reicht es allemal.

[e-s]

@apollon77
Als du damals den 2.0 vorgestellt hattest, da hast du irgendwas erzahlt, dass der Controller sich merkt von wo aus ein Adapter installiert wurde und somit die Updates leichter sind.
Ist dies schon voll integriert, bzw ist jetzt auch ein automatisches update von Adaptern möglich, die ausschließlich auf github sind?

[apollon77]

@e-s Das ist voll drin, wobei ich jetzt nicht weiss was Du mit "automatische updates von Adaptern " meinst.

Wenn man mit der 2.0 einen Adapter vom GitHub installiert wird versucht den aktuellen Commit von GitHub zu ermitteln, der auch installiert wurde und dieser wird gespeichert. Das ganze passiert im "system.adapter.name" Objekt. Falls der Commit nicht ermittelt werden kann merkt sich das System mindestens das es ein GitHub install war.

Falls jetzt danach der Adapter auf einen anderen Host verschoben wird oder ein "minimal-Backup" (iobroker-data kopiert) wiederhergestellt wird, wird der Adapter von dieser gemerkten URL wieder installiert anstelle von npm. Damit restauriert er idealerweise exakt die gleiche GitHub-Version wie vorher da war (auch wenn es zwischenzeitlich schon weitere Änderungen auf GitHub gab) oder mindestens den aktuellen GitHub Stand.

Das ist um was es hierbei geht.