OpenNethome - an open home automation project

I have added basic support for the IKEA Trådfri remote controlled light bulbs (see http://nethomeserver.blogspot.se/). Currently I have added Items for the Gateway (http://wiki.nethome.nu/doku.php?id=IkeaGateway), Fixed color temperature lights (http://wiki.nethome.nu/doku.php?id=IkeaLamp) and the lamps with variable color temperature (http://wiki.nethome.nu/doku.php?id=Ikea ... ratureLamp).
I have only tested it with the bulbs so far, but I think (hope) that it will work with the LED surfaces too, if anyone has that and tests it with OpenNetHome, please write a line here and tell how it went.

Thanks, Stefan. Fantastic work with the NetHomeServer - as always!

Hi All,

First of all, big Thanks for all of you, especially Stefan for the latest development efforts. It has been a year since I touched the system, but now finally upgraded to latest nightly in order to test some IKEA Trådfri equipment. The upgrade process and Trådfri GW + bulb install was flawless, couldn't be much easier!

Some initial thoughts and feature requests on Trådfri support in NHS today;
- Would be nice to be able to adjust the colour temp in the same way than brightness (e.g. colder/warmer buttons). Today you cannot do this from ONH GUI (other than adjusting the ColorTemperature attribute and "Applying", a bit cumbersome).
- How about support for the IKEA remotes? They are cheap, with a clever magnetic holder, have 5 buttons and seem to work very reliable together with the Trådfri GW. Could one pair the remote only with the GW only (not with any lamps) and let ONH to catch the command and then do some magic - not only with Trådfri bulbs, but with anything connected to an ONH installation e.g. NEXA lamps (or really anything else thru a custom action; exec, python etc)? Pls look into this. (The same request goes for the dimmer, but I don't have one yet).
- ColourTemp value could be also visible on the item page where you now list State, LampModel, Version, Brightness and ID info.

Thanks again!

BR,
Mikko

Hi again,

After first hours of testing with the Ikea Trådfri stuff, I have experienced issues with the gateway connection. The connection fails after few minutes and never gets fixed again. The only work-around I have found is to delete and re-create the GW item, but it's obviously not very feasible fix. I'm using the latest nightly build.

Have others had connectivity issues with the Trådfri Gateway?

Br,
Mikko

I have not seen that, when it happens, can you still control the lamp with the app?

/Stefan

Hi,

Yes, I can (via the IKEA iPhone app).

Did some more testing now. Created a new IKEA Gw item once more and it took about 4 minutes to get disconnected. I used the trådfri remote, iPhone app and ONH GUI to control the lamp (on/off, dimming, color temp etc).

In Server log window I see this;
17.08.15 11:51:12 CoapEndpoint Destroying endpoint at address 0.0.0.0/0.0.0.0:0
17.08.15 11:51:12 DTLSConnector DTLS connector listening on [{0}] with MTU [{1}] using (inbound) datagram buffer size [{2} bytes]
17.08.15 11:51:12 CoapEndpoint Starting endpoint at 0.0.0.0/0.0.0.0:0
17.08.15 11:51:02 ReliabilityLayer Endpoint is being destroyed: skipping retransmission
17.08.15 11:51:02 CoapEndpoint Destroying endpoint at address 0.0.0.0/0.0.0.0:0
17.08.15 11:51:02 DTLSConnector Stopping DTLS connector on [{0}]
17.08.15 11:51:02 CoapEndpoint Stopping endpoint at address 0.0.0.0/0.0.0.0:47767
17.08.15 11:46:40 CoapEndpoint Destroying endpoint at address 0.0.0.0/0.0.0.0:0
17.08.15 11:46:40 DTLSConnector DTLS connector listening on [{0}] with MTU [{1}] using (inbound) datagram buffer size [{2} bytes]
17.08.15 11:46:40 CoapEndpoint Starting endpoint at 0.0.0.0/0.0.0.0:0
17.08.15 11:46:28 CoapEndpoint Destroying endpoint at address 0.0.0.0/0.0.0.0:0
17.08.15 11:46:28 DTLSConnector Stopping DTLS connector on [{0}]
17.08.15 11:46:28 CoapEndpoint Stopping endpoint at address 0.0.0.0/0.0.0.0:49050
17.08.15 11:45:16 TCPCommandPort$Session Disconnected from 127.0.0.1
17.08.15 11:45:08 TCPCommandPort Connection from 127.0.0.1

After getting disconnected, I immediately created yet another GW item and will let it be without playing with the lamp. Let's see if it stays connected or not. EDIT: It did not stay connected. This time I did not touch the ONH, but only shut down the only lamp I have from the remote. Some more log;
17.08.15 12:19:12 TCPCommandPort$Session Disconnected from 127.0.0.1
17.08.15 12:19:12 TCPCommandPort$Session Failed reading from socket in TCPCommandPort java.net.SocketException: Connection reset
17.08.15 12:19:11 TCPCommandPort Connection from 127.0.0.1
17.08.15 12:15:16 TCPCommandPort$Session Disconnected from 127.0.0.1
17.08.15 12:15:08 TCPCommandPort Connection from 127.0.0.1
17.08.15 12:13:07 TCPCommandPort$Session Disconnected from 127.0.0.1
17.08.15 12:13:07 TCPCommandPort Connection from 127.0.0.1
17.08.15 12:00:16 TCPCommandPort$Session Disconnected from 127.0.0.1
17.08.15 12:00:08 TCPCommandPort Connection from 127.0.0.1

How could I get more detailed log of what's going on? Or do you already have an idea what might be wrong based on the log above?

Br,
Mikko

Hi, thanks for the logs. Unfortunately they do not give me much more information. I don't see this behavior in my system, so there must be something different in your setup that triggers this problem. One thing I was thinking about - when you have to recreate the GW-Item, does it get the same IP-Address or is it a new one?

Also, what hardware are you running on?

Hi,

I have fixed the ip address for the gw to rule out the potential problem with a changing ip. This does not help.

Any chance to get more precise log out of the system? I'd like to see does ONH even try to reconnect once the connection is lost.

I don't have anything special in my configuration: all the devices are in the same lan/subnet, no firewalls etc. The Gw is accessible via the phone app and always replies to ping.

Oh, and I'm running ONH on a raspberry pi.

Thanks again!

BR,
Mikko

Ok, pity about the IP, because that would have been my best guess. Actually, the Coap protocol used to communicate with the gateway is based on UDP/IP, so in reality there is never any "connection" with the gateway. Every message is fired as an UDP-message, and then I wait for an UDP-message back, when I expect a response, otherwise it is "fire and forget". The "Connected" state is just a way of showing to the user if we are succeeding in sending messages. If I fail in sending a message, the state is "disconnected" until I succeed in sending one. So there is no real connection that has to be reestablished.

Just to make really sure, could you please double check that the IP-Address in the Item is always the same, every time you have to recreate the GW-Item?

Hi,

Yes, the ip is always the same.

I was thinking (now when you mentioned udp), could this happen if there was packet loss between the onh server (raspberry pi) and ikea gw? Onh is running behind a "power socket network adapter" connection and it might drop some packets occasionaly. With tcp this is not an issue.

But why doesn't it get "reconnected" at all, ever?

Again, is there anything I could do to get more detailed log info (if implemented in the code)?

Edit. My Ikea GW version is 1.1.0015 (ie. latest one). Could there be some changes in the specs/api? Could you check your gw version (can be seen in the app->settings).

Br,
Mikko