IKEA Trådfri Modul

[pronson]

aber das Gateway kann doch "irgendwo" hängen wo es Netzwerk gibt, für PowerLAN bräuchtest du doch auch einen Ethernet Anschluss?
oder gibt es den nur im allerliebsten Keller und die Tradfri Lampen sind für den Dachboden?

Also wenn sich dieser post auf #117 bezieht, dann reden wir aneinenader vorbei. Ich habe keine Netzwerkprobleme. Sonder möchte lediglich auch die sensoren von tradfri verwenden können. Wenn sich die borherigen post auf etwas anderes beziehen, dann werde ich meine post löschen *verwirrt*


Gesendet von iPhone mit Tapatalk

[Mickey Mouse]

so wie ich das verstanden habe, hat "Neuhier" nicht auf deine Frage/Problem geantwortet, sondern eine neue Frage in den Raum gestellt, darin geht es um die Netzwerkanbindung des Gateway (glaube ich zumindest).
ich verstehe nicht, warum man für das Gateway eine Power-LAN Verbindung nutzen sollte. Der eine Teil solch einer Verbindung benötigt doch auch einen Netzwerk Anschluss und da kann man das Gateway doch auch direkt anschließen, so ist mein Gedankengang.

um nicht noch mehr Verwirrung zu stiften, werde ich die anderen Antworten/Fragen in eigene Beiträge schreiben und nicht hier alles zusammen fassen

[Mickey Mouse]

Mir geht es darum, dass ich z.B. Den bewegungsmeldet in fhem einbinden kann.

Vorsicht, nur gefährliches Halbwissen:
soviel ich weiß arbeitet das Trådfri Modul nicht Event gesteuert sondern pollt den Status der Devices und auch das nur mit gesetztem Intervall attr.

um also zeitnah reagieren zu können, müsstest du auch entsprechend oft die Devices pollen. Ich glaube kaum (s.o. Halbwissen...), dass man das im Sekunden Takt machen kann?!?

weiterhin kann man den Status der Bewegungsmelder direkt gar nicht auslesen (auch wieder nur so wie ich das z.Z. sehe) und tatsächlich den "Umweg" über ein vom Bewegungsmelder gesteuerten Device oder Gruppe gehen.

[Mickey Mouse]

"klammheimlich" gab es ein Update für das Modul.
Rückmeldung:
- die moods funktionieren jetzt bei mir auch wenn die Gruppe vorher aus war. Mehrfach mit verschiedenen Gruppen getestet und hat immer geklappt!
- in der DropDown Liste tauchen hier "nur" die 3 von Ikea vordefinierten moods auf (ich habe jetzt gar nicht getestet was passiert wenn davon einen löscht?), die selbstdefinierten tauchen dort nicht auf

[Peter Kappelt]

Hallo,

Wäre es nun möglich mit fhem den status dieser Gruppe auszulesen? Dim level, ein/aus, etc. und bei aktion eines aktors kann ich dann cia fhem die lampen, welche in einer anderen Gruppe sind einschalten?

Ja, ist es. Aber, wie schon oft gesagt, bitte aufpassen: Du hast immer eine Verzögerung bei der Aktualisierung.

Theoretisch (und auch praktisch) ist es zwar möglich, sekündlich zu pollen - allerdings ist das keine gute Idee. Eine ganze Menge System- und Netzwerklast wird verursacht, was nicht der Sinn des Protokolles ist.

Vom Protokoll ist das Pollen eigentlich auch nicht notwendig. Allerdings gibt es für das Coap-Protokoll keine nativen Perl-Libraries. Für mich öffnen sich dann zwei große Optionen:
- Ich könnte einen zweiten Perl-Thread asynchron laufen lassen. Der ist dann damit beschäftigt, die Ausgaben des coap-clients (C-Software) mitzuschneiden und bei Bedarf an FHEM zu senden.
- Die universelle Lösung, mit der ich einen größeren Rahmen als das Forum und die FHEM-Community bedienen würde: Für Perl eine Coap-Implementierung entwickeln/ portieren.

