bwssytems / ha-bridge

Home automation bridge that emulates a Philips Hue light system and can control other systems such as a Vera, Harmony Hub, Nest, MiLight bulbs or any other system that has an http/https/tcp/udp interface. This is a compact impl to run on small format computers. This is impl started from this project https://github.com/armzilla/amazon-echo-ha-bridge.
Apache License 2.0
1.45k stars 198 forks source link

Message: Address already in use: Cannot bind #181

Closed smarty125 closed 7 years ago

smarty125 commented 7 years ago

I am trying to send some UDP packets to control my Limitless LED lights.... similar to what is in the article: http://codecorner.galanter.net/2016/05/12/full-control-of-your-limitless-ledmilight-bulbs-from-amazon-echo/

Upon testing my On/Off udp actions, I get an error message that says: 10-06-2016 13:20:49.043 WARN Change device state, Could not send data for network request: udp://192.168.0.60:8899/0x450055 with Message: Address already in use: Cannot bind com.bwssystems.HABridge.hue.HueMulator

my "On" URL looks like: {"item":"udp://192.168.0.60:8899/0x450055"} I have also tried udp://192.168.0.60:8899/0x450055

I get the same error message.

I know that my Limitless LED wifi brifge does work because I can send it commands via a software called "PacketSender". I am using another computer on the same network to send these upd packets. My LED lights respond PROPERLY (same IP address -192.168.0.60 and port number 8899) when sending udp messages in this fashion.

So, my question is why can't the ha-bridge send out udp? or what might be stopping the ha-bridge??? I am copying everything in the article....at least I think so....

bwssytems commented 7 years ago

So, it looks like you have another application on the ha-bridge running on 8899. The ha-bridge just re-uses the port you are trying to send to as it's datagram port. I'll need to update that and use the upnp response port as that would be a better selection. If you can stop that process using that port, it should work for the interim.

smarty125 commented 7 years ago

I am not sure I have any other "applications" on the ha-bridge using port 8899.

I may have other "devices" that use a similar URL call. Is that what you mean? FYI...I didn't mean to CLOSE this...

bwssytems commented 7 years ago

There is something that has that port open and the reason why the bridge can't send if you are on a linux variant (includes MACOs) run this on your command line:

sudo netstat -pln | grep 8899

If you get something back, it is in use.

[Edited]

smarty125 commented 7 years ago

Don't I feel sheepish....After checking the machine that hosts ha-bridge, I found that in my main automation software (PowerHome), I had set up a "udp listener" type plugin on port 8899. This was part of a prior attempt to "hear" and control the Limitless LED's. After disabling this plugin, ha-bridge controlled properly and reported no errors.

I don't have the depth of computer knowledge to fully understand your comment:
"The ha-bridge just re-uses the port you are trying to send to as it's datagram port. I'll need to update that and use the upnp response port as that would be a better selection. "

But hopefully that mean that after you make an update, I could still use PowerHome to monitor udp traffic on port 8899, and thus see/sense any upd traffic going to my LED's (so I can track their state via PowerHome and the udp plugin). Right?

bwssytems commented 7 years ago

Glad you found it. The statement that I wrote was I use the port that is in your call to the limitless bulbs as the hosting port for the packet. It does not need to be that port on the hosting end and the bridge already has one assigned for upnp and can be reused. This way, you know what ports the bridge is using and can run other processes on those ports without interference. So when I add this enhancement you can run that listener again.