Open PhilWheat opened 10 years ago
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.
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.
Yes, that seems to be working, but it is only seeing 1 out of the 4 bulbs?
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.
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.
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.
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.
actually now it says 8 bulbs
When it shows 8 bulbs, does it control more than the 2 before?
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.
what do the hue numbers represent, what is the range? same as saturation and brightness?
i am assuming the Fade is in milliseconds?
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.)
so what would i put in to get my whites
Whites are done with a 0 saturation and a Kelvin value. IE 0, 0, 5000, 4500, 0. Higher Kelvin values are more blue, lower are more yellow. They're trying to match them to regular bulb color temperatures. You can see some values/colors at http://www.lightbulbsdirect.com/page/001/ctgy/colortemp
thanks, that's great.
OK - another push is up. The socket usage problem should be fixed (was an unclosed reader object - at some point I need to clean all that up.)
I am now using the first report of each bulb MAC address, so each should be registered on the first gateway they're reported from. Let me know what behavior you see - #'s of bulbs, which are controlled and the like, especially if you get more bulbs on a second or third connect than the first one. This will be the last push for the night, I'll look at any results first thing in the morning.
Great work Phil, I'll do some testing now and report back here
I have 4 bulbs on now, but only 1 being detected. I tried waiting for a little while and pressing the "connected" button again, then it says 2 bulbs, but commands are only controlling 1. then I press connected again and it says 3 bulbs, but commands still only controlling 1 :-(
OK, pushed up another version - this one will see duplicates of the bulbs, but you'll see the MAC and IP addresses of the bulbs as well as the labels. If you could run it and then copy-paste the bulb information here, that would help me understand how the bulbs are appearing on your network.
You should see something like: Bulb 2 : D0-73-D5-00-96-25-00 : D0-73-D5-01-7D-EB-00 : 192.168.1.21 Bulb 1 : D0-73-D5-00-96-25-00 : D0-73-D5-00-96-25-00 : 192.168.1.22 Bulb 1 : D0-73-D5-00-96-25-00 : D0-73-D5-00-96-25-00 : 192.168.1.22 Bulb 2 : D0-73-D5-00-96-25-00 : D0-73-D5-01-7D-EB-00 : 192.168.1.21
4 bulbs all on:
Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11 Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11
If it helps, on my phone in the lifx app, the loungeroom bulb appears but nothing else, then i close the app and open again and then all the bulbs appear.
I tried leaving the windows app open and waiting a while and pressing connected again, but no new bulbs appear.
If it's any easier and you want me to try anything, you can msg me on skype (codemonkey76) or facebook chat (facebook.com/codemonkey076) or something?
and sometimes one of the duplicates dissappears, so i just have this: Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11
Thanks - a bit of delay as I tracked the issue down. Pushed another build up that should handle both bulbs behind gateway and behind unique IP's. And feel free to send me connect messages on Skype and Facebook - PhilipWh on the first and Philip.Wheat on the second.
Let me know what you see with this build, I think I was able to replicate what you were seeing and get it working correctly.
i get number of bulbs 2, loungeroom bulb showing twice and controllable, if i turn that off, i get Dining showing up and controllable, if i turn that off i get one of the others. It's like it's only getting the gateway bulb. Does each bulb get it's own IP address?
Hmm - can you confirm that's with the current commit (19)? Also can you copy/paste the listbox again?
This change was to put detection in for both bulbs with their own IP (gateway bulbs) and bulbs behind gateway bulbs.
Is it correct to say you didn't see a change in behavior with the new build?
Updated textbox for me now is: Bulb 1 : D0-73-D5-00-96-25-00 : D0-73-D5-00-96-25-00 : 192.168.1.22 Bulb 2 : D0-73-D5-00-96-25-00 : D0-73-D5-01-7D-EB-00 : 192.168.1.22
yeah, still getting the same issue:
Rhiannon : D0-73-D5-00-24-19-00 : D0-73-D5-00-0F-79-00 : 10.0.0.15
that's my textbox, 1 bulb connected
OK - I just added an extra textbox to report on received packets. Could you let me know what you get there? And try the Connect 3-4 times with a 10 second or so pause in between.
[26/01/2014 12:53:53 pm] codemonkey76: ooh, i see 2 bulbs out of 4 after pressing connect the 3rd time [26/01/2014 12:54:18 pm] codemonkey76: on the 5th press it disappeared again though [26/01/2014 12:54:43 pm] codemonkey76: 3 Discovery Packets Received 1 Inventory Packets Received
Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11 [26/01/2014 12:55:13 pm] codemonkey76:
after 6th press i get this:
Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11 Mikayla : D0-73-D5-00-24-19-00 : D0-73-D5-00-2D-24-00 : 10.0.0.11
3 Discovery Packets Received 2 Inventory Packets Received [26/01/2014 12:55:44 pm] codemonkey76: then this...
4 Discovery Packets Received 2 Inventory Packets Received
Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11 Rhiannon : D0-73-D5-00-24-19-00 : D0-73-D5-00-0F-79-00 : 10.0.0.11 [26/01/2014 12:56:41 pm] codemonkey76: seem to be randomly visible then not visible, never more than 2 bulbs
OK - that helps. It looks like I'll need to remember bulbs when I see them at least once. When my bulbs each have an IP, the connection is very reliable, when they're meshed (only 1 bulb has an IP) it seems they're much less reliable.
I'll update to cache bulbs - in the long run, I'll be doing a regular poll to try to discover new bulbs.
Package is not yet auto-polling, but when a bulb is seen during Discovery/Inventory it will be remembered. It may take several packet requests to get all bulbs, but they should eventually show up. If this method works, I will being putting together the auto-poll process.
Please perform the previous tests with this build and let me know what you see.
i am not getting any bulbs detected anymore 0 Discovery Packets Received 0 Inventory Packets Received
OK, new push (had to do some other project work - sorry for the delay.)
The issue wasn't timing, it was that I had overlooked fully handling the incoming buffers. I'll still need to redo the packet architecture but you should get all the bulbs on at least the 2nd connect now. If you have a minuted, I'd love to hear the results of the new code on your network.
will do some testing now
on the first press i got: Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11
on the second i got: Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11 Dining : D0-73-D5-00-24-19-00 : D0-73-D5-00-24-19-00 : 10.0.0.11
and on the 3rd press i got: Lounge Room : D0-73-D5-00-24-19-00 : D0-73-D5-00-0E-E6-00 : 10.0.0.11 Dining : D0-73-D5-00-24-19-00 : D0-73-D5-00-24-19-00 : 10.0.0.11 Mikayla : D0-73-D5-00-24-19-00 : D0-73-D5-00-2D-24-00 : 10.0.0.11 Rhiannon : D0-73-D5-00-24-19-00 : D0-73-D5-00-0F-79-00 : 10.0.0.11
so that's all of them.
i tried color cycle and only the 3 bulbs (no loungeroom) would cycle, and killed the app and opened it again and this time first press got me 3 bulbs (no rhiannon), then 2nd press got me the 4th bulb, but again commands sent by typing values only go to 3 bulbs, no commands are working to lounge room
hope that helps.
Thanks - it does. I just added a new option for packet delay. I was using 50ms which was sufficient for my two bulbs, sounds like it's not quite enough for your four.
I put a default packet delay of 100ms, adjust up if you're still not getting all the bulbs to respond, down if you get annoyed with the command delays.
I also added a step value for the color cycle, since the packet delays also affect the cycle loop, I thought it might be helpful to be able to play with how fast the colors change. I went ahead and adjusted the cycle loop delay to take into account the number of bulbs and the packet delay. I basically subtract the packet delay time for the bulbs from the color cycle time, so there's not extra delays as the number of packets going out get larger.
OK, one more push before the workday gets started. Instead of a text area, there's now a Listbox with the detected bulbs at the bottom. Commands go to the selected bulbs - all start selected, but you can select and de-select as you please. Let me know if you find any issues, I dropped the change in pretty quickly.
maybe put the color cycle on a background worker thread so the app doesn't freeze? and have a second press of the button stop the thread?
In progress - multithreading is part of the packet refactoring going on right now.
OK, partial multi-threading up. Cycle now works off of whatever hue value each bulb has at the moment and simply increments by step and wraps around. Cycle button starts and stops the process, hue values are now shown by the Cycle button. Removed the Connect button - the app starts inventory when it is run and polls the gateway bulbs every minute to see if there are more bulbs to be found. Bulbs now report the last time they have received a network update.
Maybe i can TeamViewer into my home computer and run it and watch out of the webcam to see if it's changing colours :-P
No rush - I'm just trying to stay in the habit of posting updates and not letting commits get too large.
non-gateway bulbs no-longer showing an ip address, is that to reflect that they are non-gateway bulbs?
the MAC addresses in the listbox? there is 2 mac's per bulb, is one the gateway and the other the actual bulb address?, how come the gateway has 2?
That's correct - they actually don't have an IP, so I'm not recording their gateway IP, their gateway is actually the gateway MAC address on their status line (the first MAC shown.)
awesome, connected to home comp, ran the app and only 3 bulbs showed up, wife says dining was off at the switch, she turned it on and it appeared in the listbox shortly after.
The Gateway bulb has a different MAC address on each interface, the Wifi and the Zigbee. And yes, that means we're doing a bit of duplication by having the IP address and the MAC address for the gateway bulb.
Excellent!
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.