NEWS
FHEM Adapter
-
@pole23 sagte in FHEM Adapter:
Ich kann es innerhalb von FHEM mit „set bu_LichtDecke on“ und „set bu_LichtDecke g1 on“ schalten.
Und mit was schaltest du in FHEM aus?
Eine Möglichkeit die immer geht
Du legst ein dummy als Schalter an ( sehr einfach mit fhem.0.info.Commands.createSwitch) und machst in FHEM ein kleines notify dazu -> fertigGruß LausiD
@LausiD Ich schalte mit „set bu_LichtDecke on“ die Devices an und aus. Ich bin aber der Meinung, dass das mit einer älteren Version des Adapters funktioniert hatte. Ich muss mal schauen, ob ich das noch rausbekomme, welche das genau war.
-
@Scooty sagte in FHEM Adapter:
Bingo, das scheint's zu sein, ohne Einträge in fhem.0.info.Configurations.allowedIOBin startet der Adapter.
Kannst du mal bitte mit Update von github versuchen...Danke
@LausiD said in FHEM Adapter:
Kannst du mal bitte mit Update von github versuchen...Danke
Nach Update startet die Instanz nun ohne Probleme
:(4631) END ===== Synchronised FHEM in 65238 ms :-)Klasse, vielen Dank, sollte bei weiteren Tests noch etwas auffallen, melde ich mich (ist keine Drohung
) .Viele Grüße,
Andreas -
Hallo @LausiD,
tja, da bin ich schon wieder.
Leider schaffe ich es, durch eine Aktion in FHEM die FHEM-Instanz in IOBroker abzuschiessen (Neustart erfolgt aber zuverlässig).
Möchte die Bedienung aus FHEM etwas komfortabler gestalten, daher habe ich im FHEM-Device "fhem.0.send2ioB" eine setList definiert (RAW-Definition):
attr fhem.0.send2ioB setList vw-connect.0.TMBJW7NP7L70XXXXX.remote.batterycharge:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.climatisation:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.flash:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.honk:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.lock:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.standheizung:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.windowheating:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.climatisation:true,false\ chromecast.0.SZDG_GHOME01.status.volume:slider,0,5,100,1\ chromecast.0.SZDG_GHOME01.player.stop:true,false\ chromecast.0.SZDG_GHOME01.player.pause:true,false\ chromecast.0.SZDG_GHOME01.player.play:trueKann es sein, dass beim Speichern von Änderungen dieser setList FHEM wohl einen Event erzeugt, den der FHEM-Adapter in IOBRoker nicht verträgt (s. letzte Zeile im Log):
fhem.0 2020-06-15 12:02:37.362 info (4782) Terminated (NO_ERROR): Without reason fhem.0 2020-06-15 12:02:37.361 info (4782) terminating fhem.0 2020-06-15 12:02:37.353 debug (4782) [stateChange] stateChange (in): fhem.0.info.Info.alive false {"val":false,"ack":true,"ts":1592215357339,"q":0,"from":"system.adapter.fhem.0","user":"system.user.admin","lc":1592215357339} fhem.0 2020-06-15 12:02:37.351 debug (4782) [stateChange] stateChange (in): fhem.0.info.connection false {"val":false,"ack":true,"ts":1592215357338,"q":0,"from":"system.adapter.fhem.0","user":"system.user.admin","lc":1592215357338} fhem.0 2020-06-15 12:02:37.334 debug (4782) adapter.on.unload: clearTimeout getAlive fhem.0 2020-06-15 12:02:37.333 debug (4782) adapter.on.unload: clearTimeout setAlive fhem.0 2020-06-15 12:02:37.332 error (4782) ReferenceError: channel is not defined at parseEvent (/opt/iobroker/node_modules/iobroker.fhem/main.js:2317:29) at processEvent (/opt/iobroker/node_modules/iobroker.fhem/main.js:2304:5) fhem.0 2020-06-15 12:02:37.331 error (4782) uncaught exception: channel is not defined fhem.0 2020-06-15 12:02:37.329 warn (4782) ReferenceError: channel is not defined at parseEvent (/opt/iobroker/node_modules/iobroker.fhem/main.js:2317:29) at processEvent (/opt/iobroker/node_modules/iobroker.fhem/main.js:2304:5) fhem.0 2020-06-15 12:02:37.326 warn (4782) Exception: ReferenceError: channel is not defined fhem.0 2020-06-15 12:02:37.325 debug (4782) [main] [eventFHEM] eventFHEM(in): "vw-connect.0.TMBJW7NP7L7057941.remote.climatisation:true,false"Zwei weitere Dinge:
- Beim Neustart der FHEM-Instanz werden wohl alle IOBroker Devices in FHEM gelöscht und wieder neu angelegt? Ist das so gewollt? Damit werden leider auch alle von mir zwischenzeitlich geänderten Attribute (wie z.B. "room") auf Standard zurückgesetzt. Oder habe ich ein Verständnisproblem und sollte nicht mit den nativen IOBroker-Devices in FHEM arbeiten?
Edit: Betrifft ggf. nur das "room" Attribut, Attribut "userReadings" bleibt bestehen. - Zumindest die "vw-connect" Objekte werden in FHEM mit einem "_" statt dem "-" im FHEM-Devicenamen angelegt, also z.B.
#in FHEM vw_connect.0.TMBJW7NP7L70XXXXX.remote.climatisation# in IOBroker vw-connect.0.TMBJW7NP7L70XXXX.remote.climatisationFührte bei mir ein wenig zu Verwirrung, weil man in FHEM bei einem
set fhem.0.send2ioBnicht den FHEM-Devicenamen sondern den IOBroker Objektnamen verwenden muss.
Weißt Du, warum das "-" durch das "_" beim Anlage des Devices in FHEM ersetzt wird?Vielen Dank und Grüße,
AndreasPS: Sorry, keine Ahnung woher dieses "Select all" in den Code-Bereichen herkommt....
- Beim Neustart der FHEM-Instanz werden wohl alle IOBroker Devices in FHEM gelöscht und wieder neu angelegt? Ist das so gewollt? Damit werden leider auch alle von mir zwischenzeitlich geänderten Attribute (wie z.B. "room") auf Standard zurückgesetzt. Oder habe ich ein Verständnisproblem und sollte nicht mit den nativen IOBroker-Devices in FHEM arbeiten?
-
Hallo @LausiD,
tja, da bin ich schon wieder.
Leider schaffe ich es, durch eine Aktion in FHEM die FHEM-Instanz in IOBroker abzuschiessen (Neustart erfolgt aber zuverlässig).
Möchte die Bedienung aus FHEM etwas komfortabler gestalten, daher habe ich im FHEM-Device "fhem.0.send2ioB" eine setList definiert (RAW-Definition):
attr fhem.0.send2ioB setList vw-connect.0.TMBJW7NP7L70XXXXX.remote.batterycharge:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.climatisation:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.flash:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.honk:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.lock:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.standheizung:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.windowheating:true,false\ vw-connect.0.TMBJW7NP7L70XXXXX.remote.climatisation:true,false\ chromecast.0.SZDG_GHOME01.status.volume:slider,0,5,100,1\ chromecast.0.SZDG_GHOME01.player.stop:true,false\ chromecast.0.SZDG_GHOME01.player.pause:true,false\ chromecast.0.SZDG_GHOME01.player.play:trueKann es sein, dass beim Speichern von Änderungen dieser setList FHEM wohl einen Event erzeugt, den der FHEM-Adapter in IOBRoker nicht verträgt (s. letzte Zeile im Log):
fhem.0 2020-06-15 12:02:37.362 info (4782) Terminated (NO_ERROR): Without reason fhem.0 2020-06-15 12:02:37.361 info (4782) terminating fhem.0 2020-06-15 12:02:37.353 debug (4782) [stateChange] stateChange (in): fhem.0.info.Info.alive false {"val":false,"ack":true,"ts":1592215357339,"q":0,"from":"system.adapter.fhem.0","user":"system.user.admin","lc":1592215357339} fhem.0 2020-06-15 12:02:37.351 debug (4782) [stateChange] stateChange (in): fhem.0.info.connection false {"val":false,"ack":true,"ts":1592215357338,"q":0,"from":"system.adapter.fhem.0","user":"system.user.admin","lc":1592215357338} fhem.0 2020-06-15 12:02:37.334 debug (4782) adapter.on.unload: clearTimeout getAlive fhem.0 2020-06-15 12:02:37.333 debug (4782) adapter.on.unload: clearTimeout setAlive fhem.0 2020-06-15 12:02:37.332 error (4782) ReferenceError: channel is not defined at parseEvent (/opt/iobroker/node_modules/iobroker.fhem/main.js:2317:29) at processEvent (/opt/iobroker/node_modules/iobroker.fhem/main.js:2304:5) fhem.0 2020-06-15 12:02:37.331 error (4782) uncaught exception: channel is not defined fhem.0 2020-06-15 12:02:37.329 warn (4782) ReferenceError: channel is not defined at parseEvent (/opt/iobroker/node_modules/iobroker.fhem/main.js:2317:29) at processEvent (/opt/iobroker/node_modules/iobroker.fhem/main.js:2304:5) fhem.0 2020-06-15 12:02:37.326 warn (4782) Exception: ReferenceError: channel is not defined fhem.0 2020-06-15 12:02:37.325 debug (4782) [main] [eventFHEM] eventFHEM(in): "vw-connect.0.TMBJW7NP7L7057941.remote.climatisation:true,false"Zwei weitere Dinge:
- Beim Neustart der FHEM-Instanz werden wohl alle IOBroker Devices in FHEM gelöscht und wieder neu angelegt? Ist das so gewollt? Damit werden leider auch alle von mir zwischenzeitlich geänderten Attribute (wie z.B. "room") auf Standard zurückgesetzt. Oder habe ich ein Verständnisproblem und sollte nicht mit den nativen IOBroker-Devices in FHEM arbeiten?
Edit: Betrifft ggf. nur das "room" Attribut, Attribut "userReadings" bleibt bestehen. - Zumindest die "vw-connect" Objekte werden in FHEM mit einem "_" statt dem "-" im FHEM-Devicenamen angelegt, also z.B.
#in FHEM vw_connect.0.TMBJW7NP7L70XXXXX.remote.climatisation# in IOBroker vw-connect.0.TMBJW7NP7L70XXXX.remote.climatisationFührte bei mir ein wenig zu Verwirrung, weil man in FHEM bei einem
set fhem.0.send2ioBnicht den FHEM-Devicenamen sondern den IOBroker Objektnamen verwenden muss.
Weißt Du, warum das "-" durch das "_" beim Anlage des Devices in FHEM ersetzt wird?Vielen Dank und Grüße,
AndreasPS: Sorry, keine Ahnung woher dieses "Select all" in den Code-Bereichen herkommt....
@Scooty sagte in FHEM Adapter:
Kann es sein, dass beim Speichern von Änderungen dieser setList FHEM wohl einen Event erzeugt, den der FHEM-Adapter in IOBRoker nicht verträgt
Stimmt
Nach Update von github sollte Absturz erledigt sein@Scooty sagte in FHEM Adapter:
Beim Neustart der FHEM-Instanz werden wohl alle IOBroker Devices in FHEM gelöscht und wieder neu angelegt?
Werden nicht gelöscht jedoch im Raum ioB_IN erwartet.
Zusätzlich zum Raum ioB_IN einen weiteren Raum zuordnen sollte gehen@Scooty sagte in FHEM Adapter:
Zumindest die "vw-connect" Objekte werden in FHEM mit einem "_" statt dem "-" im FHEM-Devicenamen angelegt
In FHEM darf der Device Name kein "-" enthalten, deshalb erfolgt die Umwandlung in "_"
Vielen Dank für Deine Rückmeldung und Gruß
LausiD - Beim Neustart der FHEM-Instanz werden wohl alle IOBroker Devices in FHEM gelöscht und wieder neu angelegt? Ist das so gewollt? Damit werden leider auch alle von mir zwischenzeitlich geänderten Attribute (wie z.B. "room") auf Standard zurückgesetzt. Oder habe ich ein Verständnisproblem und sollte nicht mit den nativen IOBroker-Devices in FHEM arbeiten?
-
@LausiD Ich schalte mit „set bu_LichtDecke on“ die Devices an und aus. Ich bin aber der Meinung, dass das mit einer älteren Version des Adapters funktioniert hatte. Ich muss mal schauen, ob ich das noch rausbekomme, welche das genau war.
@pole23 sagte in FHEM Adapter:
Ich schalte mit „set bu_LichtDecke on“ die Devices an und aus
Sorry, verstehe ich nicht so ganz.
Mit „set bu_LichtDecke on“ schaltest du im Wechsel an/aus?
Wofür brauchst du dann ein state_switch?Gruß
LausiD -
@LausiD Sorry, da habe ich mich falsch ausgedrückt. Ich schalte mit "set bu_LichtDecke on" die Lampe an und mit "set bu_LichtDecke off" die Lampe wieder aus. Daher würde hier ein Switch sinn machen, da ich sonst in der VIS ein Problem mit den Toggle habe.
-
@Scooty sagte in FHEM Adapter:
Kann es sein, dass beim Speichern von Änderungen dieser setList FHEM wohl einen Event erzeugt, den der FHEM-Adapter in IOBRoker nicht verträgt
Stimmt
Nach Update von github sollte Absturz erledigt sein@Scooty sagte in FHEM Adapter:
Beim Neustart der FHEM-Instanz werden wohl alle IOBroker Devices in FHEM gelöscht und wieder neu angelegt?
Werden nicht gelöscht jedoch im Raum ioB_IN erwartet.
Zusätzlich zum Raum ioB_IN einen weiteren Raum zuordnen sollte gehen@Scooty sagte in FHEM Adapter:
Zumindest die "vw-connect" Objekte werden in FHEM mit einem "_" statt dem "-" im FHEM-Devicenamen angelegt
In FHEM darf der Device Name kein "-" enthalten, deshalb erfolgt die Umwandlung in "_"
Vielen Dank für Deine Rückmeldung und Gruß
LausiD -
@LausiD Sorry, da habe ich mich falsch ausgedrückt. Ich schalte mit "set bu_LichtDecke on" die Lampe an und mit "set bu_LichtDecke off" die Lampe wieder aus. Daher würde hier ein Switch sinn machen, da ich sonst in der VIS ein Problem mit den Toggle habe.
@pole23 sagte in FHEM Adapter:
Ich schalte mit "set bu_LichtDecke on" die Lampe an und mit "set bu_LichtDecke off" die Lampe wieder aus. Daher würde hier ein Switch sinn machen, da ich sonst in der VIS ein Problem mit den Toggle habe.
Ok jetzt habe ich verstanden und ein state_switch macht Sinn.
Schau ich mir nochmal an...Gruß LausiD
-
Guten Morgen.
seit dem Update wird meine Logdatei zuspamt mit:
Weiß jemand was das bedeutet?
Hier ein ausschnitt aus dem Debug:
Vielen Dank!
@djsirius sagte in FHEM Adapter:
fhem.0 2020-06-25 09:25:39.752 info (19045) unhandled event FHEM: ---- | at atSpuelmaschinePower Next: 09:25:44 > no sync - no fhemObjects >> jsonlist2 atSpuelmaschinePower
Ein state zB mit "Next: ..." kann leider nicht einwandfrei als state oder reading erkannt werden, deshalb der Umweg über jsonlist2.
Falls du die Meldung nicht haben möchtest bitte fhem.0.info.Settings.logUnhandledEventFHEM auf false setzen.Gruß
LausiD -
@LausiD Ich habe die aktuellste Version neu installiert, leider wird "_switch" nicht erstellt.
@pole23 sagte in FHEM Adapter:
@LausiD Ich habe die aktuellste Version neu installiert, leider wird "_switch" nicht erstellt.
Stimmt, habe ich nochmal geprüft.
Nach Update von github 1.5.2 buildDate 28.06.20 sollte es aber flutschenFür jedes Device TYPE "KNX" wird jetzt ein state_switch angelegt.
Gruß
LausiD -
@pole23 sagte in FHEM Adapter:
@LausiD Ich habe die aktuellste Version neu installiert, leider wird "_switch" nicht erstellt.
Stimmt, habe ich nochmal geprüft.
Nach Update von github 1.5.2 buildDate 28.06.20 sollte es aber flutschenFür jedes Device TYPE "KNX" wird jetzt ein state_switch angelegt.
Gruß
LausiD -
@djsirius sagte in FHEM Adapter:
fhem.0 2020-06-25 09:25:39.752 info (19045) unhandled event FHEM: ---- | at atSpuelmaschinePower Next: 09:25:44 > no sync - no fhemObjects >> jsonlist2 atSpuelmaschinePower
Ein state zB mit "Next: ..." kann leider nicht einwandfrei als state oder reading erkannt werden, deshalb der Umweg über jsonlist2.
Falls du die Meldung nicht haben möchtest bitte fhem.0.info.Settings.logUnhandledEventFHEM auf false setzen.Gruß
LausiD@LausiD
könntest du mir vielleicht erklären, wie ich den Fehler beheben kann, weil die drei Blockly Scripte auch Probleme machen und nicht einwandfrei funktionieren. Ich finde den Fehler nicht!Ich habe die Scripte nicht selbst geschrieben sondern von Kuddel https://forum.iobroker.net/topic/19611/vorstellung-meine-zweite-visualisierung/1200 übernommen.
Vielen Dank!
Gruß
djsirius
-
@LausiD
könntest du mir vielleicht erklären, wie ich den Fehler beheben kann, weil die drei Blockly Scripte auch Probleme machen und nicht einwandfrei funktionieren. Ich finde den Fehler nicht!Ich habe die Scripte nicht selbst geschrieben sondern von Kuddel https://forum.iobroker.net/topic/19611/vorstellung-meine-zweite-visualisierung/1200 übernommen.Vielen Dank!
@LausiD
Hallo LausiD, die Konfigurationen
-fhem.0.info.Configurations.autoConfigFHEM
-fhem.0.info.Settings.logUnhandledEventFHEM
lassen sich nicht setzen. Sie stehen auf rot: (Bestätigt: false) und ändern sich nicht.
Habe ich ein Berechtigungsproblem?
Gruß Bernd
NPM 6.14.5
Node.js 12.18.1
JS-controller 3.16
FHEM-Adapter 1.5.2
Raspbian GNU/Linux 9 (stretch) -
@LausiD
könntest du mir vielleicht erklären, wie ich den Fehler beheben kann, weil die drei Blockly Scripte auch Probleme machen und nicht einwandfrei funktionieren. Ich finde den Fehler nicht!Ich habe die Scripte nicht selbst geschrieben sondern von Kuddel https://forum.iobroker.net/topic/19611/vorstellung-meine-zweite-visualisierung/1200 übernommen.Vielen Dank!
@djsirius sagte in FHEM Adapter:
wie ich den Fehler beheben kann, weil die drei Blockly Scripte auch Probleme machen und nicht einwandfrei funktionieren.
Sorry, Blocky ist gar nicht mein Thema.
Für Hilfe, Unterstützung solltest du vielleicht das Problem näher beschreiben.Gruß LausiD
748
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge