IKEA Trådfri Modul

Begonnen von Peter Kappelt, 16 April 2017, 15:07:07

Vorheriges Thema - Nächstes Thema

dtavb

#135
Hoi Peter,

das hat ja gut geklappt!
Kurz dein HowTo für die Beta durchgespielt und gut ist.

War mir erst nicht sicher, ob ich erst alle Tradfri Konfigs aus fhem löschen muss bevor ich die Beta installiere.
Ein kleiner Hinweis auf Deiner Seite wäre noch nicht schlecht für Umsteiger.

Schaltungen funktionieren tadellos.
Der Zustand der Readings state/STATE wird in fhemweb nicht aktualisiert.
Erst durch F5 im Browser sieht man den geänderten Zustand.

Frage/Hinweis zu Java:
Habe die ganze Prozedur als root ausgeführt. Hätte eigentlich mit einem Berechtigungsproblem gerechnet, gibt aber keins :)
Für Beta-Testing reicht das, später müsste der Java-Part bestimmt dem User fhem:dialout gehören und sämtliche Java-Files für das Tradfri Modul 700 Berechtigungen haben. Liege ich hier richtig?

[Nachtrag von 16:00 Uhr]
Wenn ich mich nach einer Weile in fhemweb einlogge, erscheinen diese Meldungen:
Messages collected while initializing FHEM:
configfile: Bulb1: unknown attribute autoUpdateInterval. Type 'attr Bulb1 ?' for a detailed list.
Bulb2: unknown attribute autoUpdateInterval. Type 'attr Bulb2 ?' for a detailed list.
Bulb3: unknown attribute autoUpdateInterval. Type 'attr Bulb3 ?' for a detailed list.
Bulb4: unknown attribute autoUpdateInterval. Type 'attr Bulb4 ?' for a detailed list.

[Nachtrag von 19:40 Uhr]
habe nun eine zusätzliche virtuelle Maschine aufgesetzt und die produktive fhem-Konfig samt File-Struktur nachgebaut.
Das Tradfri-GW wird als opened angezeigt.
Get-Funktionen funktionieren beim Gateway ebenfalls.

Schalte ich allerdings eine Lampe, passiert folgendes (CLI - Screen Output):
root@fhemlab:/opt/Tradfri-FHEM/kCoAPSocket/kCoAPSocket# java -jar kCoAPSocket.jar -s SicherheitscodeDesGateways
[TcpServerThread] Binding of socket @ port 1505 successfull.
Jul 13, 2017 7:24:25 PM org.eclipse.californium.core.network.config.NetworkConfig load
INFORMATION: loading properties from file /opt/Tradfri-FHEM/kCoAPSocket/kCoAPSocket/Californium.properties
Jul 13, 2017 7:24:25 PM org.eclipse.californium.core.network.CoapEndpoint start
INFORMATION: Starting endpoint at 0.0.0.0/0.0.0.0:0
Jul 13, 2017 7:24:25 PM org.eclipse.californium.scandium.DTLSConnector start
INFORMATION: DTLS connector listening on [0.0.0.0/0.0.0.0:51732] with MTU [1.280] using (inbound) datagram buffer size [16.474 bytes]
Jul 13, 2017 7:24:25 PM org.eclipse.californium.core.CoapClient setEndpoint
INFORMATION: Started set client endpoint 0.0.0.0/0.0.0.0:51732
[TcpServerThread] Connection at port 1505 opened
[TcpServerThread] Received data: setPSK|JsvwwbRpvz3WEIUu
[TcpServerThread] Command "setPSK" disabled!
[TcpServerThread] Received data: coapPutJSON|coaps://192.168.192.141/15001/65539|{"3311":[{"5850":0}]}
[TcpServerThread] Error in client socket, ending this socket: null
[TcpServerThread] Connection at port 1505 opened
[TcpServerThread] Received data: coapGet|coaps://192.168.192.141/15001/65539
[TcpServerThread] Connection at port 1505 opened
[TcpServerThread] Received data: coapGet|coaps://192.168.192.141/15001/65539
[TcpServerThread] Error in client socket, ending this socket: null
[TcpServerThread] Error in client socket, ending this socket: null


Get-Funktionen gehen bei den Lampen nicht, "Error while fetching device info"

Aus dem produktiven System, kann ich mit der Beta schalten.