Beides ist ein ziemlich großer Block Arbeit - ich schrecke daher noch etwas vor beiden zurück. Gibt es Perl- oder Linuxentwickler, die freie Kapazitäten haben und sich hier mit einarbeiten und helfen wollen?

@Mickey Mouse
Sei mal mutig 
Führe in der FHEM-Kommandozeile "set Gruppe mood deine-eigene-stimmung" aus. Das sollte schon funktionieren. Wenn du danach die Seite nochmal neu lädst (oder erneut zu dem Device navigierst), sollte auch die Liste aktualisiert sein.
Alternativ sollte auch ein "get Gruppe moods", mit nachfolgender Aktualisierung der Seite ausreichend sein.
Ist beides vielleicht noch nicht optimal/ ausreichend dokumentiert, mal schauen.

Übrigens: So wie es aussieht, kann man die IKEA-Moods gar nicht löschen (in der App).

Schönen Abend,
Peter

[pronson]

Hallo,
Ja, ist es. Aber, wie schon oft gesagt, bitte aufpassen: Du hast immer eine Verzögerung bei der Aktualisierung.

Theoretisch (und auch praktisch) ist es zwar möglich, sekündlich zu pollen - allerdings ist das keine gute Idee. Eine ganze Menge System- und Netzwerklast wird verursacht, was nicht der Sinn des Protokolles ist.

Vom Protokoll ist das Pollen eigentlich auch nicht notwendig. Allerdings gibt es für das Coap-Protokoll keine nativen Perl-Libraries. Für mich öffnen sich dann zwei große Optionen:
- Ich könnte einen zweiten Perl-Thread asynchron laufen lassen. Der ist dann damit beschäftigt, die Ausgaben des coap-clients (C-Software) mitzuschneiden und bei Bedarf an FHEM zu senden.
- Die universelle Lösung, mit der ich einen größeren Rahmen als das Forum und die FHEM-Community bedienen würde: Für Perl eine Coap-Implementierung entwickeln/ portieren.

Beides ist ein ziemlich großer Block Arbeit - ich schrecke daher noch etwas vor beiden zurück. Gibt es Perl- oder Linuxentwickler, die freie Kapazitäten haben und sich hier mit einarbeiten und helfen wollen?

@Mickey Mouse
Sei mal mutig 
Führe in der FHEM-Kommandozeile "set Gruppe mood deine-eigene-stimmung" aus. Das sollte schon funktionieren. Wenn du danach die Seite nochmal neu lädst (oder erneut zu dem Device navigierst), sollte auch die Liste aktualisiert sein.
Alternativ sollte auch ein "get Gruppe moods", mit nachfolgender Aktualisierung der Seite ausreichend sein.
Ist beides vielleicht noch nicht optimal/ ausreichend dokumentiert, mal schauen.

Übrigens: So wie es aussieht, kann man die IKEA-Moods gar nicht löschen (in der App).

Schönen Abend,
Peter

Hallo Peter,
Da scheint sich jemand die selben Gedanken gemacht zu haben. Nur leider ist er auch noch zu keiner Endlösung gekommen.
https://www2.htw-dresden.de/~wiki_sn/index.php/CoAP/Vergleich_möglicher_Implementierungen


Gesendet von iPhone mit Tapatalk

[FunkOdyssey]

Am Rande.
Beim Starten von FHEM erscheinen folgende Warnungen:

Code Auswählen Erweitern

