Bei mir habe ich vier Innengeräte im Einsatz. Eine größere Inneneinheit die bereits seit 2013 läuft (für das EG wobei das ein offener Bereich ist). Dieses Jahr ist das DG dazugekommen. Hier sind für einzelne Räume drei deutlich kleiner dimensionierte Gerät im Einsatz.

Die "Unofficial API Documentation" ist ja auf Basis einer Daikin Emura FTXG-L entstanden. Bei dieser ist ja das WLAN Modul scheinbar von Haus aus verbaut.

Ich habe eine FTXS-K (2013er Modell), eine FTXS-K (2016er Modell) und zwei CTXS-K (2016er Modell).

Im Internet bin ich über diese "Compatible Devices" Liste gestolpert:

Compatible units in combination with BRP069A41:
FTXG20LV1BW, FTXG20LV1BS , FTXG25LV1BW, FTXG25LV1BS, FTXG35LV1BW, FTXG35LV1BS, FTXG50LV1BW, FTXG50LV1BS,
FTXJ20LV1BW, FTXJ20LV1BS, FTXJ25LV1BW, FTXJ25LV1BS, FTXJ35LV1BW, FTXJ35LV1BS, FTXJ50LV1BW, FTXJ50LV1BS ,

Compatible units in combination with BRP069A42:
FTXZ25NV1B, FTXZ35NV1B, FTXZ50NV1B, FTXS35K2V1B, FTXS35K3V1B, FTXS42K2V1B, FTXS42K3V1B, FTXS50K2V1B,
FTXS50K3V1B, FTXLS25K2V1B, FTXLS35K2V1B,FTXM35K3V1B, FTXM42K3V1B, FTXM50K3V1B, , FTXS60GV1B, FTXS71GV1B,
ATXS35K2V1B, ATXS35K3V1B, ATXS50K2V1B, ATXS50K3V1B, , FTX50GV1B, FTX60GV1B, FTX71GV1B, , FVXG25K2V1B,
FVXG35K2V1B, FVXG50K2V1B, , FVXS25FV1B, FVXS35FV1B, FVXS50FV1B, , FLXS25BAVMB, FLXS25BVMA, FLXS25BVMB,
FLXS35BAVMB, FLXS35BAVMB9, FLXS35BVMA, FLXS35BVMB, FLXS50BAVMB, FLXS50BVMA, FLXS50BVMB, FLXS60BAVMB,
FLXS60BVMA, FLXS60BVMB,

Compatible units in combination with BRP069A43:
CTXS15K2V1B, CTXS15K3V1B, FTXS20K2V1B, FTXS20K3V1B, FTXS25K2V1B, FTXS25K3V1B, CTXS35K2V1B, CTXS35K3V1B,
FTXM20K3V1B, FTXM25K3V1B, , ATXS20K2V1B, ATXS20K3V1B, ATXS25K2V1B, ATXS25K3V1B, , FTX20J2V1B, FTX25J2V1B,
FTX35J2V1B, FTX20J3V1B, FTX25J3V1B, FTX35J3V1B, , FTXL25J2V1B, FTXL35J2V1B, , FTX20KV1B, FTX25KV1B, FTX35KV1B,
FTX20GV1B, FTX25GV1B, FTX35GV1B, , ATX20J2V1B, ATX20J3V1B, ATX25J2V1B, ATX25J3V1B, ATX35J2V1B, ATX35J3V1B,
ATX20KV1B, ATX25KV1B, ATX35KV1B, , ATXL25J2V1B, ATXL35J2V1B,

Compatible units in combination with BRP069A44:
FTX50KV1B, FTX60KV1B

Sofern diese Auflistung stimmt, bekomme ich für mein 2013er Modell einen BRP069A42 Wifi-Controller und für die drei 2016er Modelle einen BRP069A43 Wifi-Controller.

Beim "42er" hast Du ja bereits geschrieben das dieser vermutlich auch funktionieren sollte.

Installieren möchte die die Wifi-Controller auf jeden Fall. Wenn es dann auch mit der ioBroker Steuerung klappt umso besser. Auf jeden Fall hast Du somit gleich einen Tester und kann (mit etwas Glück) die Liste der erfolgreich getesteten Wifi-Controller erweitern :-).

Betreffend der Mehrfach Instanzen habe ich da mittlerweile kein Problem mehr. Soweit ich das Konzept von ioBroker verstanden habe, soll ja bei mehreren Geräten mit mehreren Instanzen gearbeitet werden (wobei das nicht bei allen Adaptern so gehandhabt wurde).

