Ich hatte dieses Problem auch schon öfters. Hatte noch nicht die Muße auf Ursachenforschung zu gehen. Bei mir läuft der Unifi Controller in einem proxmox LXC Container, welcher regelmäßig auch ein Backup Nachts macht. Ich vermute, dass es damit zusammenhängt. Hab gerade mal mein Log rausgesucht. Um 4 Uhr Nachts für dier Unifi Controller angehalten und proxmox macht ein Backup. Das kommt dann im ioBroker Log 12 Sep 2021 04:02:33.610 host.ioBroker Do not restart adapter system.adapter.unifi.0 because restart loop detected 12 Sep 2021 04:02:33.609 host.ioBroker Restart adapter system.adapter.unifi.0 because enabled 12 Sep 2021 04:02:33.608 host.ioBroker instance system.adapter.unifi.0 terminated with code 6 (UNCAUGHT_EXCEPTION) 12 Sep 2021 04:02:33.606 host.ioBroker Caught by controller[0]: at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1144:16) 12 Sep 2021 04:02:33.605 host.ioBroker Caught by controller[0]: Error: connect EHOSTUNREACH 192.168.178.60:8443 12 Sep 2021 04:02:33.603 host.ioBroker Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: 12 Sep 2021 04:02:29.059 unifi.0 (5543) UniFi adapter is ready 12 Sep 2021 04:02:28.953 unifi.0 (5543) starting. Version 0.5.10 in /opt/iobroker/node_modules/iobroker.unifi, node: v12.21.0, js-controller: 3.3.15 12 Sep 2021 04:02:23.915 host.ioBroker instance system.adapter.unifi.0 started with pid 5543 12 Sep 2021 04:01:53.295 host.ioBroker Restart adapter system.adapter.unifi.0 because enabled 12 Sep 2021 04:01:53.293 host.ioBroker instance system.adapter.unifi.0 terminated with code 6 (UNCAUGHT_EXCEPTION) 12 Sep 2021 04:01:53.280 host.ioBroker Caught by controller[0]: at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1144:16) 12 Sep 2021 04:01:53.279 host.ioBroker Caught by controller[0]: Error: connect EHOSTUNREACH 192.168.178.60:8443 12 Sep 2021 04:01:53.278 host.ioBroker Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: 12 Sep 2021 04:01:47.638 unifi.0 (5521) UniFi adapter is ready 12 Sep 2021 04:01:47.551 unifi.0 (5521) starting. Version 0.5.10 in /opt/iobroker/node_modules/iobroker.unifi, node: v12.21.0, js-controller: 3.3.15 12 Sep 2021 04:01:40.954 host.ioBroker instance system.adapter.unifi.0 started with pid 5521 12 Sep 2021 04:01:33.426 host.ioBroker instance system.adapter.daswetter.0 terminated with code 0 (NO_ERROR) 12 Sep 2021 04:01:12.144 host.ioBroker instance system.adapter.ical.3 terminated with code 0 (NO_ERROR) 12 Sep 2021 04:01:09.992 host.ioBroker Restart adapter system.adapter.unifi.0 because enabled 12 Sep 2021 04:01:09.990 host.ioBroker instance system.adapter.unifi.0 terminated with code 6 (UNCAUGHT_EXCEPTION) 12 Sep 2021 04:01:09.988 host.ioBroker Caught by controller[0]: at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1144:16) 12 Sep 2021 04:01:09.987 host.ioBroker Caught by controller[0]: Error: connect EHOSTUNREACH 192.168.178.60:8443 12 Sep 2021 04:01:09.985 host.ioBroker Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:

@martin-72 sagte in Test Adapter Tradfri v3.0.x: ConBee II, CC2531 USB Zigbee Module oder noch etwas anderes? nix von beidem.. nimm entweder was aus dem Marktplatz oder das TI Baord cc26x2r die Reichweite im Zigbee wird durch geschicktes platzieren von mehrerer Router bestimmt.. nicht von der Antenne die an dem stick dran hängt

@reni2 sagte in [Neuer Adapter] Klima Gree,Argo,...: Mit welcher Version sollte es denn funktionieren? Ich habe nicht behauptet, dass es in irgendeiner Form an der nodeJS-Version liegt.

@lobomau Jepp, wird über kurz oder lang die offizielle Version. Bitte Fragen dazu im anderen Thread weiter besprechen, der hier ist noch für 0.1.x

@garfonso Ok, prima. Das hört sich gut an. Viele Grüße Andy