2017.07.05 10:13:39.548 1: PERL WARNING: Smartmatch is experimental at ./FHEM/30_TradfriGateway.pm line 100, <$fh> line 3586.
2017.07.05 10:13:39.550 1: PERL WARNING: Smartmatch is experimental at ./FHEM/30_TradfriGateway.pm line 124, <$fh> line 3586.
2017.07.05 10:13:39.628 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 102, <$fh> line 3590.
2017.07.05 10:13:39.629 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 113, <$fh> line 3590.
2017.07.05 10:13:39.631 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 127, <$fh> line 3590.
2017.07.05 10:13:39.632 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 141, <$fh> line 3590.
2017.07.05 10:13:39.634 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 157, <$fh> line 3590.
2017.07.05 10:13:39.636 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 171, <$fh> line 3590.
2017.07.05 10:13:39.637 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 186, <$fh> line 3590.
2017.07.05 10:13:39.638 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 200, <$fh> line 3590.
2017.07.05 10:13:39.640 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 214, <$fh> line 3590.
2017.07.05 10:13:39.641 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 228, <$fh> line 3590.
2017.07.05 10:13:39.643 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 242, <$fh> line 3590.
2017.07.05 10:13:39.644 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriDevice.pm line 256, <$fh> line 3590.
2017.07.05 10:13:39.709 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 107, <$fh> line 3600.
2017.07.05 10:13:39.710 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 119, <$fh> line 3600.
2017.07.05 10:13:39.712 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 132, <$fh> line 3600.
2017.07.05 10:13:39.714 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 157, <$fh> line 3600.
2017.07.05 10:13:39.715 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 174, <$fh> line 3600.
2017.07.05 10:13:39.717 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 188, <$fh> line 3600.
2017.07.05 10:13:39.718 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 202, <$fh> line 3600.
2017.07.05 10:13:39.719 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 217, <$fh> line 3600.
2017.07.05 10:13:39.722 1: PERL WARNING: Smartmatch is experimental at ./FHEM/31_TradfriGroup.pm line 257, <$fh> line 3600.

[Clyde]

Hab hier auch noch einen Schönheitsfehler? gesehen.

[Peter Kappelt]

Danke für die Hinweise, beides behoben.

[Neuhier]

So sorry
Hatte bei o.g. Beitrag vergessen @Peter Kappelt davorzuschreiben.
An dem Platz, wo mein Gateway landen soll, ist kein Router.
Daher die Idee mit dem Power-LAN.

[philippr]

Ich nutzte (für den WAF) eine HM-Unterputz-Wandsender um meine Trådfri-Gruppe per Notify ein- und auszuschalten. So kann die Frau ganz normal die Lampen an der Wand schalten ohne ihr Smartphone oder eine Fernbedienung zu suchen.

Das Notify sieht so aus:

Code Auswählen Erweitern

wz_Wandtaster_CH1:Short.* { if (Value("wz_Licht_Gruppe") eq "off") {fhem("set wz_Licht_Gruppe on")} else { fhem("set wz_Licht_Gruppe off")}}

Der 2. Kanal sieht gleich aus, damit auf jeder Seite der Wippe das Gleiche passiert.

Der Taster hat auch eine "Long"-Funktion. Es wäre natürlich toll, wenn ich da die Dimmfunktion ansteuern könnte. Geht das? Gibt es ein dimUp oder dimDown Command?

[Peter Kappelt]

Guten Abend,

dimUp und dimDown gibt es (noch) nicht, habe ich mir aber mit notiert.

Gute Nachrichten: Ich bin in den letzten Tagen mit der Neu-Implementierung des CoAP-Protokolles weitergekommen.
Ich habe mich dabei gegen ein natives Perl-Modul entschieden - das würde einfach zu viel Zeit in Anspruch nehmen. Es ist jetzt ein kleiner Socket-Client, auf Basis der Californium-Software, geworden. Soll heißen: Ein Java-Programm. Das bedeutet für die Zukunft, dass Nutzer des Modules auf ihrem System Java installiert haben müssen. Das ist keine Lösung, die mir zu einhunder Prozent gefällt - allerdings die, die am ökonomischsten ist.

