Announcement

Collapse

Contacting HomeSeer This Week

HomeSeer is open and operational this week. All orders are being processed and shipped as usual. However, some staff are working from home. If you need to contact HomeSeer for support or customer service, please use our Email or Chat options. https://homeseer.com/contact-us/
See more
See less

Magic Color Controllers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by fuzzysb View Post
    If I run it direct from VS as a remote plugin it works fine, as it's being executed against my Windows machine and loops through the nics on my Dev machine. But when I execute directly on my Linux box when it first polls the devices (takes quite a few mins before it first runs the poll, it reports this step is starting in the log) I now get that exception returned.

    Once I get the remote debugging set up I will step through and it should become apparent why it's failing and reporting the socket is blocking. It's potentially a Mono bug as I'm seeing this issue is complained about quite a bit when googling this issue,

    ​​
    Can you package up a sample and send me code to try? Like I said I do udp broadcast and receive on mono , so it def works.

    Comment


    • #32
      ok i still didn't get the mono debugger working on the remote process, however i think i have gotten to the bottom of the issue. the error i was receiving was originally when the device was polling

      Code:
       
      Jan-28 1:50:45 AM MagicHome ERROR Unable to discover any devices, the error was: Operation on non-blocking socket would block
      Jan-28 1:50:45 AM MagicHome DEBUG MagicHome Device Poll Inititated.
      but this exception only happens when discovering/polling (if no devices have previously been discovered, then the discovery will happen every time a poll occurs)

      reading about the issue Operation on non-blocking socket would block on Mono, it seems that this error is misleading, if i attempt to read the socket and the buffer is empty, it throws this error.

      so i check that _socket.Available > 0 now before i attempt to read. if not it successfully skips the read if there is no data available on a specific NIC and attempts 5 times to read on each nic.

      now i see the following when running. i've just completed some further optimisations on the code and will release the new beta very shortly.

      Code:
       
      Jan-28 9:12:57 AM MagicHome DEBUG Updating Device 840D8E41305A Preset Value Pairs
      Jan-28 9:12:53 AM MagicHome DEBUG Updating Device 840D8E41305A Warm White Value Pairs
      Jan-28 9:12:53 AM MagicHome DEBUG Existing Device Not Found Creating Device 840D8E41305A in HomeSeer
      Jan-28 9:12:49 AM MagicHome DEBUG Updating Device 840D8E41305A Blue Value Pairs
      Jan-28 9:12:45 AM MagicHome DEBUG Updating Device 840D8E41305A Green Value Pairs
      Jan-28 9:12:41 AM MagicHome DEBUG Updating Device 840D8E41305A Red Value Pairs
      Jan-28 9:12:38 AM MagicHome DEBUG Updating Device 840D8E41305A Colour Value Pairs
      Jan-28 9:12:34 AM MagicHome DEBUG Updating Device 840D8E41305A Value Pairs
      Jan-28 9:12:32 AM MagicHome DEBUG MagicHome Device Poll Inititated.
      Jan-28 9:12:30 AM MagicHome DEBUG Updating Device 840D8E41305A Root Device Value Pairs
      Jan-28 9:12:27 AM MagicHome DEBUG Device model AK001-ZJ200 with Mac Address 840D8E41305A and Firmware Version 5, proceeding to update Homeseer devices.
      Jan-28 9:12:26 AM MagicHome DEBUG Updating Device 6001948AAE65 Preset Value Pairs
      Jan-28 9:12:22 AM MagicHome DEBUG Updating Device 6001948AAE65 Blue Value Pairs
      Jan-28 9:12:18 AM MagicHome DEBUG Updating Device 6001948AAE65 Green Value Pairs
      Jan-28 9:12:14 AM MagicHome DEBUG Updating Device 6001948AAE65 Red Value Pairs
      Jan-28 9:12:11 AM MagicHome DEBUG Updating Device 6001948AAE65 Colour Value Pairs
      Jan-28 9:12:07 AM MagicHome DEBUG Updating Device 6001948AAE65 Value Pairs
      Jan-28 9:12:03 AM MagicHome DEBUG Updating Device 6001948AAE65 Root Device Value Pairs
      Jan-28 9:12:00 AM MagicHome DEBUG Device model AK001-ZJ200 with Mac Address 6001948AAE65 and Firmware Version 4, proceeding to update Homeseer devices.
      Jan-28 9:12:00 AM MagicHome DEBUG Updating Device 5CCF7F290DB1 Preset Value Pairs
      Jan-28 9:11:55 AM MagicHome DEBUG Updating Device 5CCF7F290DB1 Blue Value Pairs
      Jan-28 9:11:51 AM MagicHome DEBUG Updating Device 5CCF7F290DB1 Green Value Pairs
      Jan-28 9:11:47 AM MagicHome DEBUG Updating Device 5CCF7F290DB1 Red Value Pairs
      Jan-28 9:11:43 AM MagicHome DEBUG Updating Device 5CCF7F290DB1 Colour Value Pairs
      Jan-28 9:11:39 AM MagicHome DEBUG Updating Device 5CCF7F290DB1 Value Pairs
      Jan-28 9:11:36 AM MagicHome DEBUG Updating Device 5CCF7F290DB1 Root Device Value Pairs
      Jan-28 9:11:32 AM MagicHome DEBUG Device model AK001-ZJ100 with Mac Address 5CCF7F290DB1 and Firmware Version 3, proceeding to update Homeseer devices.
      Jan-28 9:11:32 AM MagicHome DEBUG Updating Device 60019487F8A2 Preset Value Pairs
      Jan-28 9:11:28 AM MagicHome DEBUG Updating Device 60019487F8A2 Blue Value Pairs
      Jan-28 9:11:25 AM MagicHome DEBUG Updating Device 60019487F8A2 Green Value Pairs
      Jan-28 9:11:22 AM MagicHome DEBUG Updating Device 60019487F8A2 Red Value Pairs
      Jan-28 9:11:19 AM MagicHome DEBUG Updating Device 60019487F8A2 Colour Value Pairs
      Jan-28 9:11:16 AM MagicHome DEBUG Updating Device 60019487F8A2 Value Pairs
      Jan-28 9:11:12 AM MagicHome DEBUG Updating Device 60019487F8A2 Root Device Value Pairs
      Jan-28 9:11:09 AM MagicHome DEBUG Device model AK001-ZJ200 with Mac Address 60019487F8A2 and Firmware Version 4, proceeding to update Homeseer devices.
      Jan-28 9:11:09 AM MagicHome DEBUG Updating Device 5CCF7F2A159E Preset Value Pairs
      Jan-28 9:11:04 AM MagicHome DEBUG Updating Device 5CCF7F2A159E Blue Value Pairs
      Jan-28 9:11:00 AM MagicHome DEBUG Updating Device 5CCF7F2A159E Green Value Pairs
      Jan-28 9:10:55 AM MagicHome DEBUG Updating Device 5CCF7F2A159E Red Value Pairs
      Jan-28 9:10:51 AM MagicHome DEBUG Updating Device 5CCF7F2A159E Colour Value Pairs
      Jan-28 9:10:46 AM MagicHome DEBUG Updating Device 5CCF7F2A159E Value Pairs
      Jan-28 9:10:42 AM MagicHome DEBUG Updating Device 5CCF7F2A159E Root Device Value Pairs
      Jan-28 9:10:37 AM MagicHome DEBUG Device model AK001-ZJ100 with Mac Address 5CCF7F2A159E and Firmware Version 3, proceeding to update Homeseer devices.
      Jan-28 9:10:32 AM MagicHome DEBUG MagicHome Device Poll Inititated.
      Jan-28 9:08:28 AM Starting Plug-In Plugin MagicHome started successfully in 862 milliseconds
      Jan-28 9:08:28 AM Warning Attempt by plugin to register a duplicate link of https://forums.homeseer.com/forum/lighting-primary-technology-plug-ins/lighting-primary-technology-discussion/magichome-fuzzysb. Plugin: MagicHome Instance:
      Jan-28 9:08:28 AM MagicHome INFO MagicHome version 1.0.0.168
      Jan-28 9:08:27 AM Starting Plug-In Initializing plugin MagicHome ...
      Jan-28 9:08:27 AM Info Plugin MagicHome has connected. IP:127.0.0.1:41472
      Jan-28 9:08:25 AM Plug-In Finished initializing plug-in MagicHome
      its worth noting that you need to wait for the first

      Code:
       
      MagicHome DEBUG MagicHome Device Poll Inititated.
      before any errors will be reported.

      Comment


      • #33
        No change here with the latest version, still no devices:

        Jan-27 18:58:12 DEBUG Writing the Log to File boolean value True to the MagicHome config file MagicHome.ini
        Jan-27 18:59:17 INFO MagicHome version 1.0.0.167
        Jan-27 19:01:22 DEBUG MagicHome Device Poll Inititated.
        Jan-27 19:01:22 DEBUG Unable to discover any Magic Home devices. please restart the plugin to try again
        Jan-28 10:13:38 INFO MagicHome version 1.0.0.188
        Jan-28 10:15:43 DEBUG MagicHome Device Poll Inititated.
        Jan-28 10:15:53 DEBUG Unable to discover any Magic Home devices. please restart the plugin to try again
        Jan-28 10:17:04 INFO MagicHome version 1.0.0.188

        Comment


        • #34
          ok so i am 100% running the discovery on all Nic's

          The code relating to this is


          if the socket operation produces and exception then it would be reported back. if there is no exception, either your nic is being filtered because of one of the properties. or quite simply there is no response received after 5 attempts.

          and that is the only way that the following debug line should ever be shown as the array is initialised but no results were added.

          Code:
          DEBUG Unable to discover any Magic Home devices. please restart the plugin to try again
          as it would not work originally for you based on the generic subnet broadcast address of 255.255.255.255, This code now looks up the broadcast address for your NIC based on ip address and subnet mask using the IPNetwork v2 Library, i was experiencing an issue with the socket send on Mono if i tried to read the socket when it was empty i got a blocking error (this is documented in places as a bug in Mono)

          I have just added a whole host more debugging lines around this step. please get latest beta version and give me the log

          i am catching all exceptions and reporting, and also state which NIC's the discovery will run against. if there is no error messages returned now, then it's simply that no devices have been returned during the query.






          Comment


          • #35
            Hi,

            So I ran PacketSender and confirmed that the device was not responding to the search, however when I ran the iPhone application is WAS responding. Ive been debugging and fired up wireshark on a mirror port, and it turns out the SENDING PORT also needs to be 48899 for these devices. When I send from that port, the device responds with:

            10.1.2.25,ACCF232F50A0,HF-A11-ZJ002
            (which is hex
            31 30 2E 31 2E 32 2E 32 35 2C 41 43 43 46 32 33 32 46 35 30 41 30 2C 48 46 2D 41 31 31 2D 5A 4A 30 30 32

            If I send from a random UDP port, the device does not respond. You mentioned you ran into some devices that didn't support discovery but had the port open, guessing those devices had similar firmware which required this port specifically...

            Best
            Bill

            Comment


            • #36
              ok, can i be 100% doubly sure that you don't have any software firewalls etc...blocking the random local port? and i'm not trying to teach you to suck eggs.

              obviously in this scenario this obviously isn't scalable as i will have to send the request (over UDP no less so cannot guarantee reception of transmitted response,or indeed reception of the reply) and wait for the required number of bytes to be received before closing the socket, if i attempt another request concurrently then i will get a socket in use error. obviously the default behaviour is something like below as it allows multiple synchronous requests to local ports.

              Local -> Remote
              36699 -> 48899
              36700 -> 48899
              36701 -> 48899
              36703 -> 48899
              36708 -> 48899
              36709 -> 48899
              36710 -> 48899

              look i've pushed v1.0.0.202 to Prod as i believe it's sufficiently tested for release. I will have to create a beta just for you to test this discovery. as it will cause problems and needs further error checking and timeouts to cater for for dropped packets so i don't wait indefinitely for a response.

              i'm time limited for the next two days and just specifying the local port definition on the socket as is would allow discovery of a single device or 2 maybe if you are lucky so isn't robust enough as is.

              but please can you confirm the same behaviour from another machine with Packet Sender, maybe even use Packet Sender on a wireless client such as your IOS Device or Android Device or a Windows/Mac Laptop on same wifi network just to sanity check the behaviour.

              Comment


              • #37
                bsobel i've just pushed v1.0.0.204 which sets the local port. Please test how this works for you.

                I'm not available to test myself the behaviour, as i am away from home and my test devices. however i suspect this will present problems as is, as i explained above. but at least you can confirm something is discovered initially. Look for debug errors like the device sent the wrong number of packets. if that is the case you have a response but they are jumbled together.

                or you will receive errors that the socket could not be opened.

                the issue is that i use the Socket.Bind() command to set the local port (It's the only way to set the local port on Socket Class). if there is a port already open i just don't know the behaviour.

                Comment


                • #38
                  Originally posted by fuzzysb View Post
                  ok, can i be 100% doubly sure that you don't have any software firewalls etc...blocking the random local port? and i'm not trying to teach you to suck eggs.

                  obviously in this scenario this obviously isn't scalable as i will have to send the request (over UDP no less so cannot guarantee reception of transmitted response,or indeed reception of the reply) and wait for the required number of bytes to be received before closing the socket, if i attempt another request concurrently then i will get a socket in use error. obviously the default behaviour is something like below as it allows multiple synchronous requests to local ports.

                  Local -> Remote
                  36699 -> 48899
                  36700 -> 48899
                  36701 -> 48899
                  36703 -> 48899
                  36708 -> 48899
                  36709 -> 48899
                  36710 -> 48899

                  look i've pushed v1.0.0.202 to Prod as i believe it's sufficiently tested for release. I will have to create a beta just for you to test this discovery. as it will cause problems and needs further error checking and timeouts to cater for for dropped packets so i don't wait indefinitely for a response.

                  i'm time limited for the next two days and just specifying the local port definition on the socket as is would allow discovery of a single device or 2 maybe if you are lucky so isn't robust enough as is.

                  but please can you confirm the same behaviour from another machine with Packet Sender, maybe even use Packet Sender on a wireless client such as your IOS Device or Android Device or a Windows/Mac Laptop on same wifi network just to sanity check the behaviour.
                  There are no firewalls, I have verified the behavior. As I mentioned I used wireshark I know exactly what packets are on the network. The device does not respond when the source port is doesn't match (which is stupid) This to me feels strongly like a firmware issue with certain models.

                  "obviously the default behaviour is something like below as it allows multiple synchronous requests to local ports. "

                  I didn't follow your concern here, you can send multiple packets and receive, just set exclusiveUse to false on the udpclient.

                  With this change you are discovering the device now, but no devices (that I can see) are being created. I just get a new dropdown that didn't exist before..

                  Fyi, I ran the python script against this change and it looks like you are blasting out the discovery packets, as an FYI the actual app does two things. Sends one to the broadcast port, and then walks the network and for any machine that it gets an ARP response from it sends the same message direct. E.g. even if the source port is 48899 in all cases, its only send one packet not dozens to perform discovery. I think your discovery can be greatly simplified.

                  Click image for larger version  Name:	Screen Shot 2019-01-29 at 7.38.01 PM.png Views:	1 Size:	70.2 KB ID:	1280502

                  Comment


                  • #39
                    Log as fyi:

                    Jan-29 19:29:12 INFO MagicHome version 1.0.0.205
                    Jan-29 19:31:16 DEBUG MagicHome Device Poll Inititated.
                    Jan-29 19:31:16 DEBUG Discovery is not running on NIC Adapter lo as it is the Loopback Interface
                    Jan-29 19:31:16 DEBUG Discovery will run on on NIC Adapter eth3
                    Jan-29 19:31:16 DEBUG Running Discovery on on NIC Adapter eth3 and will target broadcast address 10.1.3.255
                    Jan-29 19:31:21 DEBUG Discovery is not running on NIC Adapter wlan3 as IPv4 is not Enabled on the Interface
                    Jan-29 19:31:21 DEBUG Discovery will run on on NIC Adapter eth3.1000
                    Jan-29 19:31:21 DEBUG Running Discovery on on NIC Adapter eth3.1000 and will target broadcast address 10.1.103.255
                    Jan-29 19:31:26 DEBUG Discovery is not running on NIC Adapter eth3:1 as it is not an Ethernet or Wifi Adapter
                    Jan-29 19:33:16 DEBUG MagicHome Device Poll Inititated.
                    Jan-29 19:35:16 DEBUG MagicHome Device Poll Inititated.
                    Jan-29 19:37:16 DEBUG MagicHome Device Poll Inititated.
                    Jan-29 19:38:04 DEBUG Writing the deviceType for ACCF232F50A0 to the MagicHome config file MagicHome.ini
                    Jan-29 19:38:09 DEBUG Writing the deviceType for ACCF232F50A0 to the MagicHome config file MagicHome.ini
                    Jan-29 19:39:16 DEBUG MagicHome Device Poll Inititated.
                    Jan-29 19:41:16 DEBUG MagicHome Device Poll Inititated.

                    Comment


                    • #40
                      This new version is staying at about 80-100% cpu, so I had to stop it. Guessing your in a loop after exception caused by the port issue.

                      Comment


                      • #41
                        Ok so it's now discovered the device, an instance of the device class is generated with the Mac and IP found in the discovery response. At that point the status is requested which we need to create the devices.
                        i wonder if that now has the same issue where it doesn't respond unless the source port is 5577.

                        Try the following command
                        packetsender -xtw 500 <device ip> 5577 "81 8a 8b 96" Does it respond? Or do you need to also set the source port as 5577?

                        The older devices/firmware really are bad. The problem is that too try and fix an issue with someone else's device which sends the status response back in two packets I now issue a wait until the at least 9 bytes has been recieved to the response, as with his I would only ever process the first 8 bytes recieved in the first packet causing the status and devices never to update. It Needs a lot more thought about how to cater for both his scenario and yours.

                        ​​​​​​

                        Comment


                        • #42
                          I do get a response to that regardless of the port, but the response seems to be empty? Run from GUI because command line shows nothing, in gui you can see the empty response. I tried a random port and also 5577, same result.

                          Click image for larger version

Name:	Screen Shot 2019-01-30 at 8.40.03 AM.png
Views:	23
Size:	136.9 KB
ID:	1280627

                          Comment


                          • #43
                            ok thats not great at all, can you try

                            packetsender -xtw 500 10.1.2.25 5577 "ef 01 77"

                            Comment


                            • #44
                              Originally posted by fuzzysb View Post
                              ok thats not great at all, can you try

                              packetsender -xtw 500 10.1.2.25 5577 "ef 01 77"
                              Much better, response that time (and the port was not set the same)

                              TCP (54881)://10.1.2.25:5577 EF 01 77

                              Response Time:16:00:02.697
                              Response HEX:66 01 23 41 21 02 FE FE FE 01 99
                              Response ASCII:f\01#A!\02\fe\fe\fe\01\99

                              Comment


                              • #45
                                ok that drop down in the settings after discovery, can you change the selection to LegacyBulb then restart the plugin. does that kick it in to start working?

                                Comment

                                Working...
                                X