Replies: 4 comments 6 replies
-
|
/cc @blhoward2 since we just talked about something similar earlier today. |
Beta Was this translation helpful? Give feedback.
-
|
It's an idea but it's difficult to get any manufacturer to do anything and keep it updated if they aren't already doing it for their purposes. They often don't even keep the device's record updated at the zwave alliance, which does contain the parameter info. I'll keep this in mind as we continue talking with manufacturers. We also hope to eventually offer firmware updates through the platform so that may be an opportunity to connect some of this info, at least for those that will participate. |
Beta Was this translation helpful? Give feedback.
-
|
I've suggested it to Zooz in my recent communications, since they are looking at doing something anyway. It might as well be productive, especially if we can guide it. I suspect manufacturers get calls from users too who's devices don't work as expected. A unified system would help everyone, but only, as you said, they could be convinced of that. Perhaps if we couch it in terms of how it helps THEM... maybe they don't fully understand what is necessary on this end to make their devices trouble-free for their customers. THAT should be important to them, I would think. I was looking at trying to fix the ZEN15 (#3745), but can't find enough information from Zooz to do so, as their changelogs don't have sufficient info, and their Advance Parameter page on the KB only shows the latest FW. I've pointed that out to them. Anything done now would be purely stopgap IMO. |
Beta Was this translation helpful? Give feedback.
-
|
You're assuming they care enough about us, though. It's really only the open source projects that have this issue. Manufacturers submit their own device handlers to SmartThings and Hubitat, as an example, but even with the cooperation we have we've had maybe one manufacturer ever submit their own device file. Inovelli forked the repo once and said they were going to, but they never have to my knowledge. Few manufacturers submitted their own device files to ozw and only when they had to...and there the device wouldn't even work without it. If we're lucky they forward the support ticket to us so we can fix it...often they don't even do that. Case in point...Zooz is great to work with and they support us with test devices and such, but even they've never tried to fire up zjs2mqtt to explore it to provide better support to their users using it. (Versus Aeotec who maintain an active HA install for testing.) We've been working to build a story so they do care, but its a process. We started collecting analytics so we can prove a lot of their devices are on our platform but we're just starting to be big enough where its impressive enough data to use. We were just brainstorming this morning on other things along this line too. Before we leap to trying to get them to start a new process with a json for what they consider a minor problem, I'd be happy if they'd just answer our support inquiries and provide a contact for when we identify a firmware bug. Other than us, I don't think any projects try to keep track of at which fw a particular parameter was added, so that cuts against getting them to release that info. Most manufacturers provide very little in the way of any platform specific support. They send users to SmartThings, Hubitat, or us... |
Beta Was this translation helpful? Give feedback.
-
|
Hmm... that sounds extremely frustrating.
If they are "writing them for each hub", which I assume would each be different from the other, it's no wonder they pick a few major hubs and stick to that. If that is indeed what they are doing, then I think it would be easy for them to realize that writing a single JSON (or whatever) file that everyone can use would be much easier for them. But again, I may not have a full view of the situation. From a user perspective, coming from OZW (HA OS implementation) where I had the ability to 'install' my own config parameters info, I can't do that in zwave-js because it's in a container which I can't access, which makes a system where they can be updated quickly that much more important. I have 49 Zooz products on my network, have done a bit of testing/debugging for them, and I've pushed them pretty hard to start including HA in their compatibility lists, and in their documentation, which they are now doing, even providing HA QR codes in some of their docs. Since I use zw2mqtt CP, and it comes up in our email exchanges, I will ask if they have it installed. ;-) Similarly, when I engaged Ecolink, they asked for some stats on HA and wanted to know how to get better exposure with the community. I worked with them to test a new Siren/Chime unit on HA, and provided some significant feedback to them. They were appreciative enough to send me newly released Thermostat to test. @AlCalzone and I recently created a config file for it.
In my experience, dealing with the ones I have, the vendors seem to have limited knowledge of ZWave in general. They use Silicon Labs tools to create their FW and send it out the door. I may be completely off here, but that's my impression thus far.
Just another reason I'm using Home Assistant! |
Beta Was this translation helpful? Give feedback.
-
It wouldn't be everyone. The device handler for SmartThings and others contain much more than just the parameters...its the actual code to set the params and such. Those wouldn't ever change to use the json. Ozw is effectively dead. That leaves us and...who? OpenHAB? Even if we could get those few, smaller projects on board with this, which I'm not sure we could, you'd never get the major hub manufacturers onboard. Its a good idea but basically what you'd be suggesting is that all the manufacturers submit this information to a third-party database just because. Some may, most won't, and those that do won't keep it updated.
To be fair, if thats true (the zwavejs addon) that's because you chose to run it that way. I can enter my container just fine. The zjs2mqtt addon supports a custom config directory, which you can access right through the UI. You can also get into the zwavejs addon if you ssh in, but they chose not to implement the custom config directory option. And, in zjs2mqtt you can set any config parameter, unbounded by our files, using the advance set call at the bottom. That's why it is there.
That's great. I'll remember that as we're preparing a push for the end of this year to get in contact with some more manufacturers. We may need your contact. |
Beta Was this translation helpful? Give feedback.
-
Ah, didn't know that. Makes sense that wouldn't change. That's a much different approach than zwave-js (which I consider to be more flexible).
That sounds ominous... I have no idea how Home Assistant compares in user base to the commercial hubs, like SmartThings, but what I do see is, just since March 2020 when I first started with Home Automation, Home Assistant has grown by leaps and bounds in capabilities, and the amount of user interaction and developer support is very encouraging. I also see commercial hubs either go out of business, exit home automation, or turn their eye toward charging for their now-required cloud service. Yet Another reason I use HA. I don't believe I'm unique. I read the frustration online. IDK, maybe HA is just noise and I don't know it, but I see something pretty incredible, and zwave-js is part of that foundation - in my case, ALL of it, as I only use ZWave atm.
I wouldn't rule it out just yet. If we WERE able to get other OS projects on-board, perhaps some device manufacturers would consider that putting a few parameters in a text file every few weeks preferrable to maintaining a SW development team to write device handlers for several major commercial companies. Having once managed a Division for a Fortune 100 company doing $20M in IT Outsourcing for other such companies, I can tell you that such a move would be a no-brainer decision - on cost basis alone. Just another perspective.
Absolutely right. Plus it's the 'recommended' method of running HA. I would think most (or at least a growing number of) users would be running it that way.
OK, have to admit that I didn't know that... I knew I could access the files in the Store, but didn't know I could change them, or if it would have any effect on zwave-js (like configuration).
Recently found this NOT to be true. If there is NO config file at all, there is NO Config block in the list of CCs in CP, and therefore no way to reach that feature. That may change, I understand. I tried using the zwave-js service calls in HA, they didn't work either for a device with no Config file. I have a good relationship with both Zooz and Ecolink. Just let me know how I can help. |
Beta Was this translation helpful? Give feedback.
-
That sounds like something we can fix. The HA service will never work as its bounded by our files. What's odd is that the device didn't setup its config parameters itself. When we don't have a file we poll them from the device if it supports it.
The Ecolink one may be helpful. Some days I talk to Zooz a few times in one day so we're good with them. |
Beta Was this translation helpful? Give feedback.
-
Yup, I've talked to @robertsLando about this already
Not many devices support Configuration CC V3, which would be required for this. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I can look at that on Monday |
Beta Was this translation helpful? Give feedback.
-
I've noticed on multiple home automation support forums the same issues regarding config files either being wrong, out of date due to FW updates, or in the case of new devices, missing altogether. This is as frustrating to the end user of the device as it is for both the manufacturer and development teams who must respond to them. This seems to plague all implementations using ZWave.
It would seem rather trivial for device manufacturers to maintain an agreed-upon, standard-format JSON file containing configuration parameter information that can be updated with each new FW release. This file could then be accessed/pulled from the manufacturer's site at will by HA implementation teams, and which could then be trivially converted into the proper format for that particular implementation; but everybody starts with the same information. Naming conventions could include already standardized IDs to identify device files. If this could be standardized by the alliance (if there still is one), would it not provide a much-needed solution to the config file issue? Given continual FW updates and the ever-growing number of new devices, this will only get more or a maintenance nightmare as time goes on.
I am aware that the zwave-js team has prompted Zooz to provide better access to that data, as have I having worked with them quite a bit. They have in their plans for the new year some kind of DB to track changes by FW release. But beyond providing better access to the data, does it really help solve the larger maintenance issue? Could this be an opportunity to work with Zooz to develop such a standardized approach that might be adopted by others?
Just thinking out loud here.
Beta Was this translation helpful? Give feedback.
All reactions