Bedienung und Fehler im Discovery-Adapter

[Homoran]

@crunchip bei beiden ist in deinm Screenshot eine IP hionterlegt. Bei Chromcast sieht es fast so aus als ob da auch gerade wieder der login-Screen offen ist - die IP passt überhaupt nicht in deinen üblichen Range!

Ist das bei Onkyo der konfigurierte Receiver?
Wenn ja, hast du in der Konfig den Hostnamen oder die IP eingetragen oder "leave open for autodetect" belassen?

Hast du mein Edit noch gesehen?

[Jey Cee]

Mobile Adapter ist ja schon lange outdated, der sollte aus der Liste entfernt werden.

[Homoran]

@Jey-Cee Danke!
war auch meine Idee

[Homoran]

Habe eben nochmal meinen Onkyo angeschaltet und Discovery suchen lassen. Auf einmal ging nichts mehr.

eben sehe ich im Log:

2020-08-28 16:31:19.313 - info: discovery.0 (4362) Found 68 addresses
2020-08-28 16:31:59.585 - error: discovery.0 (4362) uncaught exception: Not running
2020-08-28 16:31:59.588 - error: discovery.0 (4362) Error [ERR_SOCKET_DGRAM_NOT_RUNNING]: Not running
at healthCheck (dgram.js:888:11)
at Socket.close (dgram.js:710:3)
at NodeMndp.stop (/opt/iobroker/node_modules/iobroker.discovery/node_modules/node-mndp/dist/index.js:34:25)
at Socket. (/opt/iobroker/node_modules/iobroker.discovery/node_modules/node-mndp/dist/index.js:49:18)
at Socket.emit (events.js:315:20)
at Socket.EventEmitter.emit (domain.js:483:12)
at dgram.js:340:14
at processTicksAndRejections (internal/process/task_queues.js:85:21)
2020-08-28 16:32:00.028 - error: host.ioBroker-Pi2-OG Caught by controller[0]: Error [ERR_SOCKET_DGRAM_NOT_RUNNING]: Not running
2020-08-28 16:32:00.064 - error: host.ioBroker-Pi2-OG Caught by controller[0]: at healthCheck (dgram.js:888:11)
2020-08-28 16:32:00.065 - error: host.ioBroker-Pi2-OG Caught by controller[0]: at Socket.close (dgram.js:710:3)
2020-08-28 16:32:00.066 - error: host.ioBroker-Pi2-OG Caught by controller[0]: at NodeMndp.stop (/opt/iobroker/node_modules/iobroker.discovery/node_modules/node-mndp/dist/index.js:34:25)
2020-08-28 16:32:00.067 - error: host.ioBroker-Pi2-OG Caught by controller[0]: at Socket. (/opt/iobroker/node_modules/iobroker.discovery/node_modules/node-mndp/dist/index.js:49:18)
2020-08-28 16:32:00.068 - error: host.ioBroker-Pi2-OG Caught by controller[0]: at Socket.emit (events.js:315:20)
2020-08-28 16:32:00.069 - error: host.ioBroker-Pi2-OG Caught by controller[0]: at Socket.EventEmitter.emit (domain.js:483:12)
2020-08-28 16:32:00.070 - error: host.ioBroker-Pi2-OG Caught by controller[0]: at dgram.js:340:14
2020-08-28 16:32:00.071 - error: host.ioBroker-Pi2-OG Caught by controller[0]: at processTicksAndRejections (internal/process/task_queues.js:85:21)
2020-08-28 16:32:00.073 - error: host.ioBroker-Pi2-OG instance system.adapter.discovery.0 terminated with code 1 (JS_CONTROLLER_STOPPED)

Der nächste Lauf ging dann durch. Allerdings auch noch was:

2020-08-28 16:45:28.448 - info: discovery.0 (6714) Found 70 addresses
2020-08-28 16:46:19.754 - error: discovery.0 (6714) Cannot detect "sonos" on "192.168.138.59": TypeError: Cannot convert undefined or null to object
2020-08-28 16:46:20.001 - error: discovery.0 (6714) Cannot detect "sonos" on "192.168.138.80": TypeError: Cannot convert undefined or null to object
2020-08-28 16:46:20.103 - error: discovery.0 (6714) Cannot detect "sonos" on "192.168.138.81": TypeError: Cannot convert undefined or null to object
2020-08-28 16:46:20.201 - info: discovery.0 (6714) Discovery finished. Found new or modified 23 instances

Was auch die Meldung ohne IP bei SONOS erklärt, wobei ich aber 4 PLAY:1 im Netz hätte

[crunchip]

@Homoran sagte in Bedienung und Fehler im Discovery-Adapter:

bei der ersten Liste so ist, "empfohlen"

ich würde das ganz weg lassen, derjenige, der entsprechend iobroker nutzen möchte, kann sich seine Adapter selbst nach seinen Bedürfnissen suchen. Nicht jeder erstellt ne Vis, auch nicht jeder verwendet cloud/iot.
Es sollten nur vorhandenen Gerätschaften erkannt werden, so ist zumindest meine Auffassung.