Auf meinem RPi3 auf dem ich begonnen habe, war mit vielen Adaptern (betreffend Speicher) schon etwas schmerzhaft. Nachdem ich aber vor kurzem auf einen Intel NUC mit einer Debian Installation umgezogen bin kann ich nun Adapter installieren ohne über den Speicher nachdenken zu müssen. Somit sind dann auch vier Instanzen von Daikin Adapter kein Problem .

Betreffend Funktionsumfang vom Adapter hast Du dann ja schon deutlich mehr implementiert (eigentlich alle Funktionen) als ich aus dem bisherigen Forenbeitrag rauslesen konnte.

Ich verwendet in jedem Raum ein Homematic Wandthermostat und einen HM Heizkörperthermostat.

Somit würde, sofern es funktioniert die Klimaanlage in Abhängigkeit der Wandthermostat Werte steuern.

Zum heizen habe ich die Geräte bisher noch nicht verwendet (bis auf den Testbetrieb). Wobei die Energieeffizient sowohl beim Kühlen als auch beim Heizen wirklich sehr gut ist bei diesen Geräten.

Kann Deine Überlegungen betreffend "Klima auch beim heizen einbeziehen", gerade bei einer FBH gut nachvollziehen. Gerade wenn es darum geht einen kühlen Raum schnell warm zu bekommen wird die Daikin da sicher gute Dienste leisten.

Spätestens wenn ich die Wifi-Controller habe, melde ich mich wieder und gebe Bescheid welche Controller mit welcher Firmware Version es sind und was damit funktioniert oder auch nicht funktioniert.

> Scheinen aber nur zu zweit zu sein :-)
Vielleicht beobachten andere den Beitrag, damit sie wissen welche "ioBroker unterstützte Klimaanlage" sie sich anschaffen sollen, wenn es denn soweit ist :lol: .

Hi,

