Announcement

Collapse
No announcement yet.

HS3 Configuration too reliant on untracked references/pointers?

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

  • HS3 Configuration too reliant on untracked references/pointers?

    Is it just me, or are others frustrated on HS3 configuration's reliance on un-tracked pointers and references becoming a pain to manage as the system becomes more complex? When a device is deleted, why can't HS3 search for references to the "to-be" deleted device and walk you through replacing or deleting them? I've resorted to an out-of-band system of management to keep my events working. The software already knows the event is broken, so why just leave it in that state?

    Typical scenario, but certainly not the only valid case -

    I replace batteries in a Z-wave multisensor, and rescan to ensure everything is working. Whoopsie; now there is a duplicate sub-device for temperature and the previous device stops updating and is orphaned. No problem, I've seen this movie (bug) before, simply delete the now-orphaned device. Whoopsie; now several events are broken that reference the device... OK, go through and re-point to the exact same named (but different internally referenced device). Several days later. Oh, whoopsie; some things still aren't working because of liberal use of device reference replacement variables, harder to find because they only have DTR:Number: and have to track that down. Fixed. OK, finally back to normal. Wait, another battery low...

    I know, first world problems right? It's a minor thing, but easily fixable by simply searching events/plugins for references to the device you are about to delete.

    Thankfully, jon00 has provided great third party tools for reporting on devices and events to help sort this all out after the fact. I highly encourage everyone to make monthly reports of your devices and events.

    And maybe rjh can add this feature to HS4! Which I'll happily purchase/upgrade when it comes out!

    Done with my end of year rant. Happy new year!


  • #2
    I am a little confused at what you are referring too? Is it the problem where you create an event to control a device but then that device is deleted and replaced and your event is now broken? That is a tough issue. I can tell you that for Z-Wave, you can add a new Z-Wave device, then go to the bad device, Z-Wave tab and change the Node ID to the new device you just added. (then delete the new device) The events that use the device will work fine. Note this only works if you replace a device with the exact same device. If its a different device, there is not way to handle a replacement and have the event still operate properly.

    Originally posted by mterry63 View Post
    Is it just me, or are others frustrated on HS3 configuration's reliance on un-tracked pointers and references becoming a pain to manage as the system becomes more complex? When a device is deleted, why can't HS3 search for references to the "to-be" deleted device and walk you through replacing or deleting them? I've resorted to an out-of-band system of management to keep my events working. The software already knows the event is broken, so why just leave it in that state?

    Typical scenario, but certainly not the only valid case -

    I replace batteries in a Z-wave multisensor, and rescan to ensure everything is working. Whoopsie; now there is a duplicate sub-device for temperature and the previous device stops updating and is orphaned. No problem, I've seen this movie (bug) before, simply delete the now-orphaned device. Whoopsie; now several events are broken that reference the device... OK, go through and re-point to the exact same named (but different internally referenced device). Several days later. Oh, whoopsie; some things still aren't working because of liberal use of device reference replacement variables, harder to find because they only have DTR:Number: and have to track that down. Fixed. OK, finally back to normal. Wait, another battery low...

    I know, first world problems right? It's a minor thing, but easily fixable by simply searching events/plugins for references to the device you are about to delete.

    Thankfully, jon00 has provided great third party tools for reporting on devices and events to help sort this all out after the fact. I highly encourage everyone to make monthly reports of your devices and events.

    And maybe rjh can add this feature to HS4! Which I'll happily purchase/upgrade when it comes out!

    Done with my end of year rant. Happy new year!
    website | buy now | support | youtube

    Comment


    • #3
      Originally posted by rjh View Post
      Is it the problem where you create an event to control a device but then that device is deleted and replaced and your event is now broken? That is a tough issue.
      Thanks for responding Rich. Yes, basically I'm talking about deleting a device that exists in one or more events, either directly referenced in the event (where it shows up by name) or if it's referenced by replacement variable (as in an email or speech output).

      I get that it's tough, especially in a retrofit fashion. You'd likely have to add an API for plugin writers and ask that they add support for such a deletion process.

      I wouldn't think it would be hard to at least provide a report of the events that will be impacted by the deletion? An icon on the Home page that indicates you now have 1 or more broken events that should be investigated? That would be simple in comparison to creating a wizard to replace a device in events. I understand that logic for this would require some type of library of device functions to allow "like for like" replacement. Not impossible, might be worth consideration.

      As for the Z-wave device replacement, I'm familiar with that. In the case above, the device created is a child device of the Z-wave node, so I don't think it would apply to my discussion. The same Z-wave node is still in service, HS3 just abandoned the child device and created a new one with a new reference and the same name. I'm not sure why, but it's not an unheard of event.

      Comment


      • #4
        Originally posted by mterry63 View Post
        HS3 just abandoned the child device and created a new one with a new reference and the same name. I'm not sure why, but it's not an unheard of event.
        Yep, I've seen this too, with the Aeon Labs Multilevel Sensor.

        Comment


        • #5
          Originally posted by baudi View Post

          Yep, I've seen this too, with the Aeon Labs Multilevel Sensor.
          I've seen it on various sensors and lights.

          What I did, was to create a virtual device for each of the physical sensors, have the physical device update the virtual device, and trigger events of the virtual. That way, there's only the one place that I need to update for a sensor when there's an issue.

          For lights, I have all my events call other events, and these events are the only thing that touches the physical device. That way, if a light gets updated like that, then there's only the one place to update, so all the other master events carry on working.


          G

          Comment


          • #6
            Seen it a number of times on rescans too. Mainly FortrezZ water sensors, but other devices too.
            HS 3.0.0.548: 1976 Devices 1156 Events
            Z-Wave 3.0.1.262: 123 Nodes on one Z-Net

            Comment


            • #7
              I had another case surface this weekend where an event had a replacement variable for a deleted device. Frustrating!


              Sent from my Pixel 2 using Tapatalk

              Comment

              Working...
              X