Kann jetzt selbstverständlich sein, dass es an der virtuellen Maschine liegt. Habe zum Vergleich noch WiFi-Steckdosen sowie eine MiLight Bridge. Beide Gerätegruppen sind vom virtuellen Labor-System aus schaltbar. Demnach kann es mal nicht am Netzwerk liegen.


Grüsse,
dtavb

fhem:pi3&kvm, z-wave, it-funk, milight, zigbee, wifi, bt & presence, geo-tracking, alexa, esp.
Monitoring: ELK(syslog), grafana (grafik), netdata (ermittlung)
Security: haproxy (access), ossec (überall), snort (access), opnsense (fw)
Geplant: KVM-Cluster

Mickey Mouse

#136
ich habe die aktuelle Version (eben war sie jedenfalls aktuell ;) ) ausprobiert und es funktioniert schon "nahezu perfekt".
ich musste nach einem FHEM Neustart in jeder Gruppe einmal die moods per get holen und die Seite neu laden, damit sie in der DropDown Liste auftauchen, aber das lasse ich unter minor details oder Kosmetik laufen.

der Status der Lampen wird sofort angezeigt, völlig egal ob per FHEM selber, App, FB oder Bewegungsmelder ein/aus geschaltet wurde (auch "aus" nach dem Timeout vom Bewegungsmelder wird korrekt gemeldet). Und man kann auf diesen Status ein Notify setzen, auch das funktioniert!
Sogar besser als ich erwartet habe.
Ich habe zum Spielen ein notify "WZ_W1:.* set TestDummy2 $EVENT" eingebaut. Wenn die Lampe aus ist und man dimmt mit der FB eine Stufe hoch, dann kommt erst ein "On" Event und anschließend der Dimvalue hinterher, On geht also nicht verloren.
ein ganz kleiner Schönheitsfehler (der bei Ikea liegen dürfte): wenn man per App eine Gruppe "auf Null dimmt", dann werden die Lampen mit Status Off angezeigt, die Gruppe selber bleibt aber "On" mit Dimvalue 0. Da könnte es noch Probleme geben...

noch ein Tip für Leute, die sich jetzt hektisch mit Trådfri eindecken (wollen). Die Ikea App selber hat noch einige Macken. Man kann zwar "Lampen" zwischen den Gruppen verschieben, aber keine FB, Dimmer, Bewegungsmelder. Wenn man die für eine andere Gruppe nutzen möchte, dann muss man die Kopplungsorgie von vorne starten, dabei ändern sich dann natürlich auch die Trådfri IDs und man kann von vorne anfangen. Man sollte sich also vorher überlegen wie man das verteilen möchte. Man bekommt das immer wieder hin, es macht aber Arbeit.

Brause

#137
Guten Abend

Ich habe gerade das heutige update eingespielt.

1. Java - git pull / git submodule update --remote
2. im screen den Client neu gestartet
3. FHEM update und restart

Allerdings funktioniert jetzt kein Schaltvorgang mehr. weder Gruppe noch Lampe.

beim start im screen

[TcpServerThread] Binding of socket @ port 1505 successfull.
Jul 14, 2017 8:43:23 PM org.eclipse.californium.core.network.config.NetworkConfig load
INFORMATION: loading properties from file /opt/Tradfri-FHEM/kCoAPSocket/kCoAPSocket/Californium.properties
Jul 14, 2017 8:43:24 PM org.eclipse.californium.core.network.CoapEndpoint start
INFORMATION: Starting endpoint at 0.0.0.0/0.0.0.0:0
Jul 14, 2017 8:43:24 PM org.eclipse.californium.scandium.DTLSConnector start
INFORMATION: DTLS connector listening on [0.0.0.0/0.0.0.0:45139] with MTU [1.280] using (inbound) datagram buffer size [16.474 bytes]
Jul 14, 2017 8:43:24 PM org.eclipse.californium.core.CoapClient setEndpoint
INFORMATION: Started set client endpoint 0.0.0.0/0.0.0.0:45139


bei Getaway reopen bekomme ich im screen

