NEWS
Auto-discovery
-
Hi BF,
jetzt habe ich eben gerade discovery auf einem Testsystem laufen lassen. Dieses befindet sich auf einer Synology in der Docker Umgebung Dabei ist mir aufgefallen, dass der discovery-Adapter anscheinend nur in dem Netz sucht, in dem der iobroker auch läuft. Wäre es vorstellbar, dem Prozess auch ein oer mehrere (Ziel-)Netze vorzugeben,in denen er suchen soll? Ansonsten wüsste ich nicht, wie er aus einer Dockerumgebung, die ja ein eigenes gebridgtes Netz verwendet "rauskommen" sollte.
-
Sowohl Serielle suche wie auch das mit "sqlite" sollte gefixt sein.
Influxdb findet er jetzt auch
-
jetzt habe ich eben gerade discovery auf einem Testsystem laufen lassen. Dieses befindet sich auf einer Synology in der Docker Umgebung Dabei ist mir aufgefallen, dass der discovery-Adapter anscheinend nur in dem Netz sucht, in dem der iobroker auch läuft. Wäre es vorstellbar, dem Prozess auch ein oer mehrere (Ziel-)Netze vorzugeben,in denen er suchen soll? Ansonsten wüsste ich nicht, wie er aus einer Dockerumgebung, die ja ein eigenes gebridgtes Netz verwendet "rauskommen" sollte. `
Gebridgtes oder geroutetes Netz?
Meine Vermutung:
Ich denke Du wirst ein eigenes Subnetz haben. Die Autodiscovery Funktion wird wohl weitgehend auf Schicht 2 arbeiten.
Dann würde es nur funktionieren, wenn Autodiscover auf einem Satelliten im anderen Subnetz läuft, z.B. auf einem Pi. Interessantes Szenario. Muss ich mal bei Gelegenheit ausprobieren. Die Adapter, die der Satellit dann identifiziert hat müssen dann auf den Master verschoben werden.
Weiter oben hatte ich das Gleiche wie Du gepostet. Bei mir ist es ein eigenes Subnetz unter Docker auf der Diskstation.
btw… wann wird die Version freigegeben? Hatte gestern komische Phänomene. Mal wurde die neuen Versionen (Updates für 13 Adapter und dem Host) gemeldet, nach einem Update eines der angebotenen Adapter waren die Updates dann wieder weg. Das Spielchen dann mehrmals. Repo war Default.
-
Hallo Ingo / Bluefox.
ich hätte dann noch einen Bug (?) im discovery Adapter.
Nachdem letzten Update von Controller und Admin sah ich in den Charts der neuen Installation auf dem NUC einige Kurven nicht.
Nach langem Suchen stellte sich heraus, dass diese Datenpunkte (MemHeapUsed) bei einzelnen Adaptern gar nicht existierten.
Heute habe ich alle Hebel in Bewegung gesetzt diese Datenpunkte wieder hinzuzufügen.
Ein
iobroker install hm-rpc
scheiterte in nahezu allen Varianten daran, dss jetzt immer eine "Meldung" kam: "ist schon die neueste Version - use upgrade"
selbst ein –production und/oder --force half da nicht (dabei weiß ich gar nicht was die bedeuten
)
erst ein
npm install iobroker.hm-rpc
stieß eine neue Installation an.
EIn anschließend ausgeführter stop, upload, start lief auch ohne Probleme durch aber die Datei tauchte immer noch nicht auf.
Nur ein Löschen der Instanzen und erneutes Anlegen fügte die fehlenden Datenpunkte ein.
Jetzt sind alle SQL-Tags bei den Datenpunkten weg …..
Fehlt (hoffentlich) nur noch der javascript Adapter (web, rega, rpc habe ich bereits neu installiert), doch hier will ich nicht schon wieder alle Scripte neu einfügen.
Gibt es veilleicht einen anderen Weg den Adapter dazu zu bewegen die fehlenden Dateien nachzuladen (Ein reinstall.sh würde die Github-Versionen überschreiben!)
Gruß
Rainer
-
Schau mal hier: https://trello.com/c/Mhgs41PP
ist mir vor ein paar Tagen auch bewusst geworden und habs mal im Trello reingestellt …
-
Schau mal hier: https://trello.com/c/Mhgs41PP
ist mir vor ein paar Tagen auch bewusst geworden und habs mal im Trello reingestellt … `
…und? gibt es noch Hoffnung für mein javascript?
Gruß
Rainer
-
so habe bei meinem neuen System auf einem C2 nun discovery getestet, hat alles super geklappt, bis auf eine Fehlermeldung vom Browser bei der web installation, nach klichen auf warten und einer minute gedenkzeit hat es dann doch geklappt. Was mir aufgefallen ist, es wäre super, wenn man die rpc instanzen selber zuordnen könnte. Da ich viel aus der alten installation mitnehme, müsste ich sonst alle scripte und views umschreiben. Aber sonst super Arbeit.
-
selbst ein –production […] half da nicht (dabei weiß ich gar nicht was die bedeuten
) `
Das weist npm dazu an, Abhängigkeiten für die Entwicklung (devDependencies) NICHT mit zu installieren. Die zu installieren ist auf einem Produktivsystem üblicherweise auch nicht nötig oder funktioniert je nach Paket auch nicht. -
habe seit dem update auf die neue version folgende warnungen und error:
discovery.0 2017-04-08 14:39:10.722 warn Stop scan port /dev/ttyS1 discovery.0 2017-04-08 14:39:09.719 warn port /dev/ttyS1 opened: 115200 discovery.0 2017-04-08 14:39:09.718 warn Open port /dev/ttyS1 discovery.0 2017-04-08 14:39:09.717 warn Call port /dev/ttyS1 115200 discovery.0 2017-04-08 14:39:09.717 warn Stop scan port /dev/ttyS1 discovery.0 2017-04-08 14:39:08.714 warn write: 10;VERSION; discovery.0 2017-04-08 14:39:08.713 warn port /dev/ttyS1 opened: 57600 discovery.0 2017-04-08 14:39:08.709 warn Open port /dev/ttyS1 discovery.0 2017-04-08 14:39:08.709 warn Call port /dev/ttyS1 57600 discovery.0 2017-04-08 14:39:00.639 warn Stop scan port /dev/ttyS3 discovery.0 2017-04-08 14:39:00.633 error Error on port /dev/ttyS3: Error: Error: Input/output error, calling write discovery.0 2017-04-08 14:39:00.628 warn port /dev/ttyS3 opened: 115200 discovery.0 2017-04-08 14:39:00.618 warn Open port /dev/ttyS3 discovery.0 2017-04-08 14:39:00.617 warn Call port /dev/ttyS3 115200 discovery.0 2017-04-08 14:39:00.616 warn Stop scan port /dev/ttyS3 discovery.0 2017-04-08 14:39:00.616 error Error on port /dev/ttyS3: Error: Error: Input/output error, calling write discovery.0 2017-04-08 14:39:00.612 warn write: 10;VERSION; discovery.0 2017-04-08 14:39:00.612 warn port /dev/ttyS3 opened: 57600 discovery.0 2017-04-08 14:39:00.609 warn Open port /dev/ttyS3 discovery.0 2017-04-08 14:39:00.608 warn Call port /dev/ttyS3 57600 discovery.0 2017-04-08 14:39:00.599 warn Stop scan port /dev/ttyS2 discovery.0 2017-04-08 14:39:00.597 error Error on port /dev/ttyS2: Error: Error: Input/output error, calling write discovery.0 2017-04-08 14:39:00.591 warn port /dev/ttyS2 opened: 115200 discovery.0 2017-04-08 14:39:00.589 warn Open port /dev/ttyS2 discovery.0 2017-04-08 14:39:00.589 warn Call port /dev/ttyS2 115200 discovery.0 2017-04-08 14:39:00.586 warn Stop scan port /dev/ttyS2 discovery.0 2017-04-08 14:39:00.577 error Error on port /dev/ttyS2: Error: Error: Input/output error, calling write discovery.0 2017-04-08 14:39:00.570 warn write: 10;VERSION; discovery.0 2017-04-08 14:39:00.570 warn port /dev/ttyS2 opened: 57600 discovery.0 2017-04-08 14:39:00.569 warn Open port /dev/ttyS2 discovery.0 2017-04-08 14:39:00.568 warn Call port /dev/ttyS2 57600 discovery.0 2017-04-08 14:39:00.565 warn Stop scan port /dev/ttyS0 discovery.0 2017-04-08 14:39:00.557 warn Stop scan port undefined discovery.0 2017-04-08 14:39:00.521 warn Cannot open port, /dev/ttyS0: Error: Error Resource temporarily unavailable Cannot lock port discovery.0 2017-04-08 14:39:00.517 warn Open port /dev/ttyS0 discovery.0 2017-04-08 14:39:00.516 warn Call port /dev/ttyS0 115200 node-red.0 2017-04-08 14:39:00.350 warn 8 Apr 14:39:00 - [warn] ------------------------------------------------------ node-red.0 2017-04-08 14:39:00.350 warn 8 Apr 14:39:00 - [warn] [rpi-gpio] Info : Ignoring Raspberry Pi specific node node-red.0 2017-04-08 14:39:00.349 warn 8 Apr 14:39:00 - [warn] ------------------------------------------------------ discovery.0 2017-04-08 14:38:59.555 warn write: 10;VERSION; discovery.0 2017-04-08 14:38:59.551 warn port /dev/ttyS0 opened: 57600 discovery.0 2017-04-08 14:38:58.516 warn Open port /dev/ttyS0 discovery.0 2017-04-08 14:38:58.514 warn Call port /dev/ttyS0 57600
-
Diese Warnungen und Fehler bei dem Scannen der Seriellen Ports ist "normal"
-
ich habe ein Problem mit dem Discovery Adapter. Er findet 13 Geräte aber bleibt bei 1 Service gefunden stecken und es geht einfach nicht weiter.
Installiert ist iobroker auf einem rpi3 zuvor hatte ich es auf einer Windows umgebung unter QNAP Nas dort lief alles gut und auch durch.
Was ist denn falsch gelaufen??
-
Auch hier die Frage; was sagt das log?
-
Hallo Bluefox,
Du warst so nett und hast den LG-TV Adapter mit hinzugefügt. Ich habe das Ganze jetzt mal getestet, allerdings fügt er den LG Fernseher nur als PING-Device hinzu:
discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 sql discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 sonos discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 samsung discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 ping DETECTED! discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 ping discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 openhab discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 nut discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 miele discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 megad discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 lightify discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 lgtv discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 landroid discovery.0 2017-05-24 09:02:53.754 debug Test 192.168.178.60 knx discovery.0 2017-05-24 09:02:53.739 debug Test 192.168.178.60 influxdb
Ich würde das gern weiter verfolgen und frage mich, ist es irgendwie möglich, den XML-Response des
Discovery-Adapters zu loggen, so dass ich mal schauen kann, was da vom Fernseher zurückgegeben wird?