Announcement

Collapse
No announcement yet.

Turns light off.... but not on... huh?

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

    Turns light off.... but not on... huh?

    Hello SimpleRF fans:

    I have a bizarre issue... I have an X-10 remote that feeds SimpleRF via a WGL W800 receiver. I have the 3 HomeSeer devices "Device Mapped" via SimpleRF. I have several other X-10 remotes that all behave just fine...

    The 3 buttons I use on the remote control 2 lights and a ceiling fan. One light and the ceiling fan work great. The other light does not. It won't turn the light on.

    Now here's the weird thing. If I turn the light on using the Insteon wall switch, I can turn the light off using the X-10 remote! I just can't turn it on... HomeSeer doesn't change (still shows it as off).

    I looked at the SimpleRF log and I don't see any difference between the light that works and the light that does not. I know SimpleRF must be using the right device reference for example 'cause it can turn the light off no problem....
    It used to work....

    I've restarted and rebooted everything...
    I've removed the Device Mapping from SimpleRF and put it back...
    I've tried saying pretty please as I push the button...

    any ideas? thanx!
    Jim

    #2
    Could you enable debug mode in SimpleRF and see if the plugin is receiving the commands properly? If so, could you send me some of the output of the log and your SimpleRF configuration file (SimpleRF.ini in c:\Program Files (x86)\HomeSeer HS3\Config) so I could take a look at it? It might be a problem with the receiver, the remote, or a bug in the plugin.

    Comment


      #3
      I've attached my simplerf.ini file as simplerf.ini.txt.
      I also attached part of my simplerf.log log file as simplerf.log.txt that shows me turning the light off then on. Turning it off worked fine. Turing it on did not.
      thanx!
      Attached Files

      Comment


        #4
        Could you check the version of the plugin? Also, were these devices mappings created in an older version of the plugin? There were multiple bugs fixed in the last couple of revisions relating to device mappings. Im hoping this isnt another bug with it. Could you verify that the plugin is the latest version and then try deleting/readding the mapping for O-1?

        Comment


          #5
          The plug-in version is 1.3.2.0.
          I already tried removing the mapping and putting it back... "O1" is now at the bottom of the "Active Device Mappings" list on the Device Mapping tab.
          Thanx for the quick responses...

          Comment


            #6
            I'm migrating away from X10 because of similar issues. I even posted on the X10 forum that a dimmer switch, a TM751 and a palmpad, nothing else in the mix and I can turn it on but not off.

            It keeps getting attributed to line noise. Is there something you recently changed such as adding a piece of electronics, changing to a different bulb somewhere?

            Comment


              #7
              Thanx Racer....
              I'm not using X-10 to control the light - that's all Insteon... I control nothing with X-10. So not a line noise problem. I use X-10 remotes to send commands into HomeSeer the SimpleRF plug-in. Then X-10 is done. From then on it's all Insteon - which works great.

              Comment


                #8
                It does sound like it might be a bug in the plugin. I'm out of town until early next week, but I'll definitely try to pinpoint the issue that is causing this when i get back. If I cant reproduce the problem on my end, would you be willing to run a beta build that contains more debugging data? I'm sure it is frustrating, but if you are willing we should be able to get it resolved.

                Comment


                  #9
                  It's not frustrating... no worries...
                  I've developed software for years and I know how it goes...
                  I've written a half dozen plug-ins for myself and sometimes one can act in a "it's not possible to act like that" kind o' way....

                  I'll help any way you need... run a beta plugin, run one with extended debug, give you remote access to my system, heck I can step through code in a debugger if you'd like...

                  One more bit of info. I installed the RFXCOM plug-in (to add an oregon scientific temperature sensor) around the time this started happening. I can't pinpoint it exactly but within a couple week window. I tried disabling that plugin but still no joy for simplerf.

                  Hope your out of town is for fun...

                  Comment


                    #10
                    I just got home and had a chance to looked at it some more. Looking at the code and your logs, it looks like it is finding multiple CAPI.CAPIControls with the same name ("On") for this device. It loops through each of the controls until it finds one to act upon. In debug mode it prints out the value during each iteration. From your Off command:

                    Code:
                    2/20/2017 5:08:50 PM ~ X-10 Debug: SetDeviceValue, devRef: 114, command: OFF
                    2/20/2017 5:08:50 PM ~ X-10 Debug: CAPI.CAPIControl count: 102
                    2/20/2017 5:08:50 PM ~ X-10 Debug: CAPI.CAPIControl On
                    2/20/2017 5:08:50 PM ~ X-10 Debug: CAPI.CAPIControl On
                    2/20/2017 5:08:50 PM ~ X-10 Debug: CAPI.CAPIControl Off
                    2/20/2017 5:08:50 PM ~ X-10 Debug: control.Label: Off
                    It saw two "CAPI.CAPIControl On" controls before it saw the CAPI.CAPIControl Off it was looking for. Could you add a picture of that device's page under the "Status Graphics" tab?

                    Edited: It looks like HS only returns the CAPI.CAPIControls that are for controlling devices and doesn't return status devices, so it doesn't seem to be a bug after all. I previously thought that me not checking if it was a control status introduced a bug if someone used the same name for a status-only status as well as a control status.

                    I see you have 102 different status levels for that device. Is there a reason to process more than one control status from the same device? This bug wouldn't have been found had I not stopped processing further controls once I found a match.
                    Last edited by edgar1898; February 26, 2017, 09:45 PM.

                    Comment


                      #11
                      We're narrowing in on this one....

                      I do have 2 status values that have the name "On" (see screen grab) but only one that is declared as being the "On" control (the other is set to "not specified").

                      I haven't done an experiment where I remove the "not specified" status value to see if it works (since I'm at work right now)...

                      I see in your edit you say "...HS only returns the CAPI.CAPIControls that are for controlling devices and doesn't return status devices,..." but since there are 2 in the log that are named "On" and I have the CAPIControl for one of them set to "not specified", maybe HS returns "not specified's" too?

                      From your note you say you check the name of the status value (and found 2 "On"'s) Do you also check the control setting to make sure that one actually controls "On" (even if it's named "On")?

                      I had to add this odd "On" a while back due to an issue with another plug-in that for some reason couldn't send an "On" or even "dim to 100%" - hence I have a status called "On" if the value of the device is 99%. SimpleRF was working with this configuration but maybe for some reason HS is now returning the 2 status's in a different order. So when all this was working, it was because HS was returning to you the status for "On" that controlled "on" before it returned the status for "On" whose control was "not specified"... and now it's returning them the other way 'round? hmmm....

                      I'll run the experiment (remove the odd "On" status) tonight when I get home.
                      Attached Files

                      Comment


                        #12
                        Well I did the experiment and now it's behaving....
                        I don't know if you can (or want to) "fix" this but if you can "ignore" that first "on", it would help... If not, I'll figure out something else to do for my other logic...
                        thanx!

                        Comment


                          #13
                          I can easily ignore Not_Specified controls. While I'm making this change, is there any value in processing multiple controls instead of stopping after the first match is found?

                          Comment


                            #14
                            The only other "control use" that may make sense would be "on alternate" but I don't know what that is, so up to you...

                            Now processing multiple "On" control uses? Well I don't know what you'd do... turn it on twice? I can't think of a good reason to keep going after the first matching control use is found... so I'd keep it simple...

                            thanx!

                            Comment


                              #15
                              I submitted the update to HS yesterday, so it should be on the updater early next week. It will ignore any controls that are set to Not_specified. Could you verify when it gets to the updater?

                              Comment

                              Working...
                              X