@sigi234 said in WARUM? 1 Adapter löschen - 3 ändern sich: @JB_Sullivan Kann ich bestätigen, es tritt aber nur auf wenn man im Reiter Adapter mit dem Papierkorb-Symbol löscht. Im Reiter Instanzen aber nicht. weil Du dann auch nur die Instanz löschst und nicht den Adapter. Selbst wenn Du keine Instanzen hast - ist der Adapter noch installiert. Es gab wenn man best. Updates gemacht hatte - den Zwang auch Admin, Info, Dev. Disc. upzugraden. Ich kann mir nur vorstellen, dass diese Abhängigkeiten bei Löschen des Adapters auch wieder rückgängig gemacht werden

@janachti sehr gut

@OliverIO Ist allerdings schon an einigen anderen Stellen schon länger (schon immer?) so gewesen. Zumindest stammt der widget-Code aus Zeiten, als es ein separates Widget-Template gab. Die Änderung macht es nur einheitlich an der einen Stelle, wo es noch nicht so war.

warum verwendest du nicht die aktuelle Zigbee Adapter Version 1.0.2 und mach auch noch einen Hardreset in der Instanz, die DB der Geräte befindet sich ebenfalls am Stick! mach als erstes den Hardreset und wenn das nichts hilft probier mal die Version 1.0.2 [image: 1584463884485-c6c742cf-287a-45dc-a63b-1bc7d7ae63c7-grafik.png]

@R1Snake Hast du den Ricksaw Adapter installiert? Den braucht's dazu wenn ich mich recht erinnere

Ja Danke für die Unterstützung. Ich habe erst mal unterschiedliche IDs verwendet.

@ilovegym sagte in Alexa2.0 Absturz nach ioB Neustart: @JB_Sullivan ihr habt aber gelesen, dass die git Version unter Entwicklung ist und daher noch viele Fehler hat?? Die Kategorie heißt ja Error/Bug - also es geht nicht darum, das ich ein produktives System nicht stabil betreiben kann, sondern das ich einen Fehler mit einer bestimmten Version habe, was ja für den Entwickler durchaus interessant sein könnte. .... und da es offensichtlich ja noch jemanden gibt, der das gleiche Problem hat, muss es ggf. in dem Adapter selber, etwas geben, was noch nicht so rund läuft.

@foxriver76 Danke für Deine Antwort Es stört halt nur etwas wenn so eine Warnung auftritt. Wenn man es aber weiß ist ja alles gut. Gruß TM

Hier noch meine finale Antwort: Ich bin von meinem PI3 auf einen PI4 mit 4GB Ram umgezogen (ohne Neuinstallation). Seit dem ist dieses Problem nicht mehr aufgetreten, daher war die Vermutung von @Homoran goldrichtig, dass dem System der RAM in diesen Situationen ausgegangen ist und das System daher nicht mehr reagiert hat.

.kurze Info...habe jetzt den Raspi mangels Zeit einfach mal ein paar Tage in Ruhe gelassen.. Letzter Stand war, dass der Javascriptadapter sich mit Fehlern installieren ließ, aber nicht bei den Adaptern erschien. Eben Interface aufgerufen...siehe da er ist da und grün....Script gestartet...geht Verrückt....selbstheilende Technik.....klasse

Problem ist gelöst. Es war die Firewall in der Raspimatic. Remote Homematic-Script API: muß auf Eingeschränkt gestellt werden. Sorry Das habe ich mir so oft angesehen und den Wald vor lauter Bäumen nicht gesehen ;-)

Danke für den Hinweis. Habe auf 1.16.3 upgedatet - sieht sehr gut aus. Aktuell keine error Einträge im log. Werde noch ein wenig beobachten. Vielen Dank.

