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

[Ein ehemaliger Benutzer]

@apollon77
sorry, ist irgendwie verschwunden.

iobroker.2019-10-27.log

[root_]

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

7. Broadlink2 funktioniert nicht mehr. Was kann ich tun?
   Der Entwickler arbeitet an einem Update. Aktuell kann manuell durch eine Änderung die Funktion wiederhergestellt werden:
   Im ioBroker-Verzeichnis in node_modules/@frankjoke/myAdapter ODER node_modules/iobroker.broadlink2/node_modules/@frankjoke/myAdapter liegt das File myAdapter.js. Dieses muss durch diese Version ( myAdapter.js ersetzt werden.

Ich habe diesen Punkt wie in der FAQ beschrieben durchgeführt.
Vor dem Datei Austausch hatte ich den Radar2 UWZ Standortfehler.
Nach dem Austausch der Datei gegen die aus der FAQ bekomme ich bei starten von Radar2 folgende error Meldungen im Log:

host.raspberry	2019-10-28 16:21:27.114	error	Caught by controller[4]: noble warning: unknown handle 63 disconnected!
host.raspberry	2019-10-28 16:21:27.114	error	Caught by controller[3]: noble warning: unknown handle 68 disconnected!

Noble funktioniert aber und UWZ auch.

[apollon77]

@root_ Das passiert teilweise bei noble ... Liegt nicht am controller ... Da wird was geloggt von noble was Bluetooth angeht

[MathiasJ]

...auf die 2.0.38 null Problemo :)
@apollon77 :+1: :+1:

[root_]

@apollon77 Alles klar. Danke für die schnelle info.

[Linedancer]

Hallo Gemeinde,
ich bin seit etwa einer Woche mit js controller 2.0.35 unterwegs. Hatte bis jetzt keine Probleme festgestellt. Läuft.
Allerdings tritt jetzt ein Problem auf. Ich bekomme das Log hiermit zugemüllt

Spoiler

2019-10-29 01:52:56.346  - error: host.HTPC Objects 192.168.178.67:53936 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:52:57.764  - error: host.HTPC States 192.168.178.67:40258 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:52:57.791  - error: host.HTPC States 192.168.178.67:40260 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:01.376  - error: host.HTPC Objects 192.168.178.67:53942 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:01.404  - error: host.HTPC Objects 192.168.178.67:53944 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:01.432  - error: host.HTPC Objects 192.168.178.67:53946 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:02.820  - error: host.HTPC States 192.168.178.67:40268 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:02.847  - error: host.HTPC States 192.168.178.67:40270 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:02.905  - error: host.HTPC States 192.168.178.67:40272 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:02.934  - error: host.HTPC States 192.168.178.67:40274 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:02.962  - error: host.HTPC States 192.168.178.67:40276 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:06.471  - error: host.HTPC Objects 192.168.178.67:53958 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:07.990  - error: host.HTPC States 192.168.178.67:40280 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:08.018  - error: host.HTPC States 192.168.178.67:40282 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:11.502  - error: host.HTPC Objects 192.168.178.67:53964 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:13.047  - error: host.HTPC States 192.168.178.67:40286 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:13.075  - error: host.HTPC States 192.168.178.67:40288 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:13.112  - error: host.HTPC States 192.168.178.67:40290 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:13.142  - error: host.HTPC States 192.168.178.67:40292 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:13.171  - error: host.HTPC States 192.168.178.67:40294 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:13.199  - error: host.HTPC States 192.168.178.67:40296 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:16.532  - error: host.HTPC Objects 192.168.178.67:53978 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:16.560  - error: host.HTPC Objects 192.168.178.67:53980 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:16.588  - error: host.HTPC Objects 192.168.178.67:53982 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:16.617  - error: host.HTPC Objects 192.168.178.67:53984 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:16.645  - error: host.HTPC Objects 192.168.178.67:53986 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:18.236  - error: host.HTPC States 192.168.178.67:40308 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:18.281  - error: host.HTPC States 192.168.178.67:40310 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:21.675  - error: host.HTPC Objects 192.168.178.67:53992 (Init=false) Redis error:Error: Invalid Chunk: parse failed
2019-10-29 01:53:21.703  - error: host.HTPC Objects 192.168.178.67:53994 (Init=false) Redis error:Error: Invalid Chunk: parse failed

Das kommt etwa alle 5 sekunden. Die IP die dort erwähnt wird ist ein Raspi der früher mal als Multihost Slave eingebunden war. Nach meinem iobroker Umzug auf einen NUC hab ich das Multihost aufgelöst und es laufen alle Adapter auf dem NUC. Auf dem Raspi läuft jetzt nur noch vcontrold für die Viessmann Heizung. Wenn ich das richtig sehe sind diese Fehler im Log aufgetreten nachdem ich den Raspi neu gebootet habe.

Mein System:
Node.js v10.16.3
NPM 6.9.0

Gibts Ideen, wie ich die Fehler im Log loswerde?

[apollon77]

@Linedancer Kann es sein das durch den Reboot der ioBroker Slave wieder gestartet wurde und jetzt versucht zum Master zu verbinden? Da der Master aber nun 2.0 ist (der Slave aber noch 1.5) kommt es zu gen diesen Meldungen.

[arteck]

@apollon77 das hatten wir schon mal... kannst dich entsinnen.. mit tankerkönig
jetzt was anderes.. hmmm..das riecht nach einen Problem

das ist es

[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 :hugging_face:

[Ein ehemaliger Benutzer]

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

@MathiasJ viele :hugging_face:

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.