Morgen Nacht oder Sonntag kommt die GitHub version auf npm wenn keiner mehr was findet

@xwing Du musst das objekt vehicle_state aber hier ist das falsche Forum um das zu diskutieren

@old_engineer Leg das doch mal als GitHub issue im material Adapter an

@mickym Das Bild sollte nur den Eingang des Flow zeigen, weil nach dem owntracks-node erst wieder ein Json gemacht werden muss. Nur, falls jemand mal was nachbauen will mit Payload encryption. Ohne die ging der Flow, den ich gefunden und angepasst hatte problemlos, nur mit halt zuerst nicht mehr. Aber wie gesagt, alles läuft nun. Gruß, Jürgen

@crunchip Na dann kennste ja das Spiel ;-) PS: hjhjjkdrghp806749ß8uPI/&(

Heute kam Email von dicovergy Hat das Auswirkungen auf den Adapter? API-Änderung: Neue, vereinfachte Notation für RLM-Stromzähler des Fabrikanten EMH. Auch anwendbar für alle anderen RLM-Zähler API-Änderung: RLM-Zähler Sehr geehrte(r) Frau/Herr , Heute möchten wir eine Änderung ankündigen, die sich auf die Notationen auswirkt, mit denen die Messwerte einiger RLM-Stromzähler in unserem System gespeichert sind und wie diese über die API abgerufen werden können. Für alle von dem Fabrikanten EMH hergestellten RLM-Zähler wurden die Felder bisher in OBIS-Notation gespeichert und die Werte auf 1 000 000 Einheiten pro kWh festgelegt. Für alle anderen Zähler verwenden wir im System anstatt OBIS einen menschenlesbaren Namen – energy – und 10 000 000 000 Einheiten pro kWh. Fortan werden allerdings bei allen neu installierten EMH RLM-Zählern keine OBIS-Notationen mehr verwendet, sondern die Daten mit derselben menschenlesbaren Notation – energy – und mit derselben Skalierung wie bei anderen Zählern gespeichert. Zur Veranschaulichung: Nehmen wir zum Beispiel an, es wurden 12 kWh von einem RLM-Zähler des Fabrikanten EMH gemessen. Diese Daten sehen derzeit so aus: Feldname: 1.8.0 Wert: 12 000 000 Nach der Änderung werden die Daten wie folgt aussehen: Feldname: energy (normalisiert auf denselben Namen wie bei allen anderen Zählern) Wert: 120 000 000 000 (normalisiert auf den gleichen Faktor wie bei allen anderen Zählern) Bei Anwendungen, die auf unserer API basieren und Messwerte von EMH RLM-Stromzählern abfragen, müssen diese Felder entsprechend angepasst werden. Obwohl diese Änderung nur die oben erwähnten RLM-Zähler von EMH betrifft, möchten wir auch anderen interessierten Kunden die Möglichkeit bieten, dieses normalisierte Format für alle ihre RLM-Zähler zu übernehmen. Die Änderung könnte zukünftige Entwicklungen und Integrationen auf Kundenseite erleichtern, indem es nicht mehr notwendig wäre, mit zwei Branchencodes zu arbeiten (einem für RLM-Zähler und einem für SLP-Zähler), sondern alle Daten könnten einheitlich abgerufen werden. Dies ist besonders vorteilhaft für Kunden, die mit der API arbeiten und sowohl über SLP- als auch RLM-Zähler verfügen. Wollen Sie diese Änderung für Ihre bereits oder künftig installierten RLM-Zähler übernehmen, können Sie sich gerne an Ihren Ansprechpartner bei Discovergy wenden oder einfach eine E-Mail an unseren Vertrieb (vertrieb@discovergy.com) schicken. Bei Fragen zu den in diesem Artikel beschriebenen Änderungen schicken Sie gerne eine E-Mail an api@discovergy.com. Wir werden uns bemühen, Ihre Frage schnellstmöglich zu beantworten. Herzliche Grüße Ihr Discovergy-Team

@hamburgmeineperle https://forum.iobroker.net/topic/45942/vis-inventwo-v3-x-x?_=1627507256386

Wird an dem Adapter noch gearbeitet? Hätte auch großes Interesse daran! Leider hab ich selbst keine Ahnung wie man so einen Adapter schreibt.

@cino Hm, Du könntest evtl. die Szene über eine (in der App) angelegte Routine aufrufen. Diese Routine kannst Du dann per Adapter auslösen.

cc2538 von Arteck [image: 1626954833268-screenshot-2021-07-22-135326.png]