FHEM Adapter

[sticks]

@LausiD

Hallo,

bei mir läuft der FHEM-Adapter (v1.6.3) im iobroker (v5.3.8 ; NPM 8.11; Node.JS 16.15.1 auf Raspi 4) an sich stressfrei.

Ich habe nur das Problem das mein gesamtes iobroker-Log fast nur aus FHEM-Adapter Warnmeldungen zum Datentyp besteht und täglich auf einige hundert Megabyte anwächst,so dass Probleme anderer Adapter im Log unter den ganzen FHEM-Adapter Meldungen untergehen/sich das Log kaum noch herunterladen/analysieren lässt. - Ich habe schon versucht ob ich das Logging vom FHEM-Adapter innerhalb iobroker ganz abstellen kann (Alles in den Log Settings auf "false" setzen, das brachte aber keinen Erfolg.) - Ich habe auch schonmal den gesamten FHEM-Adapter samt Objektbaum gelöscht und frisch installiert. Fehlermeldungen bleiben leider.

Es geht da um Type-Info-Meldungen, mehrere dutzend pro Sekunde im Dauerloop:

Nach dem komplett löschen & neuinstallieren bekam ich auch noch diese Info, dem Developer dies mitzuteilen:

Zwischenzeitlich hatte ich auch mal den Adapter von Github direkt installiert, da gab es dann immer Adapterabstürze und diese Meldung:

Der "obj0" Fehler ist/war neu und tauchte erst beim Github-Adapter auf, ist dann aber auch wieder verschwunden, nachdem ich den Github-FHEM-Adapter deinstalliert und dann ganz normal aus dem iobroker-REPO installiert habe.

Jetzt bin ich wieder beim Stand vorher das das Log einfach von Type-Warnmeldungen im Millisekunden-Takt geflutet wird.

Obwohl ich das hier so eingestellt habe:

Ideen wie ich etwas gegen das Dauer-Logging tun, oder sogar die "Type"-Warnmeldung beheben kann ? - Vielen Dank.

[LausiD]

@sticks
Die Adapterabstürze mit "objO is not defined" hatte ich auch
Habe auf github eine schnelle Abhilfe abgelegt.
Bitte teste nochmal mit der Github Verison...

Danke und Gruß
LausiD

[sticks]

@lausid
Wie gewünscht habe ich nochmal die Github Version installiert, und kann bestätigen, das die OBJ0 Abstürze nun weg sind.
Das eigentliche Problem mit den Logeintrögen habe ich aber leider immer noch.
Ich wäre auch damit glücklich wenn ich das Logging im FHEM-Adapter oder in den Objekten ganz auf "false" setzen könnte und nur bei Bedarf aktiviere.

Bin für jeden Tipp dankbar.

[LausiD]

@sticks
Die o.g. Meldungen werden durch den JS-Controller erzeugt und können somit nicht im FHEM Adapter deaktiviert werden
Für fhem.0.HUEDevicexx sollte es mit der Version von Github keine Fehler mehr geben.
Voraussetzung ist fhem.0.info.Configurations.autoType=true
Damit werden Type der Objekte (number,string usw) in Abängigkeit der Adapterversion gesetzt.

Gruß
LausiD

[sticks]

@lausid
Hi, ich kann nach erster Protokoll-Durchsicht bestätigen das die Type-Fehler aus dem HUE-Adapter quasi verschwunden ist. Allerdings habe ich tausende Type-Fehler noch vom FHEM "ECHODEVICE"-Adapter für Alexa (99% des Logs), was immer schon das Hauptproblem bezüglich Logmenge war da sich die Type-Fehler alle paar Sekunden endlos loopen.

[LausiD]

@sticks
Danke für die Rückmeldung
Habe nach Doku Adapter Echodevice mal versucht die Meldungen in Griff zu bekommen.
Bitte teste nochmal die github Version.......

Gruß
LausiD

[sticks]

@lausid

Hi, habe nochmal die neueste Github Version installiert (Build-Date 15.07.22), aber leider noch keine Änderung bezüglich der Type-Fehler bei den ECHO-Devices.

[LausiD]

@sticks sagte in FHEM Adapter:

aber leider noch keine Änderung bezüglich der Type-Fehler bei den ECHO-Devices.

Sorry, kann hier den Adapter Echodevice nicht testen
Hast du mal ein betroffenes Objekt z.B. fhem.0.ECHO_Wohnzimmer gelöscht und durch Neustart Fhem Adapter neu anlegen lassen?
fhem.0.info.Configurations.autoType steht auf true?

Gruß
LausiD

[sticks]

