No announcement yet.

is HS4 complete?

  • Filter
  • Time
  • Show
Clear All
new posts

    is HS4 complete?

    We haven't had an update since September (a little over three months ago) so does this mean that HS4 is finished? Not saying in a bad way just curious if HS4 is complete? Also is the 4.0.3 Z-Wave release complete/done also? I know I should ask that on another forum but its part of the HS4 as a whole.

    I would say no to both. HS4 (like HS3 before it) is in constant development. There are some new features to be added, most recently the next addition might be Conditional Actions as discussed in another thread.

    The Z-Wave plug-in will also be under continual development. is close to complete, but a true V4 (the current one is on a V3 core) will be released in the future.

    To answer your question, the HS core and plug-ins are going to evolve and update. It is unlikely they will be “complete” until they are at end of life and replaced by a new version.
    HS4 Pro, Windows 10 pro


      Nothing in Homeseer is ever "complete" until the next major version is released.

      The only products "complete", meaning they will receive no further updates or fixes, is HS3, the HS3.x Z-wave plugin, or any of their predecessors (versions 2.x and 1.x).


        Those are both good answers. When I think of the term "complete," in terms of an accomplishment, say, like a journey, I have completed my journey when I arrive at my predetermined destination. Otherwise, I think we would begin to discuss Buckaroo Bonzai's trip, "No matter where you go, there you are..."
        HomeSeer Version: HS4 Pro Edition
        Operating System: Microsoft Windows 10 Pro - Desktop Z-Wave via Z-Net
        Zigbee via RaspBee on RPi 3b+
        WiFi via Internal APs.

        Enabled Plug-Ins
        AK Weather,AmbientWeather,Big6,BLBackup,BLGData,BLLock,BLUPS,Device History,EasyTrigger,Harmony Hub,HSBuddy 3.30.1003.1,JowiHue,LG ThinQ,rnbWeather,SDJ-Health,TPLinkSmartHome4 2022.11.23.0,UltraCID3 3.0.6681.34300,UltraSighthoundVideo3 3.0.5960.36744,Z-Wave Hub Z-Net, Zigbee Hub: ZigBee on RPi 3+, WiFi on Internal AP.


          Originally posted by ewkearns View Post
          Those are both good answers. When I think of the term "complete," in terms of an accomplishment, say, like a journey, I have completed my journey when I arrive at my predetermined destination. Otherwise, I think we would begin to discuss Buckaroo Bonzai's trip, "No matter where you go, there you are..."
          HST had a list of things that will be in HS4. So while I agree that HS4 won't be complete until HS5 is out, I expect at the minimum that HS4 will eventually have all the items in that list of future HS4 features. The list disappeared (or maybe I can't find it anymore) but the conditional actions is something I am really looking forward to. And even more so the new HS Touch Designer (not the HS4Touch Designer but the complete rewrite of the designer).

          Also see


            Software product development has changed over the decades since my technology career first began. Back in the day (insert old guy voice here), products were defined using the waterfall methodology, meaning that, the product management team said, "We want a piece of software that will do X, Y, and Z... and that's it." So the dev teams would work, work, work, taking months and sometimes years to complete the product. Nothing shipped until the product was complete, hence the waterfall (development effort happens along the steady long stream at the top, then when product is complete, it drops down sharply to the bottom to be shipped.) Version 1.X would be released and then the product team would start working on the next major version to be released based on user feedback of the 1.X version. Hence the multi-month/year would start over again. The only thing that would be released between then and the next major version would be patches for significant bug fixes.

            What the business folks finally determined was that in between product conception and design, and by the time the product was ready to be shipped (sometimes years later), the marketplace had changed. People's needs changed. Technology changed. So the Agile methodology was conceived, whereas, you have an idea for a product, but rather than the idea being fully complete before you shipped, you got something out to the consumer sooner. So while the original specification might say "product must do X, Y, and Z", the decision would be made to fully develop feature set X first and then ship the 1.X version. Then the dev teams would work on feature set Y and ship a minor update version 1.1, maybe weeks or months later, but not years. Along the way, customer feedback might indicate that no one wants feature set Z anymore, so the team drops that goal and adopts a new goal of shipping feature set A, several weeks later. By constantly paying attention to what the marketplace is dictating, the product evolves over time and stays relevant.

            What happens though is that all these constant add-ons of unanticipated features start to reveal inadequacies in the original base product to support these additional features. Hence the team starts to work on a major re-write/coding of the product, which will become the 2.X (next major release). The tricky part for some smaller companies is having adequate resources to not only maintain/improve the 1.X version, but also work on the next major release. Most end up biting the bullet and stop all 1.X improvements to shift resources, but the problem is that bugs still get discovered and should be addressed. Larger companies with adequate resources don't have this problem because they will create a separate team just to maintain the earlier version while the larger team works on the next major version.

            The problem I can see from the outside looking in is that HST product development undisciplined. Agile methodology states that you ship new versions on a strict schedule, no matter what. What that schedule is is up to the product team, but most places I've worked at they stick to 3 to 4 week schedules called sprints. Whatever fixes or improvements can be made within those 3 weeks is what gets shipped, even if additional stuff was scheduled. Whatever didn't get done goes into the next sprint/shipping schedule. The team is judged on velocity, in other words, how well they keep fixing and improving the product while shipping on a strict schedule. This methodology works very well IMO because it doesn't matter whether you have two developers or a thousand... you're constantly shipping new versions based on the capacity you have. The product is never getting stale or standing still.