Right exactly. If I factory reset it, pair again, it returns to inactivate, and then hours to days later, I’ll find it stuck on active again. At first I suspected it was catching trees through a window, but I’ve ruled that out. I reset it again yesterday and so far it has remained on inactive but no one (including myself) is home for a couple weeks so I won’t be able to put it through its paces for a bit.
I’m using Robert’s — no offense!
Okay thanks for the tip. Will check that out when I’m back.
@bertabcd1234, I got back home, reset the ZSE11 800 once again, and of course now I can't recreate the problem with a stuck active motion! So I guess that means I'm all good, but I always worry when I haven't figured out root cause. I'll watch it carefully and then try the above diagnostics if it recurs. In the meantime, sorry for the false alarm.
Seems your driver can only support 1c increments, but the official driver can do 0.1c and intentions to update your driver to also support this? If plugged in this is really useful
Increments for what, specifically? The latest version of the manual on their website mentions only whole degrees Fahrenheit for parameter 183, the reporting threshold. This is distinct from the precision with which the device itself reports. But I don't see anything in the changelog to suggest any differences with any of these.
EDIT: looking at the docs again, I may have missed that these values represent tenths of a degree, despite the confusing summary of the at the end, so this parameter might already work the way you want, just obscured by my misinterpretation and saying 10x what each value should be...
it's in Fahrenheit for some reason but it starts at 1° and goes all the way up to 144 which doesn't make any sense you only want to do a reading if the temperature changes by 144° F
not unless I'm missing something here I wanted to report every 0.1°
@bertabcd1234 I think they must have make a mistake in the docs before, I have my driver the same way. Or it has changed with the newer model but they did not make note of that in the docs. I wonder if that why the battery life was so terrible and the motion was slow on the old one? I have always had mine set to 1 and switched it to USB power.
I will try setting it higher and then see how its reporting looks like today.
Currently mine looks like it is totally ignoring the threshold and reporting based on the 6 hour interval I have set... which it is supposed to be the opposite.
OK, my previous post still had some legit points (IMHO ), so let me try again here...
This is a good example of a unexpectedly curve-ball parameter setup that Zooz sneaks in their stuff once in a while -- these are pretty rare, so they are really easy to miss or look past.
I can't recall another example at the moment, but I remember several times over the years catching stuff like this in Zooz docs and thinking, "Well well, you sneaky little..."
Here's a paste of 3 subsequent lines from the Advanced Settings page for P183 -- italics emphasis mine:
For the setting below, value 1 is equal to .1 degree, value 10 = 1 degree, and so on
Values: 0 – disable; 1 - 144 (degrees Fahrenheit)
Default: 1
First line -- Value 1 = 1 degree could perhaps make OK sense for F, but not for C. So that explains this "value 1 = 0.1 degree" thing. But for F users, misreading this value setup is a easy to do (especially when you're whipping thru all the param options, and not just focused on this one)
Second line -- Why the "(degrees Fahrenheit)" caveat here? Does this value range also apply to C? If "yes", then why caveat F here? If "no", then what about C values?
Third line -- making the default value = 0.1 degree seems like an odd choice, even for C... Zooz is typically pretty darn common-sensical with their default values, so when I see something like this, it makes me somewhat suspicious about the integrity of the entire parameter setup.
Ok, thanks for confirming I didn't miss something the first time around. The fact that the summary at the end still says "degrees Fahrenheit" must be further lingering proof that they fixed this mistake in the full description.
Did you see my description (and the discussion) about the above?
So 18 °F would in fact mean 1.8 °F or 1 °C of change, at least according to the docs (see above for more discussion on whether the device actually does anything different in response...). This is effectively a display issue I could fix in the driver. The range of underlying values are still there.
Hey, I was just following what their docs said -- in case anyone wanted to actually use that value instead of disabling reporting for some reason.
I am seeing reporting when change is less than 1F within a few minutes of each other.
Unit is on USB power. Bumping the setting up to 5 and will check again later.
So 800LR model it looks like the setting is probably 1 = 0.1 degrees
My older FW 1.30 model still looks like it is just reporting on an interval and ignoring the threshold for the temp only. Humidity and Lux are reporting more often when changes happen (shower or lights turn on and off). I will need to keep testing this one. I may need to switch it back to battery power and see if that fixes the temp reporting.
Adding to the confusion, I just looked at the built-in driver, and it uses the numbers as tenths of a degree Celsius, so 1 = 0.1 °C, not 0.1 °F (as the manual seems to say -- now) or 1 °F (as I think it did when I wrote my driver). In any case, the values are definitely there in my driver; it's just not clear what any of them mean, I guess. (And maybe it's changed based on hardware revisions or firmware, but they usually note that, and they didn't from what I saw in the changelog I linked to above.)
From what I can tell of the Z-Wave JS driver, it also assumes whole degrees like I did, though that was a quick glance at the code without knowing what more, if anything, that might get filtered through before or after display or input from the user.
Haha well thank you for having a look. Ill switch back to your driver. As long as I select the lowest setting then it will be the same number in the back end.
My guess is their number settings in Zooz are in F and when you convert that to C you get these decimal numbers like .1 and .5.. it's all relative I guess!
Thanks for exposing all these other things the OEM driver does not.
Question is there a reason why if a devices supports a feature why an OEM would not write a driver to expose all the settings? Is it because there are so many platforms and they just want to get a basic driver out? Do they want to hide these settings from us? Seems so strange that there are 20 settings on some of these devices and only 5 of them get exposed to the user to set..
Yeah looks like my hunch is right, I just looked at the manual for this and it states this:
@jtp10181 Looks like you already pointed this out. Difference is that the OEM driver must have two units programmed in it to map to the same numbers in the back end.. My system is set to C
Robert can likely add more color, but my guess is that way back when, devices were frankly simpler -- there just weren't as many parameter options as we see today.
The native drivers have always shot for the compromise solution of presenting enough parameters to be useful, but not so many that (noob in particular) users get intimidated (or get themselves in trouble by mis-applying parameters).
That compromise solution obviously isn't going to make everyone happy, but it is what it is... For ZW devices where not all params are exposed (native or community driver), you can always use the Basic Z-Wave Tool driver to manage any/all parameters on your own.
That's actually not the latest info for P183 -- it's close, but in my post above (#50), I linked to the Advanced Settings page which has the current description.
By "OEM," I assume you mean Zooz? If so, they didn't write any of these drivers at all; the built-in driver was written by Hubitat staff. Zooz certainly could write their own driver, but I don't think they have any regular staff who have this skill for Hubitat or any home automation hub, so the hubs tend to do it themselves. For some devices, Zooz has sometimes highlighted third-party drivers that they didn't write but "officially" recommend, often when there is no built-in driver at all (this is more like to happen when they give the hub manufacturer a sample device unless it's one someone happens to already have).
As for the built-in drivers, the above is a good summary--the built-in drivers don't aim not to expose all functionality, but advanced features may be left to the vendor or community for full implementation. This is particularly likely when the manufacturer tends to make big changes between firmware or hardware revisions that might affect the way Z-Wave parameters (or similar options for other kinds of devices) work between these versions, as this one tends to. This may also be the case when there isn't a Hubitat "capability" (developer term but basically a set of commands and attributes that are standardized) that lines up with the functionality. But if there is something you're really missing that seems reasonable, you might be able to get it added to the built-in.
So wait when on their page when they point to GitHub repo is this not their code but pointing to someone else's code? Or do you just mean only the built in ones are made by Hubitat staff?
Correct, it is usually my code (on my Github), in some cases it might be @bertabcd1234's if he beat me to making a driver for it and I never bothered making one.
It is to the point where they often give me sample devices and ask me to make custom drivers for new devices.
), so let me try again here...
