Correct that is how all my drivers work, which is why it keeps track of what is synced up. The easier way is to just fire out all settings every save but some devices have A LOT of settings.
2 Likes
UPDATE
Added ZSE70: Zooz 800 Series Z-Wave Long Range Outdoor Motion Sensor ZSE70 800LR | - The Smartest House
If you already have the package installed, update first then select Modify from the HPM main screen to add/change what drivers you have installed from the package
Version [1.2.2] - 2024-06-28
- Added ZSE70 Outdoor Sensor to package
- Fixed install sequence so device will fully configure at initial pairing
- Update library and common code
4 Likes
Just received the backshell for the DC connector, and added 2 of the ZSE70's using DC, no batteries.
I'm using a DIN mount Meanwell 24 VDC power supply, and some 16 gauge jacketed speaker wire. I tuned the PSU down to 21 VDC to stay within the 12-24 range of the Sensor.
They seem to measure illuminance somewhat lower than my Hue sensors, but seem consistent.
Hopefully they last!!!!
Thanks for the great tunable driver!
S.
1 Like
Just updated all of my Zooz devices to your drivers and just want to understand the parameters and settings.
For my ZSE44, I'm on firmware 1.10 and running your Zooz ZSE44 Temperature Humidity XS Sensor v1.2.2 driver. I'm not understanding how parameter #3 works.
The title indicates that a value of 1 would set the trigger at .1 of a degree, and 10 is a one whole degree. I'm trying to do some detailed temp tracking and was hoping to use .5 degree for changes.
The range shows 10-100. Does that mean you can't set the trigger to less than 1 degree? I guess I'm confused by how the description is describing the range vs what can be used.
For the Zooz ZSE40 4-in-1 Multi, the same parameter can be set down to the range starts at 1 / .1 degree level.
Can someone please clarify for this noob?
Thanks for the quick reply. I had scanned the Zooz docs, but wasn't sure if they applied to your driver or if they applied to their own driver.
Seems strange to me that they'd indicate a value outside of the range of the device....or that you couldn't set a threshold lower than 1 degree for some of their devices but not others. Especially since the "pure" temp sensor is the more restricted one. C'est la vie.
The Zooz docs apply to the hardware itself, not any driver. I just implement the specs into the drivers so you cannot try to set out of range values on the device (it wont take them). The 1 = 0.1 is a guide telling you that each +1 you add to the setting will increase the threshold by 0.1 deg.
Would there be a less confusing way to present that?
1 Like
I was unsure if the hardware limitation of the ZSE44 was correct since it doesn't match the ZSE40.
If the range is 10-100 for the ZSE44, you can't set the report trigger parameter to 5 to use .5 degrees as the trigger.
Your language is perfect if that's the case.
I just reported on Github an issue for the ZSE11-800LR where the illumination reports a negative value when in direct sunlight. https://github.com/jtp10181/Hubitat/issues/33#issue-2448749213
On the older versions it seems Zooz corrected the firmware for this issue but not in the latest version. https://community.smartthings.com/t/release-zooz-q-sensor-zse11/224579/17
Yeah I was suspecting that was the issue with the signed integer (same as old post you linked). So technically it is a firmware bug from Zooz, but since the illuminance would never be negative I could add a calculation to revert it to an unsigned value.
1 Like
Sounds good. I'd prefer it to be set to max (32767) rather than just using Math.abs. That way it is obvious it is topped out.
Yes I will do it proper, I have a formula I use to convert values from signed to unsigned. This is not the first time I have had to do this.
1 Like
One of my ZSE40s was showing as unknown and doesn't have many parameters to set. I am pretty sure your driver used to correctly identify it, but I can't really say for sure because I rarely look at the device page. It's an older 500 series V2 sensor paired to my C5 hub.
Your driver identified the firmware as 32.12 but not much else. The reason I was looking at it was because the battery died and I use the device data edit app to add the date I last replaced the battery to the data section.
After replacing the battery, doing a full configure, and manually waking it up it's now identified correctly but has 8 pending changes that I can't seem to do anything with... I tried changing a parameter, saving, and running configure again but it didn't change anything.
Here is the device data
There's nothing to note in the state variables or current states. Temp/Humidity seem correct. Last checkin time is updated.
Here is the log from the first configure/wake up
It's interesting to me that several parameters were null.
Another thing to note is that the custom data objects I had added in the past using the device data edit app are all missing as well. Not a big deal really, but now I don't know how long the battery lasted.
Have a real fix on my end. Just need to sync some stuff up and should be able to post it within a few days.
The conversion might look incorrect but the way it works is once it gets over 32767 it wraps around to -32768 as the next value, so the MAX value as a signed int would be -1
I got these with a flashlight aimed directly into the lux sensor.
Could someone tell me what the differance is in the humidity offset {hardware} and the humidity offset {driver} is on the ZSE44
Hardware sets it on the device so the reports it sends are already offset, and the other just offsets it on the driver side after getting the report.
Someone wanted to offset more than the hardware setting allowed so I added the extra settings.
1 Like
FYI, for the following driver:
https://raw.githubusercontent.com/jtp10181/Hubitat/main/Drivers/zooz/zooz-zse40-multisensor.groovy
(I am on version: 1.2.2)
I was getting the following error:
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0 on line 651 (method parse)
For:
if (cmd) {
logTrace "parse: ${description} --PARSED-- ${cmd}"
zwaveEvent(cmd)
} else {
logWarn "Unable to parse: ${description}"
}
ChatGPT suggested I replace it with:
if (cmd && cmd.size() > 0) {
logTrace "parse: ${description} --PARSED-- ${cmd}"
zwaveEvent(cmd)
} else {
logWarn "Unable to parse: ${description}"
}
If cmd.size was = 0 then cmd would also be "falsy" and it would fail the original test.
That code has been unchanged for 11 months and its the same code in all my drivers.
Also line 651 should be the logTrace line, so that error does not even make sense.
What is your line 651?
Maybe try reinstalling the code? Did it edit it some other time maybe?
Not sure how log it’s been doing this - I’ve been working on something else when I notices some errors…
Yea, 651 is the logTrace line.
I’ll do a soft reset on the hub to see if it makes a difference. It’s been a while since I’ve done that…