Tritt bei mir auch seit kurzem auf (IoT Adapter // pro.Account).

LG

Es ging mir hier nie eine Schuldfrage, sondern immer nur um die Ursache meiner Systemabstürze.

Ich ziehe meinen Hut davor, wieviel von so vielen zu diesem Projekt beigetragen wird. Und es wird würde mir nicht in den Sinn kommen mit dem Finger auf irgendjemand oder irgendetwas zu zeigen nur weil es bei meiner Installation zu Problemen kommt.
Das war auch nie die Absicht, falls das irgendwie so rübergekommen ist.

Ich bin schwer begeistert vom ioBroker und das schon ziemlich lange. Mein System ist mittlerweile doch schon etwas gewachsen und lief bis zum ersten erwähnten Absturz absolut stabil.

Nachdem es dann einige Änderungen am System gab (die genannten Updates), aber auch von Zeit zu Zeit neue Adapter getestet dazugekommen sind, gibt es viele mögliche Ursachen.

Und mit „Ursache“ meine ich lediglich, „welche Änderung hat dazu geführt, das es nun zu Systemabstürzen kommt“.

Ob das nun ein neu verwendeter Adapter ist, oder Updates oder auch eine Kombination aus alledem ist im Grunde erst mal egal. Ich möchte nur herausfinden, so dass ich Maßnahmen setzen kann um mein System wieder in einen stabilen Zustand zu bringen.

Da ich bei der Analyse irgendwann angestanden bin, ging es eben mit Try & Error und dem Ausschließungsprinzip weiter. Nach dem Denkanstoß von @darkiop habe ich dann einfach mal auf gut Glück den BackitUp Adapter wieder deaktiviert.

Und wenn mein System nach dem deaktivieren von einem (in meiner Installation) neuen Adapter wieder stabil laufen sollte und nach erneutem Aktivieren wieder Abstürze auftreten, dann Freue ich mich im ersten Moment einfach nur die Ursache gefunden zu haben.

Wenn es mit dem Adapter am Ende gar nichts zu tun hat, dann geht die Suche eben weiter.

Da ich aber dazu beitragen möchte das Problem genauer zu analysieren, lasse ich nun im ersten Schritt vorerst den Adapter noch eine gewisse Zeit deaktiviert.
Wenn es dabei nicht zu Abstürzen kommt, werde ich eine andere (markante) Backup Zeit als 02:00 einstellen und schauen ob die Abstürze wieder auftreten.
Wenn ja dann finde ich hier ja ggf. Unterstützung wie ich mein System monitoren (Speicherauslastung aufzeichnen) kann um herauszufinden ob wirklich ein Speicherengpass den Absturz hervorruft.

Das würde den Entwickler vermutlich auch interessieren, da zwangsläuft mit wachsenden Installationen (wird bei den meisten begeisterten Anwendern der Fall sein) auch mit zunehmenden Ausfällen zu rechnen wäre. Und ein Backup Adapter findet sicher bei sehr vielen Anwendern Anklang.

Soweit erst mal mein Plan wie ich weiter vorgehen möchte.

Beim BackitUp Adapter hatte ich bisher nur das Standardbackup im Einsatz. Das Komplettbackup oder auch andere Möglichkeiten habe ich noch gar nicht genutzt bzw. aktiviert.

@Homoran
"Gewagte Aussage"
Warum wird der Adapter "sicher" nicht der Verursacher sein?
Das war ja auch keine Kritik an dem Adapter oder ähnliches. Ich versuche ja nur das Problem einzugrenzen.
Wenn das gelingt, kann man ein Problem per Github melden. Der Entwickler ist für entsprechende Informationen sicher dankbar.

Das mit dem Ram würde ich nicht gleich in Betracht ziehen. Ich weiß zwar nicht wie es zum Zeitpunkt vom Absturz ausgeschaut hat. Aber die (betroffene) ioBroker Hauptinstanz läuft auf einer VM in einem NUC und hat 4 GB RAM zur Verfügung (davon aktuell laut ioBroker noch 1,3 GB frei).

Nach Deiner Theorie müßte der Adapter (beim komprimieren der Daten) die meistens ioBroker RPi's mit 1 GB Gesamtspeicher an ihre Grenzen bringen.

Kurzes Zwischenfeedback:

Seit dem 03.04.2019 ist es zu keinem Absturz mehr gekommen.
Ich habe wie angekündigt den BackitUp Adapter (Verison 1.1.3) mal testweise deaktiviert.

Das beweißt zwar noch nicht das diese die Ursache ist/war aber es ist schon mal ein Fortschritt.
Ich werde das jetzt noch eine Zeit lang mit deaktiviertem Adapter beobachten.

Wenn es keine Probleme mehr gibt, werde ich für das Standardbackup eine andere, markante Zeit einstellen und den Adapter wieder aktivieren. Dann sollte sich zeigen ob der Adapter die Ursache bzw. ein Mitverursacher ist.

@darkiop : Der Hinweis der der Backitup Adapter da reinspielen könnte ist nicht schlecht.
Den BackitUp Adapter habe ich aktuell in der Version 1.1.3 laufen.

Das Standard Backup ist auf 02:00 eingestellt. Allerdings wird dieses täglich erstellt (alle Backups älter als 5 Tage werden gelöscht).
Andere Backups sind damit keine eingeplant. Nur das Standard Backup.

Werde den Adapter mal testweise deaktivieren und schauen wie es sich in ein paar Tagen verhält.

@wendy2702 : Danke für die Info mit Deinen Versionen. Wenn ich das Problem so nicht lösen/eingrenzen kann, werde ich ggf. auch ein Upgrade auf node/nodejs 10.x durchführen.

Hm... ich habe im Forum gesucht wie bei nodejs/npm Updates vorgegangen wird und habe mich dort an den aktuelleren Beiträgen orientiert.
Werde mich zukünftig mehr an offiziellen Dokus orientieren...

In der aktuellen Doku steht oben bei der "Neuinstallation":

Die momentan empfohlene Version ist node 8.x; mit js-controller 1.5.7 auch node 10.x, dann in Schritt 4.1. die “8.x” gegen 10.x” austauschen

Wäre es somit empfehlenswert, da ich ja den js-controller 1.5.7 verwende auch auf eine aktuelle node 10.x Version zu welchseln? Und wenn ja, welche npm Version sollte zu einer node 10.x Version kombiniert werden?

Wenn es hier eine Empfehlung gibt, würde ich node und npm auf die nächste Masterversion updaten und dann eben noch ein

npm rebuild

darüber laufen lassen.

Ich bin bei den ganzen Anleitungen betreffend nodejs/npm update immer über das rebuild.sh Script gestolpert (auszuführen im iobroker Verzeichnis).
Das lies sich aber für meine nodejs/npm Version nicht ausführen.

Ich gehe einfach mal davon aus das diese Anleitungen und Hinweise inzwischen obsolet sind.

Auf das direkte

npm rebuild

bin ich leider nicht gestossen

Ich habe mich dann nach verschiedenen Hinweisen dazu entschieden das reinstall.sh laufen zu lassen.
Das hat auch etwas gedauert, ist aber sauber durchgelaufen und es gab dann im Anschluss keinen Hinweis darauf das irgendwas nicht funktionieren würden. Alle JS-Scripte und alle Adapter liefen sauber.

Nach dem reinstall.sh sollte ja kein "npm rebuild" mehr notwendig sein, oder doch?

Bis es dann zu den Abstürzen in der Nacht kam (und dabei, wie erwähnt alle drei zur selben Zeit).
Nachdem die Zeit (immer um 02:00) so auffällig ist scheint es mir einen Trigger zu geben.

Werde trotzdem mal versuchen den wifilight Adapter zu deaktivieren und dann schauen ob innerhalb von diesem 6-8 Tage Fenster ein erneuter "Absturz" auftritt.
Wobei das ggf. auch eine Sackgasse ist. Womöglich funktionieren die geplanten Restarts (alle 5 Minuten) vom "wifilight Adapter" einfach nicht mehr wenn der js-controller weg ist. Somit wäre das kein Hinweis auf diesen Adapter sondern einfach eine Funktionalität die ohne den js-controller nicht mehr gegeben ist.

Meiner Meinung nach bin ich mit den

trap invalid opcode

Im syslog schon sehr nahe an der Sache dran. Bin aber auch kein Linux bzw. nodejs Experte und kann somit nur auf klassische Weise versuchen den Fehler einzugrenzen und mit Google tiefer in die Materie einzutauchen.

Aber beim

trap invalid opcode

habe ich noch nichts hilfreiches gefunden.

Wenn es für eine höhere npm/nodejs Version "grünes Licht" gibt, könnte ich auch das versuchen.
Mir ist halt wichtig das ich wieder auf ein stabiles ioBroker System komme und das ist bei noch höheren Versionen ggf. ungewiss (sofern es keine "erfolgreich getest" Freigaben für bestimmte Kombinationen gibt).

Beim "Javascript Adapter" verwende ich die Version 4.1.12 (somit höher als die genannte Version). Die anderen genannten Adapter habe ich nicht im Einsatz.

Mit ist beim Erstellen des Beitrags doch etwas mit dem wifilight Adapter aufgefallen. Nach der "error:" Meldung um 02:00 gibt es danach keine "error:" Einträge mehr für diesen Adapter.

Ggf. hat der sowieso fehlerhafte Adapter mit einer aktuellen node Version (oder einer anderen aktualisierten Komponente) noch mehr Probleme als schon vorher. Wobei mir das mit genau 02:00 trotzdem nicht klar ist.

Ich werde testweise mal den Wifi Light Adapter deaktivieren und schauen wie es sich weiter verhält.

Hätte ich für die LD382 oder LD382A ein passendes NPM Modul gefunden, hätte ich eh schon versucht den Adapter so abzulösen.
Jetzt schaue ich mal ob es der Adapter ist.

Falls noch jemand anhand vom Fehlerbild andere Ideen hat, bin ich trotzdem auch weiterhin für jede Anregung dankbar.

Gruß
Roland

Hallo,

Meine ioBroker Installation stürzt alle 6-8 Tage ab. Eigentlich ist es der iobroker.js-con Prozess der dann nicht mehr läuft.

Meine ioBroker Umgebung:

• Hauptinstanz auf Virtualbox VM auf einem NUC (hier laufen fast alle Adapter)
• 2. Instanz auf RPi (hier läuft nur der Radar Adapter für BT Presence)

Der VM sind 4 GB RAM zugeordnet und reichlich Festplattenplatz. Die Datenbank für den SQL Adapter läuft auf einer anderen VM.
Auf der Hauptinstanz läuft Debian 9. Betroffen von dem Problem ist die Hauptinstanz.

Das Ganze hat am 18.03.2019 angefangen nachdem ich mal einige Updates nachgezogen habe (Details zu den Versionen sind auch hier zu finden >>> https://forum.iobroker.net/topic/21106/alexa-problem-nach-updates-gewerk-raum-reagiert-gerade-nicht).
Allerdings hatte der dort beschriebene Fehler mit einem IoT Adapter im Beta Status zu tun. Das konnte ich nach einem Adapter Downgrade lösen. Das Thema mit den Abstürzen hat dort erst begonnen.

Abgesehen von diversen ioBroker Adaptern habe ich am 18.03.2019 folgendes aktualisiert:

• Linux System Updates
• node.js von 6.16.0 auf 8.15.1
• npm von 3.10.10 auf 6.4.1
• js-controller von 1.4.2 auf 1.5.7

Das erste Mal ist mir das System am 19.03.2019 abgestürzt. Danach am 25.03.2019 wieder und heute Morgen (03.04.2019) erneut.

Das System lässt sich danach ohne Probleme wieder starten (habe das System der VM neu gestartet) und läuft danach auch wieder ohne Probleme (bis es dann in einigen Tagen wieder soweit ist).
In den ioBroker Logs gibt es keinerlei Hinweise auf den Absturz (oder Aktivitäten davor).
Im Syslog habe ich sehr wohl etwas gefunden.

Und zwar schaut es so aus als wäre der Absturz immer zur selben Zeit (02:00) erfolgt (jeweils einige wenige Sekunden auf oder ab).

Gefunden habe ich dazu folgende Zeilen im syslog:

Mar 19 02:00:29 iobrokersrv kernel: [58402.630190] traps: node[4853] trap invalid opcode ip:1460b59 sp:7f5aad6e1588 error:0
Mar 19 02:00:29 iobrokersrv kernel: [58402.630226]  in node[400000+1b68000]
Mar 25 02:00:25 iobrokersrv kernel: [511530.817899] traps: node[655] trap invalid opcode ip:1460b59 sp:7efd8d7ec588 error:0
Mar 25 02:00:25 iobrokersrv kernel: [511530.817902]  in node[400000+1b68000]
Apr  3 02:00:28 iobrokersrv kernel: [734016.606985] traps: node[505] trap invalid opcode ip:1460b59 sp:7f4c241bc588 error:0
Apr  3 02:00:28 iobrokersrv kernel: [734016.606989]  in node[400000+1b68000]

Das Kernel Update habe ich nach dem zweiten Absturz am 25.03.2019 durchgeführt, in der Hoffnung das dies etwas bewirkt.
Hat es aber leider nicht, wie der heutige Absturz zeigt.

Hier auch noch einige syslog Einträge vor und nach dem Abstürz (falls da etwas hilfreiches enthalten ist):

Apr  2 22:17:01 iobrokersrv CRON[4515]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr  2 23:17:01 iobrokersrv CRON[5366]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr  3 00:17:01 iobrokersrv CRON[6230]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr  3 00:26:49 iobrokersrv dhclient[523]: DHCPREQUEST of 192.168.2.54 on enp0s3 to 192.168.2.1 port 67
Apr  3 00:26:50 iobrokersrv dhclient[523]: DHCPACK of 192.168.2.54 from 192.168.2.1
Apr  3 00:26:50 iobrokersrv dhclient[523]: bound to 192.168.2.54 -- renewal in 35666 seconds.
Apr  3 01:17:01 iobrokersrv CRON[7094]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr  3 02:00:28 iobrokersrv kernel: [734016.606985] traps: node[505] trap invalid opcode ip:1460b59 sp:7f4c241bc588 error:0
Apr  3 02:00:28 iobrokersrv kernel: [734016.606989]  in node[400000+1b68000]
Apr  3 02:17:01 iobrokersrv CRON[7916]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr  3 03:17:01 iobrokersrv CRON[8582]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr  3 03:51:28 iobrokersrv systemd[1]: Created slice User Slice of roland.
Apr  3 03:51:28 iobrokersrv systemd[1]: Starting User Manager for UID 1000...
Apr  3 03:51:28 iobrokersrv systemd[1]: Started Session 222 of user roland.

Ich habe bei Google zwar einiges gefunden mit „trap invalid opcode“ aber nichts was mir Möglichkeiten aufzeigt wie ich das Problem lösen könnte.

Vor diesen Updates ist der ioBroker Wochen bzw. Monate durchgelaufen ohne irgendwelche Probleme oder Abstürze.

Hier noch ein paar Informationen aus der /proc/version

Linux version 4.9.0-8-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.144-3.1 (2019-02-19)

Hat jemand eine Idee was ich noch probieren könnte um das Problem zu lösen oder zumindest weiter einzugrenzen?

Gruß
Roland

Guten Morgen,

Die Meldung kann ich so bestätigen. Tritt bei mir bei allen vier Daikin Instanzen auf.
Ich habe dazwischen aber immer Sensorwert Aktualisierungen (auch bei allen vier Instanzen).

z.B.

daikin.1 Set State sensorInfo.indoorTemperature: "20"
daikin.1 1 Values updated

Somit würde ich mal vorsichtig behaupten das die Kommunikation grundsätzlich funktioniert.

Bin jetzt beim Daikin Adapter wieder auf v1.0.2 zurück und werde mal schauen ob die Meldung weiterhin auftritt.

Gruß
Roland