Glad it’s working.
I highly recommend the Google drive backup add-in too 
I have no problem at all with redundant backups! 
Also like having one onsite and one off-site. I do that with my desktop systems and my important data: One local and one cloud backup.
This diagram, coupled with the fact that the Community Addon sidebar tooltip says “Z-wave JS” and the Z-wave-JS UI node name is “a0d7b954-zwavejs2mqtt”, is a perfect encapsulation of the comedy-of-errors confusion that has surfaced over the last week with Home Assistant and Z-wave users. It should be subtitled “How to confuse your users to the point of leave-your-platform frustration”. Hopefully it should be a lesson learned.
2 Likes
I don’t disagree that has been confusing. But also people don’t really read docs.
Regarding the URL, zwavejs2mqtt originally was changed to Z-Wave JS UI. Would you have preferred the maintainer of the add-on change the URL and break everyone’s installations? I’m sure no one would have had a problem with that…
Do you have ideas how it can be better? It’s easy to point out the problems.
It’s to some degree confusing when you switch from one to the other and learn the differences.
But it’s not if people just have one or the other.
The documentation is there and clear though if you need to switch.
I used JS for over a year and just moved to JS UI a month ago. Needed one guide to do it, with no data loss.
I understand, and you make a valid point about the docs. Don’t get me wrong, I’m not trying to be critical of the hard working people that make all these components work either, I’m in awe of them. And you’ve done an excellent job of clearing the fear, uncertainty, and doubt around this event. I’m just commenting about hindsight of little decisions that made a event/bug a much bigger problem for some people than it could have been were the name clearer. As you say, hindsight is 20/20 vision.
As far as ideas of making it better, I think a dialog about how naming conventions for integrations, add-ons, and drivers could be clearer when having to explain them to a user base that may range from novice to sophisticated.
Thanks again for your patience and education in all this. It’s helped me and others.
1 Like
Speaking here as a former special ed teacher and someone with his own reading disabilities. Technical documents are tough, both in terms of writing them, and in reading them. One issue with dealing with ZWave (and this recent bug that came up, as well as my issue) is that there’s a lot to grasp, especially if it’s something you don’t work with regularly. At some point early this year (i.e. between 6-10 months ago), I had read through it all and set up ZWave using ZWave JS UI. I remember I made a decision to use the community addon over the official one. But since then I’ve had to write multiple programs, spend a few weeks researching VPNs so I can access my LAN from outside, through CGNAT, and a lot more.
I think that puts me in a place with a lot of other people. I had forgotten almost everything I had learned about setting up ZWave. Most people get it working, then move on to the next task. Then, coming back, there is a LOT of information to learn and digest to know enough to troubleshoot what’s going on. And, in my case, I went on about 4 hours of sleep for 3 nights in a row to carve out time to work on this issue. (Which also lead to exhaustion and stupid mistakes, like activating the official addon unintentionally.)
I’m not writing this to excuse myself, but to illustrate: Dealing with technical docs on a subject one does not know but so well is pretty tough. You also never know what’s going on with the person you’re dealing with. I’m not at all defending people who don’t read or research at all, but many times people are coming into a situation with heavy frustration, exhaustion, confusion, or other issues that make it hard for them to see what’s going on.
I think the docs for HA are very well done and the few times I’ve made suggestions, they’ve been listened to. I did look into OpenHAB at one point, but gave up quickly because there were some STUPID things done in the documentation. And when I say that, I’m speaking, again, as a former special ed teacher, but also as a former, certified, English teacher (at multiple levels - in special ed, in some places, you fill in a LOT of gaps). There was serious hostility toward any comments that were not, “Oh, this is wonderful!” HA has good documentation, the people here do listen, and there’s a good community.
That’s a very good point. What confused me is that I knew, in the past, I had it set up and working, so when I tried to stop using the official addon, and it gave me the default port 3000, I figured that was probably the value I had used before. In other words, I thought it would have kept the previous value instead of using a default value.
Three thoughts on that:
-
Is it possible to add a note on that dialog, something like, “(If you are using the ZWave JS UI addon, then use ws://a0d7b954-zwavejs2mqtt:3000.) ?”
-
Small issue, that may help with the documentation. I don’t know if this is just due to how I read or not. On the first link, it linked to a point within the document that included good instructions, however, it did not include the proper port address, which is given elsewhere in that same page, ABOVE the link I was given. Yes, it’s there, but it would be helpful to have that information given in the section on switching to ZWave JS UI. Granted, it’s a repeat, but, and, again, speaking as a former English teacher here, when you have a section like that, which is essentially a stand-alone section (as evidenced by having a link directly to it), it would help to either include a reference to the section, ABOVE it, that includes the port info, or to have the port info right there. When a link goes to a part within a page, there’s a built- assumption, for the reader, that it’s pointing to the pertinent information, so there would be no reason to scroll up and look for more.
(And, @freshcoast, you included that info in another post - one I saw after I made that change, so that was a helpful post, it was just timing that led to me not seeing it at first.)
- Would be be a problem with backwards compatibility and would it confuse users to change the name of the ZWave JS UI addon to something that is not so close to ZWave JS? I’ve mentioned my reading issues and it was frustrating distinguishing between these two names in multiple locations. Granted, not everyone has those issues, but with such similar names, part of the confusion is that they seem related - as if one source put out two versions of the same addon, or one is a newer version of the other.
That’s worth thinking about, at least from my point of view.
And thank you, everyone for the help on this. With ZWave working again, I no longer have to wake up in the very early morning and change my thermostat so my wife and I aren’t freezing when we get up on these cooler fall mornings.
3 Likes
I think that is where the vast majority of user confusion comes from. When they renamed zwavejs2mqtt to zwavejs-ui, because people would get confused by the mqtt part, it actually made it worse. Now we have two mutually exclusive add-ons, zwavejs and zwavejs-ui. This is totally confusing for anyone who does not already know exactly how this stuff works. It would have been a lot better to either not rename zwavejs2mqtt at all or to rename it to something completely different, maybe ZUI or something (akin to ZHA from the zigbee world).
I’m wondering if the JS part of the name is needed at all. True, from the developer’s point of view, it’s a big part of it, but on the user end, who cares? And seeing “ZWave” and “JS” in both makes it look like they are related. I like ZUI - especially since I can pronounce it “zooey.” But changing to that is distinctive and would make it harder to confuse the two.
I don’t use Zigbee, but when I see ZHA, I think of Zha’ha’dum from B5 - but that’s just me.
That’s historical. There used to be another zwave driver, OpenZwave and its UI / MQTT interface was zwave2mqtt. The developer later abandoned the project and another zwave driver took over, zwavejs (because it was written in JS). zwave2mqtt also forked to use the new driver and, to differentiate it from the previous iteration, became zwavejs2mqtt. Which was again later renamed to zwavejs-ui.
That’s because they are. They use the same backend driver, zwavejs. But of course, as you said, these details could be abstracted away from the end user.
Okay, fair point - but (continued below…)
I think tat’s even more important. Those doing the development work will know about this or learn easily about it. I think this is a case where users and developers will see things differently. Since the goal is for it to be used by, well, users, I think it’s more important to have clarity for the users, since whatever information the previous name conveys is something developers will know or learn quickly, I think the issue of user confusion is important to address. And, although I wasn’t in the discussions involving the bug, I think that indicates it’s a problem that would be nice to have solved.
I get that it means some confusion in the transition, but can’t that be addressed? Can’t some message be included with the upgrade notification, like, “You are using ZWave JS UI. To avoid confusion with other addons, the name will be changed to ZUI. It’s the same extension, but the name is changed?” Or maybe it could be put on the panel for the addon or somewhere people will see it and have to acknowledge it with a mouse click?
Was this ever figured out. I can’t connect my Home Assistant to zwavejs2mqtt anymore. It used to work but I have been down for months now and it won’t connect anymore. I just get an error “Failed to Connect”