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

[Feuersturm]

@foxriver76 Ist das hier richtig oder sollte hier die ip vom Master stehen?

Server is running on http://localhost:8081

[foxriver76]

@feuersturm das passt, wenn dann fragt der Admin den falschen Host an. Nur eigentlich sah das richtig aus im Admin issue. Also controller macht alles richtig nur Admin müsste das anfragen was du da eben auch gesehen hast wenn du die ip eingegeben hast, ich schaue nochmal rein ansonsten baue ich logging in nächste admin Version

[foxriver76]

@Feuersturm Bzw. könntest du während dem Update mal wenn du die Dev Tools offen hast (F12 meistens, bzw wo auch die Konsole ist), sollte ein Tab Netzwerkanalyse sein, öffne das mal und erst wenns offen ist starte das problembehaftete Upgrade, dann sollten wir sehen was da passiert.

[Feuersturm]

@foxriver76 Ich habe leider keinen besseren Weg gefunden einen Export von der Ausgabe zu machen.
Ich habe die Netzwerkanalyse gestartet und dann das Update gestartet auf dem Slave. So sieht es dann aus.

Edit: Das Update startet dort wo die Zeilen mit dem / beginnen. Diese Zeile wiederholt sich für einige Sekunden bis es dann einfach aufhört.

[foxriver76]

@feuersturm ok anscheinend fragt er den Master statt den Slave ab..

[foxriver76]

@feuersturm Bitte nochmal mit admin 6.8.0 probieren sobald verfügbar

[Feuersturm]

@foxriver76 Wohooo. Es funktioniert mit Admin 6.8.0. Vielen Dank für deinen großartigen Einsatz.

[foxriver76]

Hallo zusammen,

zeitnah wird Controller 5.0.12 erscheinen, nichts weltbewegendes dabei, da es langsam alles recht stabil zu laufen scheint.

Änderungen

• DNS Warnung bei Erstinstallation wird nicht mehr unbegründet angezeigt
• Methode für Entwickler updateConfig berücksichtigt nun Auto Encryption und stellt sicher, dass die aktuellste Config genutzt wird
• Webserver (UI Upgrade) schließt alle Verbindungen direkt, nachdem die finale Information geliefert wurde und vermeidet so unnötige Downtime des Controllers bei Folgeanfragen
• Methoden für Entwickler: Neue Methoden für Client-Push (Infos an die UI pushen bzw. Pub/Sub System hierfür - Beispielimplementierung folgt demnächst)
• Backup-Restore Problem behoben, bei dem bei Restore eines Backups die Daten in die falsche DB geschrieben wurden, falls sich die von Backup und aktueller Installation unterschieden hatten
• Backup Optimierungen: Falsches Logging im Fehlerfall behoben und Backups sind nun ca. 30 % kleiner

[Feuersturm]

@foxriver76 Update vom Master Slave System auf 5.0.12 lief ohne Probleme und Systeme sind auch sauber gestartet.

[Ein ehemaliger Benutzer]

@apollon77 @foxriver76

5.0.12 läuft, Backup mit über 100000 States und 120000 objects ohne Probleme

Danke !

[ticaki]

Keine Ahnung wo dieser "Fehler" hin hingehört. Aber er ist mir erst seit js-controller 5 aufgefallen, und das mit dem iobroker.shelly und iobroker.sonoff.

Beide Adapter zeigen gelegentlich folgendes Verhalten, ich kann auch nicht nachvollziehen wie es reprodzierbar wäre. Passiert jeden Tag 1 mal bei ca. 100 Schaltvorgängen.

auf das Umschalten eines Relays mit

setState(id, true, false)

erfolgt folgende Reaktion innerhalb von ein paar ms vom Adapter

{val: false, ack: true)
(val: true, ack: true)

Hab deshalb sämtliche manuell übersteuert Funktionen aus meiner Automatik genommen.

[mcm1957]

@ticaki
Ich vermute mal dass das nichts mit js-controller 5 zu tun hat. Wenn da mehr Diskussion kommt bitte ev. abspalten (@Homoran)