Möglicherweise kann ich dann direkt mit dem Modul eine JRE ausliefern - das erspart zumindest dem Nutzer die Installation derer. Alternativ möchte ich mir auch den GCJ anschauen.

Mittels dieser neuen Implementierung ist es jetzt auch die (Quasi-) Echtzeit-Aktualisierung der Daten möglich. Ich habe den neuen Client bereits für TradfriDevice implementiert. Liegt im Github-Repo im Branch dev-cf.

Hat jemand Lust, das ganze in der näheren Zukunft mal zu testen? Vorraussetzung sind die Trådfri-Komponenten und ein System, dass nicht unbedingt kritisch ist. An der Stabilität und der Überwachung bestimmer Fehlerzustände arbeite ich noch.
Natürlich schreibe ich für eventuelle Beta-Tester noch eine Anleitung. Ich bin auch, in gewissen Maßen, bereit, privaten Support über Telefon/ TeamViewer o.ä. zu geben.

Schönen Abend,
Peter

[dtavb]

Hoi Ihr,

nachdem ich jetzt doch viel positives über das Tradfri System gelesen habe, bin ich ab in Ikea und habe mich eingedeckt - auch nachdem ich diesen Thread entdeckt habe.
Boah sehr schön gemacht Peter und vielen lieben Dank für Dein Engagement, funktionierte auf anhieb die Lampen einzurichten!
Die Reaktionszeiten sind der Hammer. Habe einen 433Mhz PIR Bewegungsmelder und einen Fibaro Motion Sensor probiert, mit beiden schalten die Tradfri Lampen in kürzester Zeit.
Vorher habe ich IT-Dosen oder WiFi-Dosen mal so mal so verwendet. Beide sind langsamer wie die Tradfri-Lösung, fast unmittelbar nach auslösen der Bewegungsmelder geht das Licht an
Den IKEA Bewegungsmelder finde ich optisch ganz nett, weshalb ich diesen auch gleich gekauft habe und einbinden wollte.

Frage zu Bewegungsmelder:
Kann man den Bewegungsmelder auch schon einbinden?

Zu Deinen Freiwilligen:
Ich würde mich zur Verfügung stellen - Freiwillige gibt es nicht so viele
Ob ich allerdings der richtige Kandidat bin, kann ich Dir nicht sagen.
Mein Pi ist natürlich bei mir relativ produktiv eingesetzt: Terrarium, sämtliche Lichter in der Wohnung, Strommessung, LED-Strips&Controller, Sensoren etc.
Allerdings kann ich fast gut damit leben wenn die Tradfris mal nicht funktionieren - ITler halt:)
Wenn Du das Java-Geraffel als eher zu viel Bastelei in einer Produktion ansiehst, habe ich noch einen 2. Pi.
"Kurz" geklont, kann ich mit diesem spielen.