@Homoran sagte in Bedienung und Fehler im Discovery-Adapter:

bei beiden ist in deinm Screenshot eine IP hionterlegt. Bei Chromcast sieht es fast so aus als ob da auch gerade wieder der login-Screen offen ist - die IP passt überhaupt nicht in deinen üblichen Range!

ich hatte früher noch diese IP Range(Fritzbox) mittlerweile UniFi, keine Ahnung warum der Chromecast noch mit seiner alten IP angezeigt wird, hatte den ins neue Wlan eingebunden und isst auch laut Netzwerk und APP im richtigen 10.1.1.x Netz

@Homoran sagte in Bedienung und Fehler im Discovery-Adapter:

ist das bei Onkyo der konfigurierte Receiver?

wie oben gezeigt und beschrieben -- autodiscovery/ leer gelassen beim Onkyo

@Homoran sagte in Bedienung und Fehler im Discovery-Adapter:

Meintest du dass nicht cloud, sondern iot für Alexa angegeben werden sollte?

ich meinte damit, warum wird mir cloud empfohlen, wenn IoT schon vorhanden ist

[Homoran]

@crunchip sagte in Bedienung und Fehler im Discovery-Adapter:

warum wird mir cloud empfohlen, wenn IoT schon vorhanden ist

ohne es zu wissen, behaupte ich mal, dass die s ein alter allgemeiner Satz ist, bevor es iot gab.

@crunchip sagte in Bedienung und Fehler im Discovery-Adapter:

und isst auch laut Netzwerk und APP im richtigen 10.1.1.x Netz

das war er bei mir auch. trotzdem öffnete er immer mal wieder sein Anmelde-Portal

@crunchip sagte in Bedienung und Fehler im Discovery-Adapter:

Nicht jeder erstellt ne Vis, auch nicht jeder verwendet cloud/iot.

das sehe ich ähnlich. Zumindest sollte dann eine etwas umfangreichere Info darüberstehen, wenn möglich in einer "Trennzeile" so etwas wie: für die weitere Nutzung von ioBroker können bei entsprechendem Interesse folgende Adapter empfohlen werden:

[crunchip]

@Homoran sagte in Bedienung und Fehler im Discovery-Adapter:

weitere Nutzung von ioBroker können bei entsprechendem Interesse folgende Adapter empfohlen werden:

@Homoran sagte in Bedienung und Fehler im Discovery-Adapter:

trotzdem öffnete er immer mal wieder sein Anmelde-Portal

blöd gefragt, wie überprüfe ich das am einfachsten, denn sollte es so sein, ist mir das bisher noch nicht aufgefallen

[Homoran]

@crunchip sagte in Bedienung und Fehler im Discovery-Adapter:

blöd gefragt, wie überprüfe ich das am einfachsten,

Ich hatte damals massive Probleme mit dem Fritz mesh und immer wieder mit der Fritz!WLAN app überprüft.
Die zeigte mir dann immer wieder den chromecast als verfügbares WLAN an.

[apollon77]

@Homoran sagte in Bedienung und Fehler im Discovery-Adapter:

2020-08-28 16:31:59.588 - error: discovery.0 (4362) Error [ERR_SOCKET_DGRAM_NOT_RUNNING]: Not running

Das ist in der aktuellsten Discovery gefixt ... ist denke nur noch nicht im Stable

[Homoran]

@apollon77 sagte in Bedienung und Fehler im Discovery-Adapter:

Das ist in der aktuellsten Discovery gefixt ... ist denke nur noch nicht im Stable

Danke!
habe mal ganz frech aus github installiert: v2-3-11 (vorher 2.3.7) der Fehler tart (bisher) nicht wieder auf.

Habe dann noch etwas bemerkt und daher das log auf debug gestellt und es hat mich erschlagen
passt hier gar nicht rein, deswegen als txt im Anhang

Der hm-rpc hat zwar meinen CuxD, hm und hmip rf gefunden , aber nicht mein hm-wired
Das Gateway wird zwar gefunden und auf hm-rpc getestet aber nada:

2020-08-29 17:04:51.419 - debug: discovery.0 (9591) Test ip 192.168.138.75 hm-rpc

Ebenso weiterhin die fehlende Identifikation der Sonos-Boxen

alle 4 IPs werden gefinden (.59,.80,.81 und .152), aber nur die 81 wird identifiziert

1.

Dann kam aber der Fehler:

2020-08-29 17:05:06.189 - error: discovery.0 (9591) Cannot detect "sonos" on "192.168.138.81": TypeError: Cannot convert undefined or null to object

in einem anderen Durchlauf war es die .59

@apollon77
Wo müssen die ISuues hin?
alle (einzeln natürlich) bei discovery oder bei den entsprechenden Adaptern?

Hier der log
disco_log.txt

[apollon77]

@Homoran sagte in Bedienung und Fehler im Discovery-Adapter:

Wo müssen die ISuues hin?
alle (einzeln natürlich) bei discovery oder bei den entsprechenden Adaptern?

in Discovery