When shopping for devices (in this case Z-Wave, but applies to others), often see "supported by Hubitat (or similar). Great! Or I will search in various places (such as these forums) for community support. Great! ...
...But then find aftter purchase-install that not all device capabilities are supported, or that behavior is a bit cough sketchy cough. Which leads to another search to try and determine if it is a device, driver, or a more basic issue.
I am new to Hubitat and only have a couple data points to draw from, so hard to draw conclusions. My two data points are:
Zooz ZSE44 Temperature Humidity XS Sensor -- Driver is community provided (thanks @jtp10181!). Device reporting seems inconsistent with parameter settings (could be me).
Minoston Mini Power Meter Plug. Driver provided by Hubitat, but does not appear to allow proper control of reporting (e.g., report only on change of X watts, which leads to exceessive events-noise).
Stress that this is not a critique of those specific devices, drivers, or their capabilities. IMHO the issue is a broader, and needs to be addressed at a higher level,
Would love to see documentation on what capabilities are supported by Hubitat (whether built-in or community supported) in order to make more informed decisions. Specifically: Vendor says device is capable of X, What set (or subset of X) capabilities does Hubitat support?
In my admittedly simple mind's eye, that might be, e.g., a simple matrix or enumeration of "device has capability X" with a corresponding "Hubitat [or community driver] supports Y'. Ideally X and Y are the same. If not, so be it.... maybe Y is not important to me. Or maybe it is, Hard to tell, and make decisions, without that information.
Thoughts? Do I have unrealistic expections? Thanks in advance.
The ZSE44 does have a built in driver as well but it had some issues setting the offsets properly so I made a custom one. Not sure if the built in driver was fixed or not.
Also another user had success with a Minoston MP31ZP plug on my Zooz (now also universal) smart plug driver [DRIVER] Zooz Smart Plugs Advanced (ZEN04 / ZEN05 / ZEN14 / ZEN15) . It wont give you all the parameters to adjust but you can manually set them with a built in command I have on the driver. You just need the parameter numbers and settings from the manual..
IMHO, this is something the vendor should specify, though perhaps an enterprising community member could do the same. But I don't think Hubitat "officially" can possibly keep track of what devices other vendors have claimed are compatible and what any custom drivers that may have been created for them can do. (Not speaking for them, though.)
FWIW, it seems Zooz is pretty good at this (e.g., "you need X custom driver for this functionality "), but it may depend on the device.
Regarding this particular issue, did you either wake the device after performing the configuration change or wait for the wakeup interval to pass (I think it's something like once or twice a day by default)? Most battery-powered Z-Wave devices need one of these things to happen before configuration changes to take effect as they are otherwise not listening.
It's still possible there's some oddity with the device, and if you aren't on the latest firmware for it, I might check the changelog from Zooz to see if anything looks applicable to you and update if so. But I don't remember anything off hand there.
Thanks for the rapid response; much appreciated. However, think we are losing the forest for the trees...
Again, this is not a critique of any indivual device or driver capabilities. (And thank you again; would not have considered those ZSE44's without your contribution.)
Think Hubitat needs to step up and set the standard for documenting capabilities so that the typical user does not have to resort to reading code or buy-try several different devices-drivers-whatever to determine fitness.
Yes, end users might go read code (at least what is accessible)--and I will as part of additional due dilligence going forward for anything Hubitat related.[1] But that should not be necessary. This appears to be a simple documentation issue, which Hubitat could, and should, set the standard for,
Then again, maybe I have unrealistic expectations? If I am in a situation where I am expected to read code in order to determine whether there is a good fit for Hubitat-devices, then I might as well just buy a RasPi or similar, a ZWave-whatever stick, and roll my own. Which sends me to HA (or similar) instead of Hubitat.
What say you Hubitat? Is this an unreasonable ask?
[1] Another point of concern... Hubitat provides built-in drivers for some devices, but which do not appear to support the full capabilities of those devices, but does not make the source for those drivers publicaly accessible (?), Given that, I have no way to judge the efficacy of Hubitat's support, and thus the efficacy of any given device for my needs, That sucks.
Is there a formal process through which users can submit proposed documentation for less common devices? My recollection is that the old Docs permitted Wiki-like input but no longer.
Maybe Hubitat needs an "officially certified" or somesuch...? Or maybe something as simple as "conforms to Hubitat documentation requirements"?
Would not take much to make a significant step forward. But IMHO Hubitat needs to own this and take the lead, Then the community-vendors-whoever will follow (would hope). If not, that would indicate more systemic issues.
What does Hubitat want to be when it grows up? Again, am a Hubtiat newbee. These are initial impressions. Happy to be corrected, but based on those impressions, do not think Hubitat's tracjectory is sustainable,
No, I meant host on their own, whether as a post here or some other means. (I don't think the official docs site is an appropriate location for entirely user-contributed content.)
Thanks for the suggestions; answers: yes, yes and yes. Can and have bypaased Hubitat et. al. to directly validate vendor claims as to device capabilities via alternate paths (still a work in progress).
In any case, that conversation belongs elsewhere. Again, this is not a question-critique of individual devices-drives. I can perform that verification-validation--the question is whether a typical user shoud need to do so? And to what extent Hubitat- or community provided drivers can leverage those capabilities?
At present that appears to be a crap shoot. From a buyer-consumer perspective, seriously suboptimal IMO, Thus again the question: What is Hubitat's plan to address? If the answer is NO, you're on your own, that is fine (I will look elsewhere for solutions),
Every single Z-Wave device I have ever purchased works with Hubitat (at a minimum, via a generic driver). Couple that with the "Basic Z-Wave Tool" driver and any advanced parameter for any device can be accessed.
Now granted this is somewhat of a DIY approach, but I don't think that Hubitat or any other company can justify the manpower needed to create a database and subsequent driver for every device (4,000 devices certified by the Z-Wave Alliance by mid-2022).
For some definition of "works" that is certainly true--no argument. So maybe start with a very simple ask: FOR every device for which Hubitat provides a driver (and for which driver source from Hubitat is not public): THEN Hubitat SHOULD provide a capability matrix/map.
That, in turn, would help set that standard for documentation forr all devices and community provided drivers. Without that, we are left with a random walk/crap-shoot through thousands of devices.
Not asking for anyone (including Hubitat) for exhaustive docunmentaion or support for evey device. Simply asking for better documentation--starting with those which Hubitat purports to support.
That must start with Hubitat IMO: they need to set the standard, even if they do not fill in all the blanks for every device-capability matrix. Think many here would be willing to help fill in those blanks?
p.s.. Annother subject entirely: Most all(?) of these devices-drivers follow a very similar pattern. Would seem a declaraive represention of device capabilities might be amenable to push-button driver-whatever generation. E,g, given a device-capability map X, auto-generate driver Y, Might be a bridge too far at this point, but maybe intruiging possibilities? If we could cover 80%+ of the device space, would go a long way to addressing the device-by-device whack-a-mole world we live in.
I don't see it happening. If they can test a device and it works as expected then it goes into the official compatibility list. If a device is a standard z-wave device and outputs the standard clusters based on the category of that device, chances are that the generic driver will work with it and that generic driver will expose all available attributes. It is up to the vendor to supply 1st a device to hubitat with said available documented capability so they can test it and approve it then vendor has to work out what ever deal to be able to use the Hubitat symbol on their packaging. If a vendor reaches out for that aspect of marketing I'm sure @pete will gladly work with them. Until then we have to be satisfied with a combination of the official list, word of mouth from other users, and community driver. I will also say that @mike.maxwell and @bcopeland are great about accepting the loan of a device in order to create a driver for it. If they do that, it will be rolled into that category's generic driver or a separate driver and it will be added to the official compatibility list.
Why stop there? How about a 3-D matrix that includes every firmware release for every device? Or maybe 4-D, which includes every hardware version as well .....
Thanks; that seems to provide a first-order answer, but would like an official response from Hubitat team. This conversation continues to talk around the issue. Where is Hubitat in the conversation?
What constitutes the "official compatibility list"? Not seeing it. Does that mean Hubitat providders a driver, or what? Does that mean the driver [Hubuitat official or comunity provieeded] provides access-control or all capabbilities of the driver, or what? I have an existence proof that the anser to both is false.
Hubitat cannot have it both ways, They either release all driver source for all devices--and provide approrpriate documentation--or they do not,. If you do not, the the entire concept on which this ecosystem is built is BS.
Apologies if that is harsh, but it is what it is. You can't have it both ways Hubitat.
These are devices that work with Hubitat under the mesh conditions in their testing facilities. As individual mesh networks and homes vary considerably, YMMV.
To answer your next question, this means that Hubitat has either tested the device to work with built-in drivers (or written one specifically to work with the device) or at least heard a consensus from the community that it does.
Before that list existed, early adopters noted their findings here instead: Custom Device Drivers [Wiki]. This list has continued to be maintained (by the community) as a list including community-created drivers, but Hubitat, by definition, does not provide support for community code. However, it may still be useful if you're looking for a device you can't find any "official" word on. So could a search of this forum or a post of your own asking a specific question about a specific device.
I'm not sure how your conclusions follow from your proposal in the rest of your post (e.g., I understand you must want the drivers to be open-source, though they happen to not be; but this would still not answer every question you could have about any particular device unless you also know how its firmware works, possibly inner workings of the platform itself, and other details). If you can provide an example of what you're actually looking for, or perhaps another commercial hub that does what you're asking, it may help clarify.
Not trying to boil the ocean ("...answer every question..."), just want sufficient data in order to make informed buying decisions.
At the risk of sending this conversation down the rabbit hole of a particular device-driver, hope a concrete example might help illustrate the issue. To that end, the Minoston Mini Power Meter Plug (MP31ZP) ...
Check official ZWave certification docs and capabilities--good for my use cases. Check!
Shows supported by Hubitat. Check!
Buy and install one of them. No issues. Check!
Then... Looking at Hubitat device page, many of the device's advertised capabilities cannot be controlled-accessed from the Hubitat driver.
Hmmm... Search the Hubitat forums for enlightenment... answers are effectively "if you want to control that you are on your own". E.g., "Advanced Send ZWave Command" or using the "Basic Z-Wave tool" driver.
Yes, can do #5, but if advertised device capabilities (by manufacturer) are not available through the nominal Hubitat UI, does that constitute "supported by Hubitat"?
If had known #4 and #5 ahead of time it would likely have changed my buy decision. Nowhere does Hubitat provide the data needed to make an informed decision. Again, this is not a critique-evalation of any specific device or Hubitat driver.
Thus my post, and hope conversation. Think this is an issue that deserves attention, with a solution which should not be onerous. Or maybe me being too simplistic in framing the problem-solution, or having unrealistic expectations?
p.s. Having trolled through the ZWave certification docs for a large number of devices, appears feasible to ingest that information to auto-generate drivers (Hubitat, HA, maybe others). Might not be the prettiest from a UI perspective, but a driver-of-last-resort or maybe driver-of-first-resort/starting point. (One reason have gravitated to ZWave is that information seems fairly reliable and is readily available in an automation-friendly form. Zigbee more squishy. Another conversation.) At the moment working on py script to do so; might also be done with a Hubitat groovy app. If anyone has worked on such, would love to hear your thoughts-experience. Thanks.
Sorry, but think that is a canard. These devices have an interface contract (as specified by ZWave); they obey the rules of that contract or they do not. For purposes of this discussion, will only consider those which obey the rules (are ZWave certified),
As to the question of drivers being open source... Maybe reframe that as Hubitat should open source all drivers which are generic, for some definition of "generic". That is, those which support only a subset of device capabilities. That would allow the community to build on those basic capabilities (the Minoston generic driver being a case in point),
Again, not asking for an answer to every possible question, but as the Minoston driver indicates, there are fundamental issues with Hubitat's representation of "support".
And no, do not and should not have to know intimate firmware details,. That is a canard and distraction. All of these (ZWave) devices have a defined interface contract, documented by the manufacturer, certified by ZWave.
If you think that information is incorrect, would love to hear it. As would think the folks who perform ZWave certification,
The staff have stated unequivocally in other threads that since this isn’t an open source project, they don’t consider requests from users to release all their driver code.
That doesn’t sit well with some people, and I don’t mean to get into a philosophical debate about closed vs. open source code, I’m just pointing out that their position has been outlined and doesn’t appear to be subject to change.