[TcpServerThread] Connection at port 1505 opened
[TcpServerThread] Received data: setPSK|xxxx
[TcpServerThread] Command "setPSK" disabled!
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65541
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65537
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65545
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65540
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15004/160881
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65547
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65539
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15004/178691
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65546
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65538
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65542
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65543
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15001/65544
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15004/135492
[TcpServerThread] Received data: coapObserveStart|coaps://192.168.6.44/15004/143163
21 INFO [DTLSConnector]: Unexpected error occurred while processing record from peer [/192.168.6.44:5684] - (org.eclipse.californium.scandium.DTLSConnector.java:546) processRecord() in thread pool-1-thread-4 at (2017-07-14 20:44:12)
java.lang.NullPointerException
        at org.eclipse.californium.scandium.dtls.ClientHandshaker.receivedHelloVerifyRequest(ClientHandshaker.java:327)
        at org.eclipse.californium.scandium.dtls.ClientHandshaker.doProcessMessage(ClientHandshaker.java:218)
        at org.eclipse.californium.scandium.dtls.Handshaker.processMessage(Handshaker.java:406)
        at org.eclipse.californium.scandium.DTLSConnector.processOngoingHandshakeMessage(DTLSConnector.java:908)
        at org.eclipse.californium.scandium.DTLSConnector.processDecryptedHandshakeMessage(DTLSConnector.java:895)
        at org.eclipse.californium.scandium.DTLSConnector.processHandshakeRecordWithConnection(DTLSConnector.java:879)
        at org.eclipse.californium.scandium.DTLSConnector.processHandshakeRecord(DTLSConnector.java:806)
        at org.eclipse.californium.scandium.DTLSConnector.processRecord(DTLSConnector.java:537)
        at org.eclipse.californium.scandium.DTLSConnector.access$6(DTLSConnector.java:521)
        at org.eclipse.californium.scandium.DTLSConnector$3.run(DTLSConnector.java:499)
        at eu.javaspecialists.tjsn.concurrency.stripedexecutor.StripedExecutorService$SerialExecutor$1.run(StripedExecutorService.java:460)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)


Schaltbefehl Gruppe

[TcpServerThread] Received data: coapPutJSON|coaps://192.168.6.44/15004/178691|{"5850":1}


und danach nur noch sowas

[TcpServerThread] Observing failed
[TcpServerThread] Observing failed
[TcpServerThread] Observing failed
[TcpServerThread] Observing failed
[TcpServerThread] Observing failed
[TcpServerThread] Observing failed
[TcpServerThread] Error in client socket, ending this socket: null
[TcpServerThread] Observing failed


ein get grouplist bringt im FHEM als Antwort

Unknown JSON:
UNDEF

und im screen

[TcpServerThread] Connection at port 1505 opened
[TcpServerThread] Received data: coapGet|coaps://192.168.6.44/15004
[TcpServerThread] Observing failed

und im LOG kommt das

2017.07.14 20:55:27 2: xx.GW.Tradfri: first attempt to read timed out, trying to close and open the device.
2017.07.14 20:55:28 2: xx.GW.Tradfri: second attempt to read timed out, this is an unrecoverable error.


wie gesagt ein Schaltbefehl im FHEM bring keine Lichtänderung.
Habe ich irgendwo was vergessen ??

Gruss Brause

Mickey Mouse

ich habe mir bei den Tests angewöhnt:
1) FHEM update
2) FHEM runterfahren (komplett /etc/init.d/fhem stop)
3) Java Client stoppen
4) Java Client updaten
5) Java Client starten
6) FHEM starten
7) ... etwas warten (fällt schwer ;) )
8) weiter testen ...

gerade mit dieser Screen Geschichte verliere ich gerne mal den Überblick. Da hat man gestern Abend noch etwas probiert und nächsten Tag startet man den Client auf einem anderen Terminal nochmal.
Im Zweifelsfall einfach einmal neu booten.

Brause

ja kompletten Server neustart habe ich auch schon probiert.
Auch komplette Neuinstallation der JAVA-Geschichte

Alles keine Änderung.
Die Meldungen bleiben die selben.


Mickey Mouse

bei mir war das in den letzten Tagen ähnlich, aber jetzt funktioniert das alles sehr gut.
vielleicht sollten wir Peter noch etwas Zeit geben und nicht zu sehr unter Druck setzen.

Peter Kappelt

Hallo,

