[Gelöst] Fehlende Devices und Zustände im FHEM-Adapter
-
Systemdata Bitte Ausfüllen Hardwaresystem: NUC mit Proxmox-VM Arbeitsspeicher: 3GB Festplattenart: VM 60 GB Betriebssystem: Ubuntu Node-Version: 12.20.0 Nodejs-Version: 12.20.0 NPM-Version: 6.14.8 Installationsart: Skript Image genutzt: Nein Ort/Name der Imagedatei: Link Hallo zuammen,
seit ein paar Tagen zeigt mit der FHEM-Adapter keine Devices mehr an.
Im Log steht, dass das FHEM-Device einen Fehler in der jsonlist2 aufweist (s. Bild).
Wo kann ich mit der Fehlersuche beginnen?
Die Version des Adapters lautet 1.5.3 und ist aus dem Stable.Gruß
Hans-Ulrich -
Systemdata Bitte Ausfüllen Hardwaresystem: NUC mit Proxmox-VM Arbeitsspeicher: 3GB Festplattenart: VM 60 GB Betriebssystem: Ubuntu Node-Version: 12.20.0 Nodejs-Version: 12.20.0 NPM-Version: 6.14.8 Installationsart: Skript Image genutzt: Nein Ort/Name der Imagedatei: Link Hallo zuammen,
seit ein paar Tagen zeigt mit der FHEM-Adapter keine Devices mehr an.
Im Log steht, dass das FHEM-Device einen Fehler in der jsonlist2 aufweist (s. Bild).Wo kann ich mit der Fehlersuche beginnen?
Die Version des Adapters lautet 1.5.3 und ist aus dem Stable.Gruß
Hans-UlrichHallo zusammen,
ich habe das identische Fehlerbild auf einem NUC, Proxmox, LXC, FHEM (Version) 23364, iobroker (js 3.1.6, npm 6.14.4, nodejs 12.17.0). Die Rückgabe aus telnet jsonlist2 sieht in einem JSON-Viewer nicht unplausibel aus. Ich habe in fhem nur ein device, welches mit seinen readings im json auftaucht. Könnt Ihr mir als iobroker und fhem-beginner helfen, wo ich mit der Fehlersuche beginnen kann.
Danke und Gruß
mem -
Hallo zusammen,
ich habe das identische Fehlerbild auf einem NUC, Proxmox, LXC, FHEM (Version) 23364, iobroker (js 3.1.6, npm 6.14.4, nodejs 12.17.0). Die Rückgabe aus telnet jsonlist2 sieht in einem JSON-Viewer nicht unplausibel aus. Ich habe in fhem nur ein device, welches mit seinen readings im json auftaucht. Könnt Ihr mir als iobroker und fhem-beginner helfen, wo ich mit der Fehlersuche beginnen kann.
Danke und Gruß
mem -
Hallo zusammen,
ich habe exakt das gleiche Verhalten. FHEM für sich funktioniert einwandfrei. Der Adapter jedoch aktualisiert keine Stati, so dass über den ioBroker keine Verwendung möglich ist. Eine Neuinstallation des Adapters behebt den Fehler auch nicht nicht.
Die Ursache scheint ein Problem bei der Codierung des Response zu sein. Beim Abruf der Devices über jsonlist2 kann der Response nicht in JSON konvertiert werden.
Ich habe mir kurz einmal das Ergebnis des Requests im ioBroker angesehen und festgestellt, dass die ersten beiden Zeichen (Zeile 621 in main.js) [objects = JSON.parse(result);] den Fehler verursachen. Wenn ich die aus dem Response entferne (z.b. result = result.substr(3);) funktioniert der Request korrekt und die Devices werden alle erstellt. Leider funktionieren Aktualisierungsvorgänge (in beide Richtungen) im Nachgang auch nicht, somit sind wohl sämtliche Requests betroffen, was auf ein allgemeines Problem hindeutet.Ich habe leider gerade wenig Zeit hier weiter zu forschen. Was ich jedoch sagen kann, dass ihr hier selber vermutlich ohne Codeanpassungen den Fehler nicht beheben könnt, sondern ggf. auf ein Update des Adapters warten müsst.
-
Auch ich habe das Problem nach einem Update von FHEM.
Habe Backup von FHEM wieder eingespielt, dann lief der Adapter auch wieder.
Dann attr global exclude_from_update fhem.pl Utils.pm fhemweb.js 01_FHEMWEB.pm gesetzt.
Dadurch werden diese Dateien im Update ausgelassen und man kann zumindest die anderen FHEM Module aktualisieren.Ob die JSON Rückgabe von FHEM fehlerhaft ist, oder die Auswertung auf IoBroker Seite nicht korrekt abläuft kann ich nicht sagen.
Ich bin jedoch mit Smart-Gang einer Meinung, dass es nur durch ein Update des Adapters oder auf FHEM Seite behoben werden kann.Trotz allem,
Frohe Weihnachten -
Auch ich habe das Problem nach einem Update von FHEM.
Habe Backup von FHEM wieder eingespielt, dann lief der Adapter auch wieder.
Dann attr global exclude_from_update fhem.pl Utils.pm fhemweb.js 01_FHEMWEB.pm gesetzt.
Dadurch werden diese Dateien im Update ausgelassen und man kann zumindest die anderen FHEM Module aktualisieren.Ob die JSON Rückgabe von FHEM fehlerhaft ist, oder die Auswertung auf IoBroker Seite nicht korrekt abläuft kann ich nicht sagen.
Ich bin jedoch mit Smart-Gang einer Meinung, dass es nur durch ein Update des Adapters oder auf FHEM Seite behoben werden kann.Trotz allem,
Frohe WeihnachtenHallo zusammen,
Fehler liegt eindeudig auf FHEM Seite.
Lösche ich unter allowed das Passwort in FHEM ist wieder alles Ok.
Habe mal bei den FHEM Jungs angefragt: https://forum.fhem.de/index.php?topic=117051.msg1114138#msg1114138Gruß
LausiD -
Hallo zusammen,
Fehler liegt eindeudig auf FHEM Seite.
Lösche ich unter allowed das Passwort in FHEM ist wieder alles Ok.
Habe mal bei den FHEM Jungs angefragt: https://forum.fhem.de/index.php?topic=117051.msg1114138#msg1114138Gruß
LausiD@LausiD In einer Telegram Gruppe meint einer, die FHEM Jungs haben was am Telnet gefixt und das es wohl damit zusammenhängt.
Der Grund ist, dass die FHEM Jungs das Thema Telnet gefixt haben, aber bei IObroker der Adapter leider das Telnet nicht nach Norm umsetzt (er nimmt nur 6bytes, oder sowas)....Ka ob man damit was anfangen kann.
-
Systemdata Bitte Ausfüllen Hardwaresystem: NUC mit Proxmox-VM Arbeitsspeicher: 3GB Festplattenart: VM 60 GB Betriebssystem: Ubuntu Node-Version: 12.20.0 Nodejs-Version: 12.20.0 NPM-Version: 6.14.8 Installationsart: Skript Image genutzt: Nein Ort/Name der Imagedatei: Link Hallo zuammen,
seit ein paar Tagen zeigt mit der FHEM-Adapter keine Devices mehr an.
Im Log steht, dass das FHEM-Device einen Fehler in der jsonlist2 aufweist (s. Bild).Wo kann ich mit der Fehlersuche beginnen?
Die Version des Adapters lautet 1.5.3 und ist aus dem Stable.Gruß
Hans-UlrichIch weiß es nicht, ob es für Euch eine Alternative ist. Ich habe den FHEM Adapter nicht im Einsatz - steuere aber meine Heizung nach wie vor über FHEM.
Die Kommunikation zwischen FHEM und iobroker nehme ich über MQTT vor. Vielleicht ist das für den einen oder anderen ja auch eine Lösung - oder eine Übergangslösung.
-
@LausiD In einer Telegram Gruppe meint einer, die FHEM Jungs haben was am Telnet gefixt und das es wohl damit zusammenhängt.
Der Grund ist, dass die FHEM Jungs das Thema Telnet gefixt haben, aber bei IObroker der Adapter leider das Telnet nicht nach Norm umsetzt (er nimmt nur 6bytes, oder sowas)....Ka ob man damit was anfangen kann.
Seit heute mit 98_telnet.pm 23434 2020-12-29 20:22:05Z rudolfkoenig wieder alles OK :-)
https://forum.fhem.de/index.php?topic=117051.msg1114138#msg1114138
Es kann wieder ohne Probleme ein FHEM Update durchgeführt werden.
Falls Telnet Passwort gelöscht wurde kann nach FHEM Update auch in FHEM wieder ein Passwort gesetzt werden.Gruß
LausiD@h-tag01
Bitte als gelöst markieren. Vielen Dank! -
Ich weiß es nicht, ob es für Euch eine Alternative ist. Ich habe den FHEM Adapter nicht im Einsatz - steuere aber meine Heizung nach wie vor über FHEM.
Die Kommunikation zwischen FHEM und iobroker nehme ich über MQTT vor. Vielleicht ist das für den einen oder anderen ja auch eine Lösung - oder eine Übergangslösung.
-
@ch90045 Über mqtt - wobei ich das auf der FHEM Seite schwieriger fand. ;) Ehrlich gesagt müsste ich mich da erst wieder reinfuchsen - das hat mich damals schon etwas Zeit gekosten - funktioniert aber soweit erst mal ganz gut und stabil.
Inzwischen nutze ich ja mosquitto als MQTT Broker, sodass dies die zentrale Komponente ist.
Sieht also so aus. Da der MAX Adapter im iobroker zum Beispiel nicht mit den MAX eigenen Wochenprofilen arbeiten kann, bleibe ich hier auf dem FHEM System.
Auf der iobroker Seite sieht es deshalb so aus:
FHEM mqtt Client ==> mosquitto Broker <== iobroker MQTT Adapter als Client.
Die ganzen FHEM Geräte mit den von mir gewüschten Attributen sehe ich also in der MQTT Client Instanz:
Auf der FHEM Seite nimmt dann ein Dummy Device die Befehle so auseinander - damit da eine gewisse Sicherheit drin ist und man nicht alles unkontrolliert auf der FHEM Seite macht.
Welche Geräte ganz allgemein veröffentlich werden - steuert man dann über die Bridge, die dann entsprechend die userattr zu den Geräten hinzufügt.
Man kann dann auch noch einzelne Datenpunkte direkt steuern - das funktioniert prinzipiell - aber mit meiner Visualisierung stehe ich bei falscher Ausgangssituation manchmal auf Kriegsfuss und da muss man ziemlich aufpassen dass man keine Endlosschliefen produziert.
Dann kann man einzelne Datenpunkte (mit mqttPublish und mqttSubscribe) - wie ich das bei den Thermostaten machen - und der Anzeige von IST und SOLL Temperatur aufpassen, dass man SET und Zustand unterschiedlich behandelt:
unter mqtt ist es also wichtig hier 2 unterschiedliche Datenpunkte zu haben:
Jeder Flow bzw. jedes Script, das ich hier poste implementiert jeder auf eigene Gefahr. Flows und Scripts können Fehler aufweisen und weder der Seitenbetreiber noch ich persönlich können hierfür haftbar gemacht werden. Das gleiche gilt für Empfehlungen aller Art.
-
@ch90045 Über mqtt - wobei ich das auf der FHEM Seite schwieriger fand. ;) Ehrlich gesagt müsste ich mich da erst wieder reinfuchsen - das hat mich damals schon etwas Zeit gekosten - funktioniert aber soweit erst mal ganz gut und stabil.
Inzwischen nutze ich ja mosquitto als MQTT Broker, sodass dies die zentrale Komponente ist.
Sieht also so aus. Da der MAX Adapter im iobroker zum Beispiel nicht mit den MAX eigenen Wochenprofilen arbeiten kann, bleibe ich hier auf dem FHEM System.
Auf der iobroker Seite sieht es deshalb so aus:FHEM mqtt Client ==> mosquitto Broker <== iobroker MQTT Adapter als Client.
Die ganzen FHEM Geräte mit den von mir gewüschten Attributen sehe ich also in der MQTT Client Instanz:
Auf der FHEM Seite nimmt dann ein Dummy Device die Befehle so auseinander - damit da eine gewisse Sicherheit drin ist und man nicht alles unkontrolliert auf der FHEM Seite macht.
Welche Geräte ganz allgemein veröffentlich werden - steuert man dann über die Bridge, die dann entsprechend die userattr zu den Geräten hinzufügt.
Man kann dann auch noch einzelne Datenpunkte direkt steuern - das funktioniert prinzipiell - aber mit meiner Visualisierung stehe ich bei falscher Ausgangssituation manchmal auf Kriegsfuss und da muss man ziemlich aufpassen dass man keine Endlosschliefen produziert.
Dann kann man einzelne Datenpunkte (mit mqttPublish und mqttSubscribe) - wie ich das bei den Thermostaten machen - und der Anzeige von IST und SOLL Temperatur aufpassen, dass man SET und Zustand unterschiedlich behandelt:
unter mqtt ist es also wichtig hier 2 unterschiedliche Datenpunkte zu haben:
679
Online32.7k
Users82.5k
Topics1.3m
Posts