Ich gehe davon aus, dass es sich bei dem State um einen State handelt, den einerseit du von extern setzt und der andrerseits intern vom Gerät gesetzt wird. Da ist es durchaus möglich, dass dein Schaltauftrag zunächst mal von einem Wert der vom Gerät kommmt übersteuert wird. setStates mit ack=true kommen ja vom Gerät

Also:

• extern setzt val: true, ack: false
• Adapter code liest das
• Gerät sendet val:false, adapter setzt daher val: false, ack: true
• Adapter sendet val: true (das kann auch Grund der asynchronität auch erst nach dem Empfang einer Meldung vom Gerät passieren !)
• Gerät sendet va:true, Adapter setzt daher val:true, ack: treu

Dass das nur selten passiert liegt wahrscheinlich am engen Zeitrahmen in dem so eine Konstelleation passieren muss. Wichtig beim drüber Nachdenken ist, dass der Adapter das ack=trzue richtigerweise erst setzen sollte wenn das Gerät den neuen Wert bestätigt hat.

Ergo seh ich das als durchaus zulässiges Verhalten.

[Merlin123]

Gibt es eine Übersicht von Adaptern, die aktuell noch Probleme machen?

[mcm1957]

@merlin123

Derzeit sollten KEINE Adapter mehr Probleme machen, ausgenommen

km200 - ist deprecated, Ersatz ems-esp
samsung_tyzen - war nie in repos und repository ist stale
daikin-cloud erfordert noch github installation

Alle anderen sollten via latest in einem brauchbaren Zustand sein;
und asap auch auf stable erscheinen sofern noch nicht geschehen.

Ich werd dazu aber in den nächsten Stunden sowieso ein Hilfegsuch hier absetzen :-)

[Merlin123]

@mcm57 Ah perfekt :) Danke! Bin jetzt auch auf die 5.0.12 hoch und bis jetzt läuft alles. Ich beobachte das mal.

[mcm1957]

Liebe Beta-User und Tester,

Vorab ein ganz herzliches DANKE für eure Mühe und die zahlreichen Feedbacks zur Qualitätsverbesserung.

Da nun der js-controller 5 in sehr naher Zukunft im stable Repository aufgenommen werden soll, versuchen wir sicherzustellen, dass alle Adapter die in den letzten Wochen eine Anpassung erhalten haben auch in einer für den js-controller 5 geeigneten Release im stable Repository verfügbar sind. Ich habe dazu aus den Informationen in diesem Topic eine Liste von Adaptern zusammengestellt, die davon (potenziell) betroffen sind. Diese kommt im nächsten Beitrag.

Bei jedem Adapter ist angegeben, welche Release für js-controller 5 mindestens erforderlich ist und ob diese bereits im stable verfügbar ist. Einige wenige hier angesprochene Adapter werden unter js-controller 5 nicht mehr unterstützt, vor allem da sie nicht mehr gewartet werden. Diese sind entsprechend markiert. Adapter die noch nie im stable repository waren, sind ebenfalls markiert da es hier vom dev abhängt wann er diese für stable ready hält.

Und nun mein BITTE:

Falls ihr im Zuge eurer Tests weitere Adapter (die nicht in der nachfolgenden Liste stehen) entdeckt habt die im ioBroker repository gelistet sind gebt diese bitte bekannt und schreibt dazu

-) ob der Adapter nun mit der aktuellen Release im latest funktioniert
-) ob der Adapter nur via github Installation funktioniert
-) ob der Adapter vom dev gar nicht angepasst wurde und daher nicht mehr funktioniert

Sofern bekannt verlinkt bitte das entsprechende Issue.

Ziel der Aktion ist vor allem sicherzustellen dass verbesserte Adapter auch sicher ins stable Repository kommmen. Zu dem Zweck werde ich den entsprechenden Maintainern ggF nachlaufen und abzuklären versuchen ob noch etwas gegen einen stable Update spricht.

DANKE für eure Unterstützung
mcm1957

[mcm1957]