Re: Umzug Windows -> Pi 4 - Shellys werden nicht gefunden Hier noch das debuglog des Shelly-Adapters: 2020-03-14 21:47:30.490 - info: host.raspberrypi instance system.adapter.shelly.0 started with pid 1782 2020-03-14 21:47:31.661 - debug: shelly.0 (1782) Redis Objects: Use Redis connection: 127.0.0.1:9003 2020-03-14 21:47:31.705 - debug: shelly.0 (1782) Objects client ready ... initialize now 2020-03-14 21:47:31.725 - debug: shelly.0 (1782) Objects create System PubSub Client 2020-03-14 21:47:31.727 - debug: shelly.0 (1782) Objects create User PubSub Client 2020-03-14 21:47:31.728 - debug: shelly.0 (1782) Objects client initialize lua scripts 2020-03-14 21:47:31.743 - debug: shelly.0 (1782) Objects connected to redis: 127.0.0.1:9003 2020-03-14 21:47:31.748 - debug: shelly.0 (1782) objectDB connected 2020-03-14 21:47:31.750 - debug: shelly.0 (1782) Redis States: Use Redis connection: 127.0.0.1:9002 2020-03-14 21:47:31.757 - debug: shelly.0 (1782) States create User PubSub Client 2020-03-14 21:47:31.760 - debug: shelly.0 (1782) States create System PubSub Client 2020-03-14 21:47:31.769 - debug: shelly.0 (1782) States connected to redis: 127.0.0.1:9002 2020-03-14 21:47:31.770 - debug: shelly.0 (1782) statesDB connected 2020-03-14 21:47:32.674 - info: shelly.0 (1782) starting. Version 3.2.2 in /opt/iobroker/node_modules/iobroker.shelly, node: v12.16.1 2020-03-14 21:47:32.722 - info: shelly.0 (1782) Starting Shelly adapter in CoAP modus. 2020-03-14 21:47:32.786 - info: shelly.0 (1782) Listening for Shelly packets in the network 2020-03-14 21:47:38.728 - debug: shelly.0 (1782) CoAP status package received: {"3332":"SHSW-1#F39F06#1","3412":38400,"3420":1024,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,118,0]]} 2020-03-14 21:47:38.731 - debug: shelly.0 (1782) Status update received for SHSW-1#F39F06#1: {"G":[[0,112,0],[0,118,0]]} 2020-03-14 21:47:38.733 - debug: shelly.0 (1782) CoAP device description request for SHSW-1#F39F06#1 to 192.168.2.115(0) 2020-03-14 21:47:38.768 - debug: shelly.0 (1782) CoAP response: {"3332":"SHSW-1#F39F06#1"} 2020-03-14 21:47:38.769 - debug: shelly.0 (1782) Device description received: {"3332":"SHSW-1#F39F06#1"} / {"blk":[{"I":0,"D":"Relay0"},{"I":1,"D":"Sensors"}],"sen":[{"I":112,"T":"S","D":"Switch","R":"0/1","L":0},{"I":118,"T":"S","D":"Input","R":"0(off)/1(on)/2(longpush)","L":0}]} 2020-03-14 21:47:38.774 - info: shelly.0 (1782) Shelly device 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) with CoAP connected! 2020-03-14 21:47:38.801 - debug: shelly.0 (1782) CoAP Message for SHSW-1#F39F06#1 : {"G":[[0,112,0],[0,118,0]]} 2020-03-14 21:47:38.802 - debug: shelly.0 (1782) Create State : SHSW-1#F39F06#1.Relay0.Switch, Payload: {"G":[[0,112,0],[0,118,0]]} for SHSW-1#F39F06#1 2020-03-14 21:47:38.802 - debug: shelly.0 (1782) Create State : SHSW-1#F39F06#1.Relay0.Switch, Payload: [object Object] for SHSW-1#F39F06#1 2020-03-14 21:47:38.803 - debug: shelly.0 (1782) State change : SHSW-1#F39F06#1.Relay0.Switch, Value: false for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.048 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.Relay0.AutoTimerOff, Value: 900 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.050 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.Relay0.AutoTimerOn, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.051 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.version, Value: "20200312-123713/v1.6.1@112262fd" for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.155 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.ext.temperatureC1, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.156 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.ext.temperatureC2, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.157 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.ext.temperatureC3, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.158 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.ext.temperatureC4, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.158 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.ext.temperatureF1, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.159 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.ext.temperatureF2, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.160 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.ext.temperatureF3, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.161 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.ext.temperatureF4, Value: 0 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.161 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.firmware, Value: false for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.162 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.uptime, Value: "00:35:45" for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.163 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.hostname, Value: "192.168.2.115" for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) 2020-03-14 21:47:39.164 - debug: shelly.0 (1782) Set state SHSW-1#F39F06#1.rssi, Value: -64 for 192.168.2.115 (shelly1 / shelly1-F39F06 / SHSW-1#F39F06#1) Und hier die ifconfig: wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.2.141 netmask 255.255.255.0 broadcast 192.168.2.255 inet6 fe80::efe7:4e69:b994:3b89 prefixlen 64 scopeid 0x20<link> inet6 2003:f9:13ca:e54c:fb18:66fb:da85:3b35 prefixlen 64 scopeid 0x0<global> ether dc:a6:32:7b:7c:15 txqueuelen 1000 (Ethernet) RX packets 20944 bytes 2774911 (2.6 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 29523 bytes 13543653 (12.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 EDIT: Mir war der Speedport Smart3 schon länger ein Dorn im Auge, weshalb ich meine Fritzbox 7490 wieder rausgekramt habe. Jetzt klappt alles ohne Probleme! Denke, dass der Speedport ein Problem mit Coap bzw. Multicast bei WLAN <-> WLAN hat...

@joergfrde Das hört man doch gern.

Hat sonst wirklich keiner das Problem? Was ich rausgefunden habe: Nicht Version 4.4 ist schuld, sondern Version 4.3.6, konkret commit e3ecffe88ac2b48a6fde8ff666f18844a045bfd8 im javascript adapter. Und kaputt ist nicht der Adapter selbst, sondern das virtual-tsc Modul, dort funktioniert Release 0.4.6 noch, 0.5.0 nicht mehr. Leider ist der commit von 0.4.6 auf 0.5.0 ziemlich groß, so daß es sich nicht so einfach rausfinden läßt, was kaputt ist.

@chiroptera hab auch nen Tester thread auf gemacht. Feedback bitte dort

shit Ist mir echt durch gegangen :-)