Test program blocks at UDP packet receiving

[PhilWheat]

The test program blocks at the line:
byte[] receivebytes = receivingUdpClient.Receive(ref RemoteIpEndPoint);

This is happening because the app is not receiving a response from any bulbs on the UDP packet. Items to test for troubleshooting:
Check IP Range - currently the package assumes 192.168.1.xxx IP range. Package needs to be modified to auto-detect the local IP and adapt the IP range accordingly.

Check Firewall - the first time the program is run, Windows firewall may require permission to be given. When it is given, the program needs to be re-run. Package needs to time out and re-send packets to overcome this (and some other lossy) scenario.

If the blocking line is inside the while (receivingUdpClient.Available > 0) loop, please open a separate issue item for additional requirements troubleshooting.

[codemonkey76]

I am using 10.x.x.x ip addresses on my network.

I changed the adress from 192.168.0.255 to 10.0.0.255 and it no longer freezes it actually sees one of my bulbs, but can't get any of the controls to do anything.

[PhilWheat]

OK - the latest push should work with whatever IP range you want, it reads the subnet information from your PC.

The commands should work with you either pressing enter in the fields or Clicking on "Bulb Command". "Color Cycle" will currently freeze the UI but slowly take the bulbs through a full cycle of red-green-blue-red.

For a sample set of values, try
Hue: 48000
Saturation: 65000
Brightness: 5000
Kelvin: 0
Fade Time: 0

Let me know if you don't see any updates on the bulb(s) it sees.

[codemonkey76]

Yes, that seems to be working, but it is only seeing 1 out of the 4 bulbs?

[PhilWheat]

I suspect your bulbs are behaving correctly and mine are not. I have pushed another change that will possibly identify duplicate bulbs, let me know if it lets you control more (or all) of your bulbs. Note this version will be more "chatty" on the network - it shouldn't affect things much, but if you're running a wireshark, you'll probably see more (up to double) the number of packets sent out.

[codemonkey76]

haha, man you're fast. I tried turning off the bulb it could see and then running the app again, this time it could see only 1 bulb still, but a different bulb... I will try the update now.

[codemonkey76]

Ok, just tried the update, it says 4 bulbs connected (even though only 3 are switched on at the wall). I press color cycle and only 2 bulbs out of the 3 that are on are affected.

[PhilWheat]

Excellent. That does help. Let me do a bit of work and I'll push another update. In the meantime, could you try the "Connect" a couple of times over say 5 minutes or so and see if it shows 6 bulbs at any time? It should be showing duplicate bulbs and should be reporting twice the number you actually have with this quickie patch.

[codemonkey76]

actually now it says 8 bulbs

[PhilWheat]

When it shows 8 bulbs, does it control more than the 2 before?

[codemonkey76]

it also occasionally says this:
"Only one usage of each socket address (protocol/network address/port) is normally permitted"
with a SocketException on this line:
UdpClient receivingUdpClient = new UdpClient(56700);

sometimes when i press connected button.

[codemonkey76]

what do the hue numbers represent, what is the range? same as saturation and brightness?

[codemonkey76]

i am assuming the Fade is in milliseconds?

[PhilWheat]

Fade is actually attempted to be in Seconds, though we're trying to figure out all the behaviors. Sometimes the bulbs respond in seconds to the current formula (such as reducing brightness) and sometimes it's some other algorithm (such as in moving from one hue to another.)

Current tested formula is Packet Fade value = ((seconds) * 225) ^ 2; I'm doing the conversion on the packet population from the value in the textbox.

Brightness, Hue, Saturation are all 0-65000 (UInt16) Kelvin is effectively just that in bulb temperature (so you'll want to be somewhere between 2000 and 5000 or so.)

[codemonkey76]

so what would i put in to get my whites