Announcement

Collapse
No announcement yet.

Why can't events control a virtual device?

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

  • Why can't events control a virtual device?

    This is something I've always wonder about. I have control and status virtual devices which I use to control way things works. Many of these I don't want to have any way to allow them to be changed from the devices tab. Way back when I started I thought I could just set the whole device as status only and that would solve the problem by removing the control button. That's when I found out that once you do not even events can change the device, boy was I sad to find that out, and the only way around this was to write scripts. But then you can't rename any device without changing every script that addresses it. So it seems that once a device is set to status ONLY shell scripts can change them.

    Is there some reason why a device that is set to Status Only can't still be controlled using Events? I racked my brain and can't see any reason this would cause any issues or break anything.

    If there isn't a reason that it has to be this way can events be changed so they can change devices marked Status Only? Surely this can't be that hard to do.

    Now if changing Control Device breaks something can we add a checkbook to the command which would allow it to control Status Only Device if you checked the box or if that isn't possible add a Control Status Only Device command?

    Everything above also goes for a single butting being set to Status from Both. Basically Events should be able to change any device be it status or not.

    BTW, Even Easy Trigger can't seem to change Status Only Devices or I would have used that as a work around. I fairly sure that Easy Trigger could be made to do it.
    HomeSeer Version: HS3 Standard Edition 3.0.0.531 | Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
    Linux version: Linux auto 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
    IP Address: 10.0.2.16 | Number of Devices: 417 | Number of Events: 667 | Available Threads: 399 | HSTouch Enabled: True

    Enabled Plug-Ins: AirplaySpeak: 3.0.0.13 | BLBackup: 2.0.61.0 | EasyTrigger: 3.0.0.65 | LiftMaster MyQ: 1.3.7006.42100
    mcsMQTT: 4.0.2.2 | PHLocation2: 3.0.0.53 | Pushover 3P: 0.0.0.45 | Z-Wave: 3.0.1.262

    Z-Net version: 1.0.23 using a HomeSeer SmartStick+: 6.04 (ZDK 6.81.3)

  • #2
    YOu can, but you have to use a script:

    Code:
    &hs.SetDeviceValueByRef(2146,100,true)
    the first value is the Device Reference, the second is the value, and the third is if you want it to fire triggers (setting it to false means no event triggers that check for a status change will fire).

    Click image for larger version

Name:	2019-02-20_12-10-50.png
Views:	23
Size:	55.7 KB
ID:	1286607
    Thanks,
    Frank

    Comment


    • #3
      Originally posted by Timon View Post
      I have control and status virtual devices which I use to control way things works. Many of these I don't want to have any way to allow them to be changed from the devices tab.
      You can filter the device list so devices you don't want to control do not appear on the Device Management page. Is there a reason why they must be displayed there? (BTW, I don't think the intent of that page was to be a general UI, but just a way to access devices for building and maintaining your HA system.)

      Is there some reason why a device that is set to Status Only can't still be controlled using Events? I racked my brain and can't see any reason this would cause any issues or break anything.
      I assume that's what the distinction is meant to do. A device that is 'status only' is, by definition, not controllable. It was probably originally expected that the feature would be used by plug-in authors to protect a subset of devices from being changed outside the control of the plug-in.

      You could submit a feature request to have a way to hide control buttons on a device-by-device basis, but I wouldn't count on seeing the change implemented quickly.
      Mike____________________________________________________________ __________________
      HS3 Pro Edition 3.0.0.548

      HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF, Rain8Net+ | RFXCOM | QSE100D | Vantage Pro | Green-Eye | X10: XTB-232, -IIR | Edgeport/8 | Way2Call | Ecobee3

      Comment


      • #4
        Originally posted by Uncle Michael View Post
        You can filter the device list so devices you don't want to control do not appear on the Device Management page. Is there a reason why they must be displayed there? (BTW, I don't think the intent of that page was to be a general UI, but just a way to access devices for building and maintaining your HA system.)
        I actually don't want to hide the device just not allowed it to be controller.


        Originally posted by Uncle Michael View Post
        I assume that's what the distinction is meant to do. A device that is 'status only' is, by definition, not controllable. It was probably originally expected that the feature would be used by plug-in authors to protect a subset of devices from being changed outside the control of the plug-in.

        You could submit a feature request to have a way to hide control buttons on a device-by-device basis, but I wouldn't count on seeing the change implemented quickly.

        I'm sure it was for plugins and scripts to be able to control them but I think that the same reason you'd want them to control the devices is the same reason you'd want events to control them.

        Originally posted by sirmeili View Post
        YOu can, but you have to use a script:

        Code:
        &hs.SetDeviceValueByRef(2146,100,true)
        the first value is the Device Reference, the second is the value, and the third is if you want it to fire triggers (setting it to false means no event triggers that check for a status change will fire).

        Click image for larger version