@lausid
Hi, ja, ich habe bei meinen Tests nach Github-Update immer den kompletten "FHEM"-Objektbaum löschen und neu anlegen lassen (Nach Update der Github-Version).
Und "AutoType" wird dann ja im "default" immer auf "True" gesetzt, was auch jetzt der Fall ist.

[LausiD]

@sticks
OK muss es eine andere Ursache haben
Kannst du mir aus FHEM die Ausgabe von "jsonlist2 .ECHO_Wohnzimmer" zukommen lassen?
Damit kannn ich zum Test das Objekt bei mir anlegen lassen.......

[sticks]

@lausid

Hi, ich hab dir die Ausgabe mal als Chat gesendet, da ich nicht weiß ob dort eventuell "geheime" Informationen zu meinem Amazon Account mit drin sind.

[sticks]

ECHODEVICE Log-Problem mit der neuesten GitHub Version des FHEM-Adapters jetzt gelöst.
Danke LausiD.

[LausiD]

@sticks
Danke für die Rückmeldung und den geduldigen Test

Gruß
LausiD

[ok1]

Re: FHEM Adapter

@LausiD , ich erhalte seit heute Abend folgende Fehlermeldungen im Log, so dass der fhem-Adapter nicht startet.
Das System wurde nicht verändert, der aktuellste fhem-Adapter ist installiert und lief bislang einwandfrei.
(eine zweite fhem-Instanz fhem.1 startet dagegen einwandfrei ?!)

Vielen Dank schon jetzt für einen Hinweis !

fhem.0
2022-10-23 23:16:37.756	info	State value to set for "fhem.0.info.Configurations.allowedInternals" has to be type "string" but received type "boolean"

fhem.0
2022-10-23 23:16:37.750	warn	Terminated (UNCAUGHT_EXCEPTION): Without reason

fhem.0
2022-10-23 23:16:37.748	debug	Plugin sentry destroyed

fhem.0
2022-10-23 23:16:37.746	info	terminating

fhem.0
2022-10-23 23:16:37.737	error	state.val.split is not a function

fhem.0
2022-10-23 23:16:37.736	error	TypeError: state.val.split is not a function at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.fhem/main.js:529:44) at processImmediate (internal/timers.js:463:21)

fhem.0
2022-10-23 23:16:37.735	error	uncaught exception: state.val.split is not a function

fhem.0
2022-10-23 23:16:37.731	warn	TypeError: state.val.split is not a function at Immediate.<anonymous> (/opt/iobroker/node_modules/iobroker.fhem/main.js:529:44) at processImmediate (internal/timers.js:463:21)

fhem.0
2022-10-23 23:16:37.728	warn	Exception: TypeError: state.val.split is not a function

fhem.0
2022-10-23 23:16:37.726	debug	[main] [getConfigurationsSYNC] [getConfig] info.Configurations.allowedInternals: {"val":true,"ack":true,"ts":1666559762075,"q":0,"from":"system.adapter.fhem.0","user":"system.user.admin","lc":1666547534818}

fhem.0
2022-10-23 23:16:37.717	debug	[main] [getConfigurationsSYNC] [getConfig] info.Configurations.allowedInternals (TYPE,NAME)

[ioB_Daniel]

Hallo,
ich habe vorgestern eine Verbindung zu einer bestehenden Fhem Installation aufgebaut.
Nun bekomme ich meinen Log mit lauter Meldungen zugemüllt.

Wie kann ich diese Meldungen abstellen?

Vielen Dank
Daniel

[DJMarc75]

@iob_daniel sagte in FHEM Adapter:

Wie kann ich diese Meldungen abstellen?

indem Du das LOGLevel der Instanz auf mindestens "warn" setzt !

[ioB_Daniel]

@DJMarc75 Vielen Dank!
Wenn immer alles so einfach gehen würde!

[LausiD]

@ok1 sagte in FHEM Adapter:

ich erhalte seit heute Abend folgende Fehlermeldungen im Log, so dass der fhem-Adapter nicht startet.

Welchen Wert hat info.Configurations.allowedInternals?

Hast du die Version von github (16.07.22) ?
Die zweite Instanz geht auf eine andere FHEM Installation?

[Rickman]

Hallo zusammen,

kurze Frage, da ich per Suche nichts gefunden habe.
Ist es möglich per fhem.0.Info.Commands.SendFHEM einen regSet Befehl zu senden, der dann im Gerät auch übernommen wird?
Wenn ich darüber folgenden Befehl sende, steht zwar kurz im Register set_100%, aber wechselt dann wieder auf die in FHEM selbst eingestellten 50%.

set HM_728021_Bright regSet shOnLevel 100 HM_68E334_Sw_01

Es scheint mir, als ob eine Registeränderung über iobroker nicht möglich ist, kann das sein?

Gruß,
Richy

[Rickman]

Niemand eine Idee?