Not discovered

[okachobi]

I've started the service successful on an iMac with Java 8, specified my wired IP address, registerred the rest endpoints of on/off successfully, then requested Echo to discover through the echo.amazon.com interface with no luck.

I have several wifi access points, so I thought it might be an issue with my wireless router not bridging the UPNP to the wired network, so I turned on the wifi on the iMac (which should have put it on the same AP) and used that address for the upnp listener and still no luck.

Is there something I might be missing? My next steps are to do some packet sniffing and make sure I can see the UPNP broadcasts, and was also planning on trying the code on a linux server instead of OSX. I've confirmed that nothing is listening on the required ports. I see no exceptions in the log and actually no activity to suggest that Echo actually attempted a connection. I also see the ports 1900, 50000, and 8080 in the netstat as being bound once the server starts. It looks like everything on the server side is working and I'm wondering if Echo received an update that has stopped this from working or if I have something wrong. I'm using the switch prefer ipv4 as well.

I'd love to get this working since I really wanted to bridge Echo to my own light gateway that I had developed for sending commands to arduino/jeenode driven lights on 433mhz. ( https://code.google.com/p/arduino-aaser-gateway/ )

[armzilla]

is the wireless network that the Echo is using on the same subnet as your wired? Not personally sure how to get multicast to work across subnets. If they are both on the same subnet then we might have to attack this problem with packet capture like you mentioned.

[okachobi]

It is. I had to confirm though that the way I configured the VLAN was bridging the multicast, and I believe it is.

Is there some way to turn on debug log in the com.armzilla.* classes without rebuilding? I tried the --debug switch in spring boot but it only turned on debug for the springboot classes. I also tried overriding the log4j property to designate the log4j.xml but that didn't seem to work. And I edited and repackaged the application.properties file with the logging.level.* set to DEBUG and it didn't seem to do it.

I'll do some packet captures from the server to see if it sees the traffic from the Echo but I saw some log statements in the source that I'd like to watch in the log as well.

[okachobi]

I moved the Echo to a different AP and it now discovered the service :+1:

This means my VLAN isn't bridging the multicast packets properly. I'm going to have to look into that separately. Now I just have to figure out how to delete a registration. It looks like I registered the same services twice and they show up twice on echo.

[okachobi]

After further testing everything is working! I commanded my arduino/jeenode RGB LED light with this! I deleted the prior entries using DELETE with /api/devices/ altering issuing a GET to /api/devices to get the ID. :+1:

I did find what appeared to be a bug. The URL I registered for my own lightgw service was mistyped and so I had to delete the device and add it again then rediscover from echo, but the amazon-echo-ha-bridge was returning an error to the amazon echo. I had to restart the springboot container and then it worked. I'm not sure what was going on, but when I stopped the container I got an exception:

org.apache.http.impl.execchain.RequestAbortedException: Request aborted at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:176) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) at com.armzilla.ha.hue.HueMulator.doHttpGETRequest(HueMulator.java:159) ...

I don't know if that is related and I'm not sure what happened there. My lightgw service doesn't log requests that don't match a correct pattern so I wash't sure if it called it or what the result code was. I didn't see the response logged on echo-bridge either.

Next request - Echo supports light levels- like 50%. Could you add the ability to specify a setLevel handler with a macro field for the percent value 0-100 in the url? (preferably with the ability to repeat the macro in the url - though I could add a request for just 1 level and map it to each color)

My lightgw ( https://code.google.com/p/arduino-aaser-gateway/source/browse/LEDServer/lightgw.py ) can handle a request like:

/lightgw//color///

and can then set the appropriate level for the light. I think I'm currently taking 0-255 values, but I could add a new request for doing percent_color. I had also planned to level setting of an existing scene color. I can't remember yet if I added that into the firmware code yet but its an easy add.

[armzilla]

Glad it is working!

The echo sends an integer percentage to the hue for the dimming functionality. I was working on dimming a few days ago and should have something this weekend.

[armzilla]

i was completely wrong on the value sent. The hue uses an 8 bit value for its brightness level.

[okachobi]

0-255 then?

[armzilla]

i can expose two variables to support dimming. One would be a percentage to support the vera, the other will be an eight bit value 0-255 for your use.