ich muss zugeben, dass ich gerade in den letzten Tagen etwas den Überblick über die Problemmeldungen verloren habe, die bei den verschiedenen Testern aufgetreten sind. Dummerweise habe ich auch noch versehentlich die Benachrichtigungen für den Thread hier deaktiviert und in den letzten Tagen nicht mehr gelesen. Hinzu kam noch, dass ich in den Entwicklungsversionen auch keine Versionsnummern verwendet habe - was die Zuordnung von Problem zu Bearbeitungsversion noch schwerer macht. Gut, was für die Zukunft gelernt.

Im Allgemeinen muss ich auch sagen, dass ich mit der CoAP-Implementierung "Californium" von der ETH Zürich recht unzufrieden bin - obwohl die mir am Anfang sehr vielversprechend schien. Gerade in Sachen Fehlerbehandlung sehe ich da einiges Verbesserungspotenzial, vieles muss ich per Hand in meinem Code abprüfen.

Wie auch immer - Ich möchte mich hier bei allen bedanken, die bisher ihre eigene Zeit in das Testen und Herumärgern mit meiner Software gesteckt haben.

Sofern Eure Probleme und Meldungen noch aktuell und relevant sind:

Zitat von: dtavb am 13 Juli 2017, 11:08:15
Frage/Hinweis zu Java:
Habe die ganze Prozedur als root ausgeführt. Hätte eigentlich mit einem Berechtigungsproblem gerechnet, gibt aber keins :)
Für Beta-Testing reicht das, später müsste der Java-Part bestimmt dem User fhem:dialout gehören und sämtliche Java-Files für das Tradfri Modul 700 Berechtigungen haben. Liege ich hier richtig?

[Nachtrag von 16:00 Uhr]
Wenn ich mich nach einer Weile in fhemweb einlogge, erscheinen diese Meldungen:
Messages collected while initializing FHEM:
configfile: Bulb1: unknown attribute autoUpdateInterval. Type 'attr Bulb1 ?' for a detailed list.
Bulb2: unknown attribute autoUpdateInterval. Type 'attr Bulb2 ?' for a detailed list.
Bulb3: unknown attribute autoUpdateInterval. Type 'attr Bulb3 ?' for a detailed list.
Bulb4: unknown attribute autoUpdateInterval. Type 'attr Bulb4 ?' for a detailed list.

Ausführung als Root ist obsolet, der Java-Client kann inzwischen als normaler Nutzer gestartet werden. Ich habe mich damals gewundert, weil der den Socket als normaler Nutzer nicht starten wollte. Lag aber daran, dass ein Port kleiner 1024 genutzt wurde - um so einen zu öffnen, bedarf es Root-Rechten. Habe ich inzwischen geändert.

Das Attribut "autoUpdateInterval" ist obsolet und auch nicht mehr notwendig, habe es somit auch aus den Definitionen gelöscht.

Zitat von: dtavb am 13 Juli 2017, 11:08:15
Schaltungen funktionieren tadellos.
Der Zustand der Readings state/STATE wird in fhemweb nicht aktualisiert.
Erst durch F5 im Browser sieht man den geänderten Zustand.

Schau ich mir an.

Zitat von: Mickey Mouse am 14 Juli 2017, 21:35:23
ich habe mir bei den Tests angewöhnt:
1) FHEM update
2) FHEM runterfahren (komplett /etc/init.d/fhem stop)
3) Java Client stoppen
4) Java Client updaten
5) Java Client starten
6) FHEM starten
7) ... etwas warten (fällt schwer ;) )
8) weiter testen ...

gerade mit dieser Screen Geschichte verliere ich gerne mal den Überblick. Da hat man gestern Abend noch etwas probiert und nächsten Tag startet man den Client auf einem anderen Terminal nochmal.
Im Zweifelsfall einfach einmal neu booten.


Diese Reihenfolge halte ich selbst auch ein und empfehle auch deren Einhaltung - zumindest bis ein wenig Besserung in Aussicht ist. Werde ich noch ergänzen. Entschuldigt bitte, dass ich so etwas noch nicht in der Anleitung hingeschrieben hatte.


Zitat von: Brause am 14 Juli 2017, 20:50:08
Allerdings funktioniert jetzt kein Schaltvorgang mehr. weder Gruppe noch Lampe.

Habe gerade keine Zeit mehr, intensiv über mögliche Problemursachen nachzudenken. Setze mich morgen nochmal damit auseinander.
Erstmal das Einfachste: Bist du dor sicher, dass du den Java-Client mit dem Parameter "-s" aufrufst? Der ist inzwischen notwendig geworden. Also soll dann heißen: "java -jar kCoAPSocket.jar -s DeinGatewayPasswort".


