NEWS

Hallo,

den Fehler mit dem "enums.room.Technikraum" konnte ich nun finden und auch lösen. Bisschen schwierig zu erklären aber ich versuche es einmal: Es waren Objekte von einer Siemens LOGO, die zwar in der Adapterinstanz auf den Raum (Technikraum) zugewiesen waren aber bei den Objekten war keine Zuordnung auf den Raum (Technikraum) vorhanden. Woher das kommt ist mir unklar, da ich noch mehrere LOGO´s im Einsatz habe, bei denen so etwas nicht aufgetreten ist. Ich habe nun bei den Objekten den Raum angegeben und nun ist Ruhe.

Bzgl. des 2. Fehlers mit dem doppelten Stop hat @foxriver76 ja schon geantwortet.

Somit kennzeichne ich dieses Thema hier für mich als gelöst.

Edit: Peinlich, wie kennzeichne ich im neuen Forum ein Thema als gelößt 🤔

Gruß Steffen

@arteck
Danke! So etwas ähnliches habe ich heute morgen auch überlegt, das dann aber wieder verworfen - denn es hatte ja gestern schon funktioniert und ich hatte ja schon erfolgreich mehrere Sensoren wieder angelernt.
Aber bei meinen ganzen verzweifelten Wiederherstellungs- und Backup-Versuchen habe ich da wohl was übersehen/zerschossen. Durch deinen Hinweis habe ich jetzt nochmal alles mehrfach kontrolliert und neu durchgereicht: Erfolgreich!

Aktuell geht´s also positiv weiter: DerStick ist wieder da (!) und ich habe auch die sheperd-Datei mal rüberkopiert. Jetzt sind alle Zigbee-Geräte da, 3 machen noch Probleme, die kann ich aber noch nicht eingrenzen. Die werde ich mal neu anlernen.

Danke euch beiden!!! 👍

mqtt und sonoff adapter muessen auf verschiedene Ports liegen, als Standard ist leider bei beiden 1883 gesetzt, da beide mit dem mqtt-protokoll arbeiten. Stelle einen Adapter auf einen anderen Port, z.bsp. 1886, und dann klappts.

Ich habe 60 Devices, die mit dem sonoff Adapter auf Port 1883 kommunizieren, und 35, die mit mqtt auf Port 1886 reden.
Läuft.
Die Adapter werden erst grün, wenn der erste Client sich angemeldet hat, also nicht wundern, wenn man den Server konfiguriert und dann erstmal gelb ist.
Mehr findest du auch im Protokoll in iobroker ( /opt/iobroker/log da sind alle logfiles von iobroker täglich abgelegt).

nach längeren herumprobieren habe ich es geschafft.

Habe alle Dateien in /opt/iobroker/node_modules/.bin/iobroker per Hand gelöscht und update Prozess neu gestartet.

Mach erstmal n Backup, du weißt, nur wer ein Backup hat, kann beruhigt schlafen..

@arteck Jo.. wurde kurz nach dem ich das eingestellt hatte schon gemerged. Als ich hier die Notiz hinterließ wusste ich nicht wie fix das geht.

A.

Mittlerweile geht es wieder. Ein Reboot des ganzen Systems, danach ging es dann.

☺

Okay, hat sich erledigt. Ich vergaß, dass es sich um eine Windows-Maschine handelt. Ein Reboot löste mal wieder das Problem.

Jetzt zu deinem Pi 1B+
Willst du den wirklich für ioBroker nutzen?
Nein.
Ich habe jetzt erst mal zum Lernen und Üben meinen Garten-Raspi, ein RasPi 2B auf dem Kodi läuft, zweckentfremdet. Bis zum Frühjahr hab ich dann was "Besseres" 😉

Müsste ich auch erst suchen.
War gleich der 5 Eintrag wenn man hier die Suche benutzt😜
[Link Text]https://forum.iobroker.net/topic/15247/aufruf-neuer-adaper-google-sharedlocations(Link Adresse)

Naja, den Grund rausfinden ist doch viel besser. Was sagt das ioBroker Log denn so wenn das passiert?

Dann melde es doch mal im GitHub als Issue

Wozu brauchst Du die reinstall? ein "nm rebuild" macht das gleiche 🙂

die Lösung ist relativ simpel: CCU Update machen. Ich war auf der 2.35.16. Mit der aktuellen Version 2.41.5 ist das Log ruhig.

OK Danke, Asche auf mein Haupt😵
Dann versuche ich mal den anderen Weg!

Kein Wunder. Wenn npm die Installation von ioBroker mit einem Fehler abbricht, würde ich nicht erwarten, dass es installiert ist.

Was passiert bei npm i -g npm --verbose?