❗ offen, Fragen zu klären
⌛ in Arbeit, alles geklärt
✅ ok, alles erledigt
🚫 adapter wird mit js-controlle 5 nicht mehr unterstützt
⚪ nicht für js-controller 5 relevant oder Adapter nicht im Repository
:mega: dev kontaktiert, warte auf Feedback

• ⚪
  acme - required: none
• ✅
  admin - required: 6.8.0 - released
• ✅
  anelhut - required: 1.0.15 - released
• ✅
  b-control-em - required: 0.3.1 - released
• 📣
  bosch-ebike - required: ???
• ✅
  cul - required: 2.2.0 - released (no change)
• :mega:
  doorbird - required: ???
• ❗
  daikin-cloud - required: new release planned
• 📣
  energymanager - required: ??? - PR pending
• ⚪
  enigma2 - required: none - not at stable yet
• ✅
  fakeroku - required: 0.2.2+ - released
• ⌛
  fhem - required: 2.0.5 - PR pending
• ⌛
  iqontrol - required: 2.3.0 - PR merged
• 📣
  javascript - required: ???
• 🚫
  km200 - deprecated - Ersatz: ems-esp
• 📣
  lgtv - required: ???
• ❗
  linux-control - required: ???
• ✅
  maxcul - required: 1.3.1 (no change)
• ⚪
  miio - required: none - not at stable
• ⌛
  mydlink - required: 1.3.4 - PR pending
• ✅
  nanoleaf-lightpanales - required: 1.4.0 - released
• ✅
  node-red - required: 4.03+ (no change)
• ✅
  notification.manager - required: 0.1.1 - released
• ✅
  pi-hole - required: 1.3.6+ - released
• ✅
  ping - required: 1.6.2 - released
• 🚫
  samsung_tyzen - stale repo - deprecated with js-controller 5
• ✅
  stiebel-isg - required: 1.7.6+
• ❗
  systeminfo - required: ???
• ✅
  viessmann - required: 1.4.4+ - released
• 📣
  web - required: ???
• 📣
  yahka - required: 1.0.1 - PR requested
• ✅
  zigbee - required: 1.8.23 - released

[mcm1957]

Die obige Liste ist optisch nicht 1a - sorry. Ich hab keine Ahnung warum das Forum nach den Symbolen unbedingt ne neue Zeile beginnen will :-(

Optisch kompakter aber mit identem Inhalt findet ihr die Info in folgendem Issue das als Arbeitspapier mißbraucht wurde.

https://github.com/ioBroker/ioBroker.repositories/issues/2514

Hier findet ihr im ersten Beitrag diese Liste, im zweiten Beitrag zu jedem Adapter eine Sammlung loser Daten wie Verweise auf Forumsbeiträge, Issues etc.

Kann dort gerne gestöbert werden.

ABER BITTE DIE DISKUSSION HIER IM FORUM BELASSEN!

[mcm1957]

Weitere betroffene Adapter:

• ds18b20
  braucht Update
  https://forum.iobroker.net/topic/66985/test-adapter-ds18b20-v2-0-x/8

• history
  braucht update auf 2.2.6
  https://github.com/ioBroker/ioBroker.history/issues/268 (fixed)
  https://github.com/ioBroker/ioBroker.history/issues/253 (offen)

[Tom2323]

Ich habe Probleme mit dem ioBroker Update.
Ich habe v6.2.23 mit js-controller 4.0.24 auf einem Raspberry.
Ich wollte alles auf den aktuellen Stand bringen.
Als erstes habe ich alle Adapter ge-update. Dann habe ich in der Konsole weitergemacht…

cd /opt/iobroker/ 

sudo iobroker stop
sudo iobroker update
sudo iobroker upgrade self 

sudo iobroker start

Nach dem Start zeigt er mir unter Host ich solle js-controller von @4.0.24 to @5.0.12 updaten und scheinbar hat er auch die Adapter updates noch nicht gemacht. z.B. der Admin Adapter sagt, er hätte v 6.2.23 und will auf 6.9.1 wieder updaten.

Was mache ich falsch?