Schönen Abend!
Peter

solbadguy2010

Hallo Herr Kappelt,
ich bin seit heute auch stolzer besitzer eines Ikea Tradfri und habe direkt versucht es in meine existierende FHEM Konfiguration mit EQ-3 Max! und Homebridge zu integrieren. Das ganze läuft auf einem Mac Mini.

Zuerst habe ich das JASON.pm mit den beiden Befehlen "brew install cpanm" und "sudo cpanm install JSON" installiert.
Anschließend habe ich Coap mit "brew install libcoap" installiert.
Zuletzt habe ich dann ihr Modul nach ihrer Anleitung in FHEM installiert.
Unter "Unsorted" habe ich nun ein neues device welches wie folgt aussieht:

Internals
DEF 10.0.1.160 8RA......P70 /usr/local/bin
NAME TradfriGW
NR 44
STATE IDLE
TYPE TradfriGateway
canConnect 1
gatewayAddress 10.0.1.160
gatewaySecret 8RA.......P70
name TradfriGW

Readings
coapClientVersion    coap-client v4.1.1 -- a small CoAP implementation    2017-07-14 22:54:40



Sobald ich nun aber "get TradfriGW deviceList" in FHEM eingebe erhalte ich den Fehler "Error while trying to fetch devices!"

Was mir noch aufgefallen ist: Wenn ich den Coap Befehl aus der Tradfri.pm direkt ins Terminal eingebe:
Mac-Mini:~ Solbadguy2010$ coap-client -u Client_identity -k 8RA......P70 -v 1 -m GET coaps://10.0.1.160:5684/15001
coap-client: illegal option -- u


Können sie mir helfen? Was mache ich falsch?

Vielen Dank!

Peter Kappelt

Guten Abend,

möglicherweise ist die von brew verteilte libcoap einfach zu alt. Bitte posten Sie die Ausgabe von "coap-client", bzw. "coap-client -h", damit können weitere Diagnosen vorbereitet werden.

Falls das der Fall ist, muss libcoap selbst kompilliert werde - wie in der Anleitung beschrieben.
Alternativ stellen die Entwickler von libcoap auch vorkompillierte Versionen unter https://libcoap.net/files/ bereit. Ich bin mir nicht sicher, ob eine der vorbereiteten Architekturen für Ihren Mac Mini passt. Am Wahrscheinlichsten ist der coap-client aus dem Ordner amd64.
Diesen können Sie in einen beliebigen Ordner herunterladen. Das Attribute "coap-client-path" in der Definition des Gateways muss dann zu dem Pfad geändert werden, wo der heruntergeladene Coap-Client liegt.

Viele Grüße,
Peter Kappelt

solbadguy2010

Hallo,
danke für die schnelle Antwort.

ich habe auch gerade die Master-Version selbst kompiliert. Es bliebt bei der v4.1.1.

Hier die gewünschten Ausgaben:

Mac-Mini:libcoap-master Solbadguy2010$ coap-client
coap-client v4.1.1 -- a small CoAP implementation
(c) 2010-2013 Olaf Bergmann <bergmann@tzi.org>

usage: coap-client [-A type...] [-t type] [-b [num,]size] [-B seconds] [-e text]
[-g group] [-m method] [-N] [-o file] [-P addr[:port]] [-p port]
[-s duration] [-O num,text] [-T string] [-v num] URI

URI can be an absolute or relative coap URI,
-A type... accepted media types as comma-separated list of
symbolic or numeric values
-t type content type for given resource for PUT/POST
-b [num,]size block size to be used in GET/PUT/POST requests
        (value must be a multiple of 16 not larger than 1024)
        If num is present, the request chain will start at
        block num
-B seconds break operation after waiting given seconds
(default is 90)
-e text include text as payload (use percent-encoding for
non-ASCII characters)
-f file file to send with PUT/POST (use '-' for STDIN)
-g group join the given multicast group
-m method request method (get|put|post|delete), default is 'get'
-N send NON-confirmable message
-o file output received data to this file (use '-' for STDOUT)
-p port listen on specified port
-s duration subscribe for given duration [s]
-v num verbosity level (default: 3)
-O num,text add option num with contents text to request
-P addr[:port] use proxy (automatically adds Proxy-Uri option to
request)
-T token include specified token