Name:	2019-02-20_12-10-50.png
Views:	23
Size:	55.7 KB
ID:	1286607
        I learn more about HS3 every day. I've set devices that way but only in a full script and have never used it that way you showed. I'm going to get that a try.

        Although I'd love to be able to put the device name rather than the reference number using the reference number is more reliable since if you use the name and you change the name you'd break everyplace you use it. Now that could be fixed if HS3 could rename name them but that can get very hard to fix.

        HomeSeer Version: HS3 Standard Edition 3.0.0.531 | Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
        Linux version: Linux auto 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
        IP Address: 10.0.2.16 | Number of Devices: 417 | Number of Events: 667 | Available Threads: 399 | HSTouch Enabled: True

        Enabled Plug-Ins: AirplaySpeak: 3.0.0.13 | BLBackup: 2.0.61.0 | EasyTrigger: 3.0.0.65 | LiftMaster MyQ: 1.3.7006.42100
        mcsMQTT: 4.0.2.2 | PHLocation2: 3.0.0.53 | Pushover 3P: 0.0.0.45 | Z-Wave: 3.0.1.262

        Z-Net version: 1.0.23 using a HomeSeer SmartStick+: 6.04 (ZDK 6.81.3)

        Comment


        • #5
          Originally posted by Timon View Post

          ...
          Although I'd love to be able to put the device name rather than the reference number using the reference number is more reliable since if you use the name and you change the name you'd break everyplace you use it. Now that could be fixed if HS3 could rename name them but that can get very hard to fix.
          To be clear, when you use a device name in an Event, the device is stored by its RefID. Changing a name will not break events, only a change in the RefID will break the Events. With scripting, it is possible to reference a device by name and that script call will become broken if the device is renamed.

          Randy Prade
          Aurora, CO
          Prades.net

          PHLocation - Pushover - EasyTrigger - UltraECM3 - Ultra1Wire3 - Arduino

          Comment


          • #6
            Originally posted by rprade View Post
            To be clear, when you use a device name in an Event, the device is stored by its RefID. Changing a name will not break events, only a change in the RefID will break the Events. With scripting, it is possible to reference a device by name and that script call will become broken if the device is renamed.
            Sorry should have made that more clear. Device names don’t get updated when used as parameters in scripts that are referenced inside of events.

            HomeSeer Version: HS3 Standard Edition 3.0.0.531 | Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
            Linux version: Linux auto 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
            IP Address: 10.0.2.16 | Number of Devices: 417 | Number of Events: 667 | Available Threads: 399 | HSTouch Enabled: True

            Enabled Plug-Ins: AirplaySpeak: 3.0.0.13 | BLBackup: 2.0.61.0 | EasyTrigger: 3.0.0.65 | LiftMaster MyQ: 1.3.7006.42100
            mcsMQTT: 4.0.2.2 | PHLocation2: 3.0.0.53 | Pushover 3P: 0.0.0.45 | Z-Wave: 3.0.1.262

            Z-Net version: 1.0.23 using a HomeSeer SmartStick+: 6.04 (ZDK 6.81.3)

            Comment


            • #7
              Originally posted by Timon View Post
              I learn more about HS3 every day. I've set devices that way but only in a full script and have never used it that way you showed. I'm going to get that a try.

              Although I'd love to be able to put the device name rather than the reference number using the reference number is more reliable since if you use the name and you change the name you'd break everyplace you use it. Now that could be fixed if HS3 could rename name them but that can get very hard to fix.
              You can do this, but I would use the refID. Yo ucan do it via: HS.SetDeviceValueByName(Name,value) and the name has to include the location (doesn't say if you have to use both or just 1 or just 2). I think this would be a bit error prone and just using the refID should be the way you go.

              You can see the help file on it here: http://help.homeseer.com/help/HS3/st...icevaluebyname
              Thanks,
              Frank

              Comment


              • #8
                Yea, that’s my feeling as well. I always have the ref I’d visable on the device page for just that reason.
                HomeSeer Version: HS3 Standard Edition 3.0.0.531 | Mono JIT compiler version 5.20.1.19 (tarball Thu Apr 11 09:02:17 UTC 2019)
                Linux version: Linux auto 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
                IP Address: 10.0.2.16 | Number of Devices: 417 | Number of Events: 667 | Available Threads: 399 | HSTouch Enabled: True

                Enabled Plug-Ins: AirplaySpeak: 3.0.0.13 | BLBackup: 2.0.61.0 | EasyTrigger: 3.0.0.65 | LiftMaster MyQ: 1.3.7006.42100
                mcsMQTT: 4.0.2.2 | PHLocation2: 3.0.0.53 | Pushover 3P: 0.0.0.45 | Z-Wave: 3.0.1.262

                Z-Net version: 1.0.23 using a HomeSeer SmartStick+: 6.04 (ZDK 6.81.3)

                Comment

                Working...
                X