Kleine Anmerkdung zur Tradfri GW & fhem Performance
In bestimmten Konstellationen (zB Umbau Netzwerk ohne Restart von Tradfri Gateway oder Pi) scheinen sich fhem & tradfri Modul irgendwie auszubremsen.
Habe Heute mein Netzwerk & Strom etwas anders verkabelt. Dabei musste ich den DHCP&DNS Server (NAS) herunterfahren. Sprich fhem auf Pi, Tradfri GW, Router und Switch hatten diese Services nicht zur Verfügung. Als ich dann alles wieder hochgefahren habe (VMs&NAS'es) ging erstmal alles. Ich habe mich nur gewundert, dass fhemweb sehr sehr langsam war.
Manchmal drehte der Browser durch, dann ging es wieder einige Sekunden sehr schnell. Das Tradfri System habe ich nicht getestet, war ja hell
Erst nachdem ich das Tradfri-Device vorhin stromlos gemacht habe, läuft fhemweb etc. wieder flott.

Hast Du dazu eine Idee, bzw. kann sich da etwas totlaufen in fhem?

Danke Dir und Grüsse,
dtavb

[Peter Kappelt]

Guten Tag,

freut mich zu hören, dass meine Arbeit Verwendung findet!

Wie man(n) die aktuelle Entwicklungsversion nutzt habe ich auf folgender Seite niedergeschrieben: http://electronic.kappelt.net/wordpress/de/ikea-tradfri-module-for-fhem-beta/
In den letzten Tagen hat sich in der Entwicklungsversion einiges getan. Dein ganzes System sollte nicht beeinflusst werden - höchsten Tradfri hängt bei der Verwendung halt.

Zu deinen Fragen:

1. Den Bewegungsmelder kann man nicht direkt einbinden - das ist auch von IKEA gar nicht vorgesehen möglich. Der BWM verhält sich transparent und steuert lediglich eine Gruppe oder eine Lampe an. Genauso verhält es sich mit den Fernbedienungen - die können einfach nicht ausgelesen werden.
Du kannst dir aber helfen, in dem du eine Gruppe erstellst, in der sich nur der Bewegungsmelder befindet. Diese Gruppe kannst du dann im FHEM definieren.

2. Wie schon oben gesagt: Probleme, die sich auf das gesamte System auswirken, habe ich nicht beobachtet und wüsste auch nicht, wo die auftreten sollten. Ich habe meine Entwicklungsversion auch schon auf meiner produktiven Installation im Einsatz. Ich möchte eine möglichst große Zahl an Szenarios durchtesten (lassen), bevor ich die "offiziell freigebe".

3. Performance
Ja, das hat was mit der aktuellen Implementierung zu tun. Erstmal musst du wissen, dass mit FHEM ein externes Programm synchron aufgerufen wird. Somit wird FHEM solange blockiert, bis das Programm sich wieder beendet hat. Falls auf der spezifizierten IP aber niemand antwortet, wird lt. Protokollspezifikation erstmal gewartet - bis zu einem Timeout. Der ist in der Master-Version auf 5 Sekunden gesetzt.
Im Endeffekt heißt das, dass für jedes spezifizierte Gerät, das nicht erreichbar ist, FHEM für bis zu 5s blockiert wird.
Daran kann man bestimmt noch arbeiten - meiner Vorstellung nach soll aber der aktuelle Master-Branch so bald wie möglich durch die aktuelle Entwicklung ersetzt werden. Ich sehe die Version als Auslaufmodell und möchte daran nicht mehr weiter herumbasteln. Mit der neuen Implementierung wird die Kommunikation mit dem Gateway asynchron ablaufen und FHEM nicht blockieren.

Dankeschön!

Viele Grüße,
Peter

[Brause]

Guten Morgen

Ich habe gerade mal mein System auf die neue Java-Variante umgestellt.

1. ich hatte versucht den Java Start im screen per shell-script zu automatisieren.
    Funktioniert ja auch fast.
    Ich muss mich dann doch einmal in den screen-Task wechseln um mein root-Passwort einzugeben.
    Der root scheinen ja unabdinglich zu sein, jedenfalls hat es mit einem User der auch zur root-Gruppe gehört nicht funktioniert.
    gut eine Minute später ein reopen auslösen und der Gateway läuft.

2. schalte ich im FHEM eine Lampe wird das Licht auch geschaltet, jedoch ändert sich im FHEM der state/STATE nicht.
    Zeitverzögert ändert sich dann der zustand der Gruppe.

3. in der Gruppe funktioniert der STATE beim schalten der Gruppe, das Reading state kommt zeitverzögert.


Da ich einzelne Lampen aus einer Gruppe als Bewegungsmelder-Nachlicht nutze wäre die Zustandsänderung in der entsprechenden Lampe schon schön.
wäre es auch möglich bei Status-Änderung des Gateways ein readingsupdate für den state mit event auszulösen ??


Soweit erstmal die Beobachtungen direkt nach der Installation.

Gruss Brause