Complaints

[Ltek]

Are these posts in the forum or a Service Desk ticket? If on the forum, Mark said it above and it has been stated many times this forum is not regularly monitored by HST.
How would we know if a Service Desk ticket had been submitted and if so that it was ignored?

I've done both but that is simply lazy on HST's part...
Experts also use focus groups and collect feature request data... and the forum here can be considered a focus group ;-)

If they want to show they care then THEY should curate FR tickets, en mass - right now, and then make them visible and votable in Jura... I've said this EVERYTIME this comes up. HST doesnt want to really do this... HST actions (and lack of some) tell you the truth.

rmasonjr voting polls tell you what HST wants to do, not what is most important to the user base. Experts who design products do not use polls the way they are done here.... they can never capture the user base needs/wants.

[mulu]

<snip>
rmasonjr voting polls tell you what HST wants to do, not what is most important to the user base. Experts who design products do not use polls the way they are done here.... they can never capture the user base needs/wants.

I am not sure how HST comes up with the polls they did so far. I have a hard time believing that each engineer says "I would like to work on this". Instead, I would expect that they have regular meetings, discuss what feature request and bugs have been submitted, check how many people reported the same thing and weigh it according to severity (like the backup feature that doesn't backup 15 days as defined and just backups up 4 days should be VERY high on the priority list, especially considering how easily the DB/json can be corrupted).

And since Zigbee was mentioned, as I said in the other thread, I can't disagree with Ltek comment but I still would like to see support for some of the major Aqara devices like door/window sensor, water sensor, presence sensor and maybe vibration sensor. I don't think those sensors will be too hard to add but supporting them could add some significant value. Don't get into the video, etc. stuff.

[rmasonjr]

rmasonjr voting polls tell you what HST wants to do, not what is most important to the user base. Experts who design products do not use polls the way they are done here.... they can never capture the user base needs/wants.

But they get get input from the users, nonetheless.

You keep saying Jura? Do you mean Jira?

[Ltek]

I am not sure how HST comes up with the polls they did so far. I have a hard time believing that each engineer says "I would like to work on this". Instead, I would expect that they have regular meetings, discuss what feature request and bugs have been submitted, check how many people reported the same thing and weigh it according to severity (like the backup feature that doesn't backup 15 days as defined and just backups up 4 days should be VERY high on the priority list, especially considering how easily the DB/json can be corrupted).

the point I was making was the data they collect is VERY limited and thus the options are too limited. Then they pick what they want to present to the users from that... experts make it easy but letting the system automatically tell them what users care most about... it collects 100s or 1000s of data points (voting data for each/all request) then yes, they take that and decide what to do with it... but at least all users can see all option and vote. Right now, users only see the option HST wants you to see. And the voting method itself is still wrong, it doesnt show priority. Its easy to learn and get better at things like this, they seem to not want to. I didnt invent any of this... I learned from other experts, and experience. Same way those experts learned.

But they get get input from the users, nonetheless.

you dont get my point, which is fine its just not your skillset.

You keep saying Jura? Do you mean Jira?

Yes, Jira.

[macromark]

And since Zigbee was mentioned, as I said in the other thread, I can't disagree with Ltek comment but I still would like to see support for some of the major Aqara devices like door/window sensor, water sensor, presence sensor and maybe vibration sensor. I don't think those sensors will be too hard to add but supporting them could add some significant value. Don't get into the video, etc. stuff.

Yes, this is in the works now and we should have something for users to test in June.

[mulu]

Yes, this is in the works now and we should have something for users to test in June.

Cool!!! If it works well I can stop using deConz and the Jowi Hue plugin. My current solution (deConz & Jowi Hue) is very stable but having a solution not requiring that setup is very appreciated by me and I suspect others.

As a side note, I am only using the door/window sensor and water sensor (not really for water, though). I just mentioned the presence sensor and vibration sensor because I think there might be some significant interest from others for those basic sensors. I also have the Aqara cube device but I think it's a niche product and I wouldn't want HS to spend time on something like that. I rather retire this device for more important things. Just my 2 cents.

[racerfern]

It's very nice that HS is going to expand the zigbee devices that are recognized, however if it isn't going to include nearly all zigbee devices then it's just a bandaid to make some complaining go away. Aqara devices have been available for over three years, maybe more. They're cheap and popular. Now you're going to include them, after nearly everyone else found other solutions?!?

[langenet]

Personally, I think HST should leave the zigbee solutions to both JowiHue and mcsmqtt and move on to other resolutions. I added Aqara sensors back in 2019 using JowiHue that continue to work flawlessly. I see no value in both resources and time for them to think of adding them now at this stage in the game.

[Wade]

Personally, I think HST should leave the zigbee solutions to both JowiHue and mcsmqtt and move on to other resolutions. I added Aqara sensors back in 2019 using JowiHue that continue to work flawlessly. I see no value in both resources and time for them to think of adding them now at this stage in the game.

I tend to agree, in that zigbee requires ongoing development as new devices and capabilities are introduced. HST's limited resources might be better used elsewhere, and when/if HST's addition of support for new devices is slower than the others' it will likely only cause more frustration.

[ewkearns]

I tend to agree, in that zigbee requires ongoing development as new devices and capabilities are introduced. HST's limited resources might be better used elsewhere, and when/if HST's addition of support for new devices is slower than the others' it will likely only cause more frustration.

I agree as well and HST needs to consider the impact on the developers as they add existing PIs into Homeseer. Much of the usefulness of HS4 is carried by the PIs that I have paid for. Too many developers have thrown in the towel and left large swaths of my paid-for useful automation unsupported and ignored by HST. IMHO, HST needs to continue marching forward and leave the PIs be, unless one becomes unsupported. It is really a part of the notion: "If it ain't broke don't fix it."

If some specifics need to be mentioned: "...needed and simple: OR IF, Do/While Loops, Else..." are a continuation of the HS4 GUI. If liquid layouts and small screens are to be the standard moving forward, HST needs to consider the reality that nobody wants to "program" on a phone or tablet and smarter events will be needed to fill the gap.

Kudos to HST for asking users what they need and want. Keep those surveys coming...

[Homeseer666]

Personally, I think HST should leave the zigbee solutions to both JowiHue and mcsmqtt and move on to other resolutions. I added Aqara sensors back in 2019 using JowiHue that continue to work flawlessly. I see no value in both resources and time for them to think of adding them now at this stage in the game.

Agreed, HST should focus on their core system/automation.

Two examples come to mind:

- Redesign the device page or make it user customizable. Current/stock version is an eyesore and navigation is just painful.

- fix major bugs like losing all events on power failure. Public/non beta versions should be free from such obvious/system impacting issues. Yes I have daily backups but no time to waste on this.


As long as protocols (MQTT, JSON/HTTP NodeRed, etc ) are supported (which is the case), keeping up with new devices should be left to PIs and specialized 3rd party apps. Blue Iris spent years developing camera support, same goes with Zigbee2MQTT for Zigbee, Tasmota for Wifi, etc.; not worth investing cycles to deliver half baked versions while leaving core issues unresolved (see previous polls)

[TC1]

An actual complaint and not a product improvement suggestion: No documented code escrow process for Plug-In authors.

It is completely disingenuous and unethical for HST to take the customer's money (they get a percentage) for a plug-in when the possibility exists that the plug-in will be abandoned by a third party and no documented process to support the plug-in.

This is not a ding against the plug-in authors, life happens, and they have their reasons for stopping development and/or support. But at that point HST should responsibly take ownership of the code and decide to either to further support and maintain it or open-source it so that some other developer can take over.

To leave pay for plug-ins in the store that are no longer supported is disingenuous.

[racerfern]

But at that point HST should responsibly take ownership of the code and decide to either to further support and maintain it or open-source it so that some other developer can take over.

Yep, I said it years ago when PHLocation was abandoned. Part of the contract should be HS being allowed to either continue or pass on to someone else. A current version of all code should reside at HS every time a new version of a PI is uploaded. Easy enough.

[Bigstevep]

I tend to agree, in that zigbee requires ongoing development as new devices and capabilities are introduced. HST's limited resources might be better used elsewhere, and when/if HST's addition of support for new devices is slower than the others' it will likely only cause more frustration.

Just let the zigbee stuff stay with JowieHue or mcsMQTT and work on other things. The event engine, the Zwave V4 plugin improvements and bug fixes would be a great start plus work out a deal with Spud and upgrade EasyTrigger and make it a base function of HS4 tools. I see the competitors out there are getting stronger as their communities are providing fixes/drivers etc. Many of us are invested heavily in HS and prefer many of the capabilities and features to others but can get tired at times of keeping everything running as a part time job.

[randy]

Yep, I said it years ago when PHLocation was abandoned. Part of the contract should be HS being allowed to either continue or pass on to someone else. A current version of all code should reside at HS every time a new version of a PI is uploaded. Easy enough.

With PHLocation the author promised the source code but went MIA. I agree that HST should be allowed to keep a copy of the code for any paid plugin. For free ones like PHL that might be an unfair additional burden on them. I don’t know what a plugin author has to agree to for inclusion in the updater, but quite a few free plugins (PHLocation being one) are out there which are manually installed exclusive of the updater. Not sure how HST can have any say on how a developer handles them.

I am also aware of the number of technology companies that abandon consumers, Logitech being a prime example. It wold be nice if HST could prevent plug-in or technology abandonment, but what they can do is limited.