Hallo Community,

nach Upgrade auf 1.5.8 kann ich nicht mehr über die externe URL (fgljpxxxxxxxxx.myfritz.net) auf Admin zugreifen.
D.h. es funktioniert:
https://localhost:port
https://interneIP:port
https://externeIP:port

Es funktioniert nicht:
https://externeURL:port

Da die externe IP funktioniert kann es nicht am Port-Forwarding liegen und da ich über die externe URL immer noch auf meine FritzBox komme, liegt es auch nicht am DNS.

Interessanterweise hilft auch ein Downgrade auf 1.5.7. nichts. Nach etwas Probieren bin ich nun auf Greenlock (Let's encrypt) als Ursache gestoßen. Die 1.5.7 kam mit greenlock@2.6.8, die 1.5.8 mit greenlock@2.7.18 und ein Downgrade auf 1.5.7 hat die greenlock-Version auf 2.7.18 belassen. Durch Testen habe ich nun die Version 2.7.1 als letzte funktionierende Version ermittelt.

Meine Lösung also:
cd <iobroker> (bei mir am Mac "cd /usr/local/iobroker")
cd node_modules/iobroker.js-controller
npm i greenlock@2.7.1

Hoffe das hilft dem ein oder anderen weiter und hilft bei der Korrektur.

Viele Grüße
justr

@Peoples sagte in [Diskussion] js-controller 1.5.11 ab sofort im Stable Repository:

@Peoples sagte in [Diskussion] js-controller 1.5.11 ab sofort im Stable Repository:

No "killall.sh" script found. Just stop.

Hier hat keiner eine Idee?

Hallo Steffen,

mich stört der Fehler auch schon länger und habe deshalb mal nachgeforscht. Zumindest bei mir liegt das Script "killall.sh" im iobroker-Verzeichnis und nicht im Unterverzeichnis "/usr/local/iobroker/node_modules/iobroker.js-controller". Könnte mir aber vorstellen, dass das bei aktuelleren Installationen anders aussieht. Also es gibt jetzt verschiedene Möglichkeiten:

1. Das Shell-Script "killall.sh" ins Unterverzeichnis "<iobroker>/node_modules/iobroker.js-controller" kopieren/verschieben.
2. Oder in der Datei <iobroker>/node_modules/iobroker.js-controller/lib/setup.js in den drei Zeilen 287 bis 289 das "/../killall.sh" gegen "/../../../killall.sh" ersetzen, also zwei Verzeichnisse höher referenzieren.

Unschön ist dann auch, dass danach immer das root-Passwort abgefragt wird. Sollte mittlerweile ja auch nicht mehr nötig sein, solange keine Instanzen mehr unter root laufen. Also vermutlich kannst du im "killall.sh" die vier 'sudo' löschen.

HTH und viele Grüße
justr

edit: PS: Habe auch mal ein Issue in Git eingestellt.

@arteck
Ich bin begeistert! Ich hatte bisher keine Lösung gefunden, den Conbee II unter MacOS zum Laufen zu bekommen. Lediglich in einer Linux-VitualBox mit Phoscon funktionierte er. Das hat aber gereicht, dass der Lüfter im Wohnzimmer-Mac durchgehend rauschte, was den WAF zunichte gemacht hat. Selbst von Dresden-Elektronik gab es lediglich vage Andeutungen aus 2018. Was soll ich sagen? Mit dem aktuellen Zigbee-Adapter läuft alles wie geschmiert! Keine zusätzlichen Treiber nötig. Einfach den Conbee II eingesteckt und den USB-Port (/dev/tty.usbmodemDE21342711) in den Settings ausgewählt, fertig! Ok, musste den Adapter ein paar mal neu starten. Die Settings ließen sich erst nach einem restart öffnen. Und nach dem Auswählen des Conbee musste ich auch noch mal neu starten, damit ich den USB-Port auswählen konnte.

Vielen Dank!

@andyb:

Per Script den Play1 "add_to_group" befüllt mit der IP von der Playbar - IP wird in den Objekten entsprechend übernommen.

Allerding bleibt die Play1 stumm. `
Also das "add_to_group" finde ich auch immer etwas verwirrend. So wie beschrieben hättest du die Playbar deiner Play1 untergeordnet (nicht umgekehrt). Somit sollte nach Betätigung von "Play" (bei der Play1) eigentlich auch die Playbar die Musik von der Play1 übernehmen.

Achtung: In den Datenpunkt "add_to_group" wird nicht die IP-Adresse geschrieben sondern der Channel-Name der Sonos (Underscore "_" statt Punkt "."), also z.B. 192_168_1_101

@c_hoch_b Viel Erfolg! Ich musste die Devices leider neu anlernen. Evtl. hatte ich aber zu viel rumprobiert und dabei die Config verloren. Allerdings verliere ich alle paar Tage (einmal beim Einrichten und dann noch einmal in den letzten 10 Tagen) die Verbindung zum Conbee ohne Info-, Warn- oder Fehlermeldung. Auch die Instanz bleibt grün. Nach einem Restart der Instanz läuft aber alles wieder. Wenn es weiterhin passiert, werde ich mir wohl ein kleines Restart-Skript schreiben, welches triggert, wenn einer der Timestamps für die "link_quality" der Devices seit mehr als einer Stunde nicht mehr aktualisiert wurde. Wenn es aber immer erst nach mehreren Tagen passiert, reicht auch ein Auto-Restart jede Nacht. Werde es weiter beobachten...

Ja, Netzwerkkarte hat bei mir auch nur einmal funktioniert. Aber auch die Link-Quality ist nicht vertrauenswürdig. Schwankt extrem und ist für alle Geräte identisch.

@c_hoch_b Viel Erfolg! Ich musste die Devices leider neu anlernen. Evtl. hatte ich aber zu viel rumprobiert und dabei die Config verloren. Allerdings verliere ich alle paar Tage (einmal beim Einrichten und dann noch einmal in den letzten 10 Tagen) die Verbindung zum Conbee ohne Info-, Warn- oder Fehlermeldung. Auch die Instanz bleibt grün. Nach einem Restart der Instanz läuft aber alles wieder. Wenn es weiterhin passiert, werde ich mir wohl ein kleines Restart-Skript schreiben, welches triggert, wenn einer der Timestamps für die "link_quality" der Devices seit mehr als einer Stunde nicht mehr aktualisiert wurde. Wenn es aber immer erst nach mehreren Tagen passiert, reicht auch ein Auto-Restart jede Nacht. Werde es weiter beobachten...

@FredF Das stimmt natürlich und habe ich auch so gemacht (also auf dem lokalen Host aufgerufen). Und nach dem Downgrade auf die 2.4.0 klappt es ja auch wieder...

@FredF Tatsächlich, mit der IP-Adresse klappt es! Kannst du mir das erklären?

Vielen Dank und viele Grüße, justr

Guten Morgen zusammen,

seit der aktuellen ("latest") Version 2.4.1 funktioniert mein simple-api nicht mehr. Selbst bei der einfachen Abfrage
http://localhost:8087/help
bekomme ich ein "localhost hat die Verbindung abgelehnt" (Chrome-Fehlermeldung).

Sobald ich wieder auf die Vorversion 2.4.0 zurück gehe, läuft alles wieder.

Bin ich der Einzige?

Vielen Dank und viele Grüße
justr

@arteck
Ich bin begeistert! Ich hatte bisher keine Lösung gefunden, den Conbee II unter MacOS zum Laufen zu bekommen. Lediglich in einer Linux-VitualBox mit Phoscon funktionierte er. Das hat aber gereicht, dass der Lüfter im Wohnzimmer-Mac durchgehend rauschte, was den WAF zunichte gemacht hat. Selbst von Dresden-Elektronik gab es lediglich vage Andeutungen aus 2018. Was soll ich sagen? Mit dem aktuellen Zigbee-Adapter läuft alles wie geschmiert! Keine zusätzlichen Treiber nötig. Einfach den Conbee II eingesteckt und den USB-Port (/dev/tty.usbmodemDE21342711) in den Settings ausgewählt, fertig! Ok, musste den Adapter ein paar mal neu starten. Die Settings ließen sich erst nach einem restart öffnen. Und nach dem Auswählen des Conbee musste ich auch noch mal neu starten, damit ich den USB-Port auswählen konnte.

Vielen Dank!

@AlCalzone Also ich habe jetzt nicht immer Zeit, aber wenn ihr auch mal ein paar Stunden bis Tage warten könnt, könnt ihr zum Testen unter MacOS auf mich zurückgreifen.

@AlCalzone Mein iobroker läuft unter MacOS und tatsächlich kam es bisher von Zeit zu Zeit mal vor, dass Instanzen nicht korrekt beendet wurden und dann teilweise ständig versucht haben, sich doppelt zu starten. Wenn ich jetzt so drüber nachdenke, passierte das aber eher nicht bei "iobroker stop" sondern wenn ich einen Restart über den Admin anstieß oder iobroker selbst einen Restart initiiert hat. Hmm, bin mir unsicher...

@Peoples sagte in [Diskussion] js-controller 1.5.11 ab sofort im Stable Repository:

@Peoples sagte in [Diskussion] js-controller 1.5.11 ab sofort im Stable Repository:

No "killall.sh" script found. Just stop.

Hier hat keiner eine Idee?

Hallo Steffen,

mich stört der Fehler auch schon länger und habe deshalb mal nachgeforscht. Zumindest bei mir liegt das Script "killall.sh" im iobroker-Verzeichnis und nicht im Unterverzeichnis "/usr/local/iobroker/node_modules/iobroker.js-controller". Könnte mir aber vorstellen, dass das bei aktuelleren Installationen anders aussieht. Also es gibt jetzt verschiedene Möglichkeiten:

1. Das Shell-Script "killall.sh" ins Unterverzeichnis "<iobroker>/node_modules/iobroker.js-controller" kopieren/verschieben.
2. Oder in der Datei <iobroker>/node_modules/iobroker.js-controller/lib/setup.js in den drei Zeilen 287 bis 289 das "/../killall.sh" gegen "/../../../killall.sh" ersetzen, also zwei Verzeichnisse höher referenzieren.

Unschön ist dann auch, dass danach immer das root-Passwort abgefragt wird. Sollte mittlerweile ja auch nicht mehr nötig sein, solange keine Instanzen mehr unter root laufen. Also vermutlich kannst du im "killall.sh" die vier 'sudo' löschen.

HTH und viele Grüße
justr

edit: PS: Habe auch mal ein Issue in Git eingestellt.

Schon klar, aber beim nächsten Update des js-controllers wird er halt auch wieder global installiert.