Announcement

Collapse
No announcement yet.

RFXCOM breaks other plugins

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

    RFXCOM breaks other plugins

    Bert, I've been trying for a week or more to troubleshoot one of my plugins and it looks like it fails only after the installation of the RFXCOM plugin.

    When debugging my plugin remotely (VS running on a different machine than HS3) it works fine. If I install and enable RFXCOM, it then fails whenever it tries to execute a hs.GetDeviceEnumerator - it's like the plugin somehow corrupts the device database. Disabling RFXCOM makes no difference, nor does removing it completely.
    Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

    #2
    I have a few of my own plug-ins where I'm using hs.GetDeviceEnumerator and I also have RFXCOM installed. Never seen any problems, but all plug-ins on my system run on the main HS3 machine.

    I did find that GetDeviceEnumerator is painfully slow even with less than 200 devices, so now I have limited it's use in my plug-ins.

    Paul..

    Comment


      #3
      Yup - it only fails when it's on a different box. I have some 300 devices, but even if I delete the config database (so there a no devices) it fails, so it's no a timeout issue I don't think. And I can re-create the issue with the RFXCOM plugin every time. It's just bizarre. I only call it once so I can iterate through the devices and find my own. Is there a better way?
      Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

      Comment


        #4
        Originally posted by sooty View Post
        I did find that GetDeviceEnumerator is painfully slow even with less than 200 devices, so now I have limited it's use in my plug-ins.
        Paul..
        You are probably passing it the hs reference all the time, which causes it to go back through the interface to HS3 each time a property is accessed with the hs reference. If you get the enumerator, then you have a recent copy of all of the devices, so as you are going through the devices and are getting things such as the name of the device, do this:
        sName = dv.Name(Nothing)
        instead of this
        sName = dv.Name(hs)

        You only need to provide hs when you suspect the information may be old, or when you want to make a change.
        Regards,

        Rick Tinker (a.k.a. "Tink")

        Comment


          #5
          Originally posted by beerygaz View Post
          Bert, I've been trying for a week or more to troubleshoot one of my plugins and it looks like it fails only after the installation of the RFXCOM plugin.

          When debugging my plugin remotely (VS running on a different machine than HS3) it works fine. If I install and enable RFXCOM, it then fails whenever it tries to execute a hs.GetDeviceEnumerator - it's like the plugin somehow corrupts the device database. Disabling RFXCOM makes no difference, nor does removing it completely.
          Make sure that the HomeSeer DLLs in the root HS folder and in the \Bin folder are current on both systems. Perhaps when the version of HomeSeer changed those DLLs were not updated on your remote system or visa versa. If the object model on either system is out of sync with the other, I am guessing it could cause this, but I am not sure. If you create a plug-in looking for version 1 and you have version 2, that will fail, but if a plug-in on system A is looking for version 1 and has version 1, but HomeSeer on system B has version 2, I am thinking that could be like crossing the beams.
          Regards,

          Rick Tinker (a.k.a. "Tink")

          Comment


            #6
            RFXCOM breaks other plugins

            Rick that was my first thought too so I manually copied the DLLs of .55 to my /bin folder to be sure.

            Dirk (of Sonos fame) can duplicate the issue too with the device created by RFXCOM.

            Strange that it's only remote plugins (which is what made me think of a DLL issue first).
            Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

            Comment


              #7
              Did you also copy the RFXcom plugin to the remote machine? The RFXcom plugin may be serializing its own classes into a device, so when you get all the devices they are deserialized on the remote PC. If the remote PC cannot access the DLL or EXE that describes these classes you might get an exception.
              website | buy now | support | youtube

              Comment


                #8
                Yup - that sorted it. Thanks for the advice guys.

                If I copy HSPI_RFXCOM.EXE to my remote machine then I no longer get the exception.

                That - that solves my short-term problem of remote-debugging, but I'm guessing this isn't a viable solution for anyone writing remote plugins? Having their users copy every plugin executable to their local machine just to get the plugin to work?
                Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

                Comment


                  #9
                  Originally posted by beerygaz View Post
                  Yup - that sorted it. Thanks for the advice guys.

                  If I copy HSPI_RFXCOM.EXE to my remote machine then I no longer get the exception.

                  That - that solves my short-term problem of remote-debugging, but I'm guessing this isn't a viable solution for anyone writing remote plugins? Having their users copy every plugin executable to their local machine just to get the plugin to work?
                  Definitely not an acceptable solution.

                  tenholde
                  tenholde

                  Comment


                    #10
                    In your remote plugin which devices are you looking for? Only your own?

                    We will need to come up with another way to get devices. There is no workaround for this issue as is. The deserialization just will not work unless the class its deserializing is known. Plugins serialize their own classes into the ExtraData object in the device class and that automatically gets deserialized over the remote plugin connection. If you only need devices that are owned by your plugin, we should be able to offer a new call that can give you those.
                    website | buy now | support | youtube

                    Comment


                      #11
                      Originally posted by rjh View Post
                      Did you also copy the RFXcom plugin to the remote machine? The RFXcom plugin may be serializing its own classes into a device, so when you get all the devices they are deserialized on the remote PC. If the remote PC cannot access the DLL or EXE that describes these classes you might get an exception.
                      That seems to be quite a problem in general. I assume the same problem would happen when everything is running on a local machine: let's say RFXCOM was running before, stored extra data, but the PI is now disabled so ALL other PIs would fail when retrieving the GetDeviceEnumerator?

                      I do this at start-up to build up all the relevant internal data-structures while checking for consistency. In fact the recommendation has been to store PIs data in the HS devices and not in an .ini file, how would you ever be able to start-up again in this case, because the only way to find your own devices is to weed through all of them and if there is a device in there that doesn't have the corresponding PI running, you are out of luck?

                      So if this cannot be changed, than we need a new HS function ala GetDeviceEnumerator which has the Interface AND InterfaceInstance as input parameters.

                      Dirk

                      Comment


                        #12
                        Note that the RFXcom plugin does NOT need to be running. Its simply a class reference (EXE's contain class info just like a DLL). When the HSCF code transfers data between HS and a plugin, it serializes the data to the TCP stream, then deserializes on the other end. This is fine on the local machine since all class information is known to both the source (HS) and the client (the plugin). If the class info is not available on the remote system, the deserialization fails. The ExtraData property is only of interest to the actual plugin that owns that data, so there is no reason to send it to any other plugin. I might already know who is requesting the enumerator, if I do, I can simply clear out the ExtraData property and problem solved.
                        website | buy now | support | youtube

                        Comment


                          #13
                          Originally posted by rjh View Post
                          Note that the RFXcom plugin does NOT need to be running. Its simply a class reference (EXE's contain class info just like a DLL). When the HSCF code transfers data between HS and a plugin, it serializes the data to the TCP stream, then deserializes on the other end. This is fine on the local machine since all class information is known to both the source (HS) and the client (the plugin). If the class info is not available on the remote system, the deserialization fails. The ExtraData property is only of interest to the actual plugin that owns that data, so there is no reason to send it to any other plugin. I might already know who is requesting the enumerator, if I do, I can simply clear out the ExtraData property and problem solved.
                          Well we're never too old to learn something new.

                          Would be great if you could clear out the ExtraData, else I predict the occasional melt down, where a user starts removing PIs because something doesn't work and things go from bad to worse.

                          Is this the reason why I cannot "display" the "Object Data" field in the HS (devices table) SQL DB?

                          Dirk

                          Comment


                            #14
                            Correct, the object data in the DB is just a bunch of bytes which is serialized classes.

                            Originally posted by dcorsus View Post
                            Well we're never too old to learn something new.

                            Would be great if you could clear out the ExtraData, else I predict the occasional melt down, where a user starts removing PIs because something doesn't work and things go from bad to worse.

                            Is this the reason why I cannot "display" the "Object Data" field in the HS (devices table) SQL DB?

                            Dirk
                            website | buy now | support | youtube

                            Comment


                              #15
                              Originally posted by rjh View Post
                              In your remote plugin which devices are you looking for? Only your own?
                              In this instance I'm only looking for my own devices, so a GetDevEn function that took interface and (for others I guess: instance) as parameters would work to return only that plugin's devices.

                              However, as Dirk mentions, running a plugin, then removing it while leaving its devices behind would leave a ticking time-bomb.

                              I can think of a number of instance where I would want to know if other plugin devices were present too. I was about to enhance my Twitter plugin to see if UltraNetCam3 is installed and then list the camera devices as sources for an image to tweet.

                              So you're saying you'd need to determine the calling plugin, send it all of the data for devices it owns and clear the PED data for ones it does not?
                              Author of Highpeak Plugins | SMS-Gateway Plugin | Blue Iris Plugin | Paradox (Beta) Plugin | Modbus Plugin | Yamaha Plugin

                              Comment

                              Working...
                              X