Mac-Mini:libcoap-master Solbadguy2010$ coap-client -h
coap-client: illegal option -- h

solbadguy2010

Ich nochmal.
Jetzt geht es.

ich habe noch mal alles entfernt und mich strikt an die Anleitung gehalten.

ich hatte beim ersten mal diese Zeilen vergessen:

git checkout dtls
git submodule update --init --recursive


Danke für die Hilfe!

solbadguy2010

Hallo Nochmal.
leider habe ich den nächsten verrückten Fehler.
ich habe jetzt alle Lampen und Gruppen in FEHM.
Wenn ich mit der IKEA App die Lampen steuere sehe ich die Veränderung auch sofort im FHEM.

Leider geht es anders herum nicht. Die Lampen reagieren nicht auf FHEM. Woran kann das liegen?

Danke!

Brause

Zitat von: Peter Kappelt am 14 Juli 2017, 22:41:35
Erstmal das Einfachste: Bist du dor sicher, dass du den Java-Client mit dem Parameter "-s" aufrufst? Der ist inzwischen notwendig geworden. Also soll dann heißen: "java -jar kCoAPSocket.jar -s DeinGatewayPasswort".

Gut.
Das sich der Aufruf der Java geändert hat das habe ich übersehen.
Jetzt funktioniert es wieder wie vor dem update.
Aber mein subjektiver Eindruck, etwas zeitverzögerter als vorher.

vertikus

Zitat von: Peter Kappelt am 16 April 2017, 15:07:07
Guten Tag an Alle,

seit einigen Tagen gibt es auch in deutschen IKEA-Märkten das Trådfri-System zu kaufen. Natürlich bietet es sich perfekt zur Integration in die FHEM-Installation an.
Ich habe für meinen Setup ein Modul entwickelt und möchte das nun auch euch zur Verfügung stellen.
Der Sourcecode, inklusive einer kurzen (englischen) Anleitung findet ihr unter https://github.com/peterkappelt/Tradfri-FHEM .

Das Modul befindet sich noch in der Entwicklung. Grundfunktionen sind problemlos nutzbar. Erweiterte Funktionen (Stimmungen, Pairen von Geräten, Steuern von Gruppenmitgliedschaften, ...) sind derzeit noch nicht unterstützt. Die Funktionen, die unterstützt sind, sind auf der Github-Seite aufgelistet.

Instabilitäten, die die gesamte FHEM-Installation beeinflussen, sollten eigentlich nicht mehr auftreten.

Falls ihr euch auch von IKEA solche Lampen kaufen möchtet, beachtet bitte, dass eine einzelne Lampe und ein Gateway nicht genug sind - darauf bin ich auch reingefallen. Ihr benötigt zu besagtem mindestens noch ein Steuergerät, wie beispielsweise einen Dimmer. Nur mit diesem können Gateway und Lampen gekoppelt werden. Diese Tatsache ist aber nicht auf den IKEA-Produktseiten hinterlegt, in den Anleitungen steht es jedoch.

Ich hoffe, dass das Modul vielleicht jemanden nutzt. Über ein Feedback, wenn ihr es probiert, würde ich mich freuen!

Einen schönen Nachmittag,
Peter Kappelt

Update: Ich kam heute noch etwas weiter mit der Entwicklung. Nun wird ein separates Device zur Parametrisierung der Verbindung genutzt, außerdem kann man Gruppen steuern.
Update: Hinweis zur höheren Stabilität
Update: Aktueller Entwicklungsstand

Brause

Ich schon wieder

Habe jetzt nochmal ein wenig an meiner Software-Installation gebastelt.
und jetzt ist alles Perfekt.

Das Gateway wird direkt beim FHEM-Start als opened gemeldet.
Gruppen und einzelne Lampen schalten ohne Verzögerung und auch ohne verzögerten Event im jeweils anderem Device.

Die screen/java-Geschichte läuft mit Benutzer fhem. Dieser hat als Rechte-Gruppen nur dialout und tty.
Und das alles als Server Start-Script automatisiert.

Problem schien gewesen zu sein, das die Java schon laufen muss, bevor FHEM startet.
Sonst hatte ich eigenartige Phänomene.

Danke nochmal Peter für Deine Arbeit.
Gruss Brause