Monatsrückblick Januar/Februar 2026 ist online!

[Homoran]

@kmxak:

In den Logs steht ich hätte immer noch 0.16 `

Was steht im Reiter Hosts?

hattest du vor dem Upgrade iobroker gestoppt?

Gruß

Rainer

[kmxak]

Dort steht:

0.17.1(Ausgeführt: 0.16.2)

[Homoran]

@kmxak:

0.17.1(Ausgeführt: 0.16.2) `
:mrgreen:

Dann läuft sie auch nicht.

Jetzt kannst du alles mögliche versuchen, sicher funktioniert IMHO nur ein reboot des RasPi (oder was du da hast)

Gruß

Rainer

[kmxak]

da hab ich mir doch gerade das ganze system zerschossen :lol:

Der Snapshot von vorhin hat es mir dann aber leicht gemacht.

Nun geht es.

Ich danke dir für die Hilfe

So nach erster suche habe ich folgenden Fehler:````
iobroker 2017-03-18 19:30:26.053 info exit 5
iobroker 2017-03-18 19:30:26.045 error host.FHEM Unknown packetName sqlite
iobroker 2017-03-18 19:30:25.215 info install sqlite

Kann ich leider nichts mit anfangen vielleicht hilft es euch ja

nochwas zur info

discovery.0 2017-03-18 19:33:59.635 error Cannot detect "zwave" on "ttyS0": TypeError: tools.testSerialPort is not a function
discovery.0 2017-03-18 19:33:59.634 error Cannot detect "rflink" on "ttyS0": TypeError: tools.testSerialPort is not a function

[Heinzelmaennchen]

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.

[apollon77]

Sowohl Serielle suche wie auch das mit "sqlite" sollte gefixt sein.

Influxdb findet er jetzt auch

[ruhr70]

@Heinzelmaennchen:

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.

[Homoran]

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

[apollon77]

Schau mal hier: https://trello.com/c/Mhgs41PP :-) ist mir vor ein paar Tagen auch bewusst geworden und habs mal im Trello reingestellt …

[Homoran]

@apollon77:

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

[Meistertr]

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.

[AlCalzone]

@Homoran:

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.

[kmxak]

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

[apollon77]

Diese Warnungen und Fehler bei dem Scannen der Seriellen Ports ist "normal"

[badplay]

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??

[apollon77]

Auch hier die Frage; was sagt das log?

[SchuetzeSchulz]

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?