Thanks so much @jtp10181 for these drivers. They work much better than the built-in drivers which did not seem to be compatible with the 700 series sensors. I recently purchased several of these and they don't seem to be updating when changes occur like I expected. For example this evening, my son was showering and it took 20 minutes for the sensor to report a change in humidity, and when it went from 43% to 66%. When it updated humidity it also updated illuminance to 100% and a new temp report. I've noticed on both my sensors that they seem to report periodically but not on changed like I'd expect.
Motion reports are sent quickly and were being received during that 20 minute period when no humidity reports were being sent.
If there is active motion they do not report the other metrics. Zooz says it is to improve the speed of the motion reports as that was their primary function. For my bathroom application I tested out a ZSE11 and ZSE40 and decided to put the ZSE11 in there, it is a little slower turning on the lights with motion but it reports the humidity faster.
Or if the sensor can be placed so that it wont see any movement while someone is in the shower that would work also, just set a significant delay on the lights so you dont have someone in the shower in the dark. I also have my motion activation keep the lights on if the humidity triggers the bath fan to come on (via Smarter Humidity Fan app)
I've been playing with the triggers and offsets on my two 700's to tweak the frequency of reports and calibrate temp and humidity. [side note: they NEED calibration; will post results in a new topic] I have two questions:
What's the right procedure for getting a parameter change synced?
Should the sensors continuously report syncStatus : 1 Pending Changes?
I follow these steps when I change a parameter:
Enter the new value
Click Save Preferences
Click Configure - sensor shows "syncing" for a few seconds
Click Refresh
Go to the sensor and push a pin in the hole to wake it up - LED flashes blue
On my computer, I again see "syncing" for a few seconds
I have five of the 500 series V2 units running firmware 17.9 and I got some new 700 series but have not added them to the network until I sort this out or they may just be used to replace the 500 series which were stable on SmartThings but nothing but a headache on Hubitat C7.
I finally got the 500 series joined without security (the initial headache) but even still it seems these 4-in-1 units make my ZWave network very unhappy on an inconsistent daily basis.
They're no longer plowing through batteries at least, but a lot of ZWave devices will not respond and this issue goes away and ZWave is rock solid when the five ZSE40 (500)s are removed from the mix.
I was using the built-in driver which I discovered since shows as deprecated and now there's a "New" one but I don't know what the differences are between the system one and this driver. I am inclined to try this one but this says minimum firmware is 32.02 so I'm inclined to think I should probably be using the "New" system driver and not this one?
I understand firmware before 17.9 can't be updated, but 17.9 and higher can, but I am not sure how to get the firmware or how far the unit I have can be updated. I opened a ticket with Zooz but still have not heard back.
You can skip 3 and 4, you only need to save and then wake up the device.
I have noticed sometimes you have the refresh the page for the "Pending" to go away, I think this started with HE firmware 2.3.1. Otherwise, if the Pending Changes wont go away, something is not saving correctly. If you enable debug logging and then do a wake up, it should show in the logs which parameter it is trying to sync up. You can also check the "configVals" map in the bottom data section to compare the values with what you have set, they should match.
I think the "new" system driver was updated to work with the 700 series device. I am not sure if it is backwards compatible to the older devices. For my custom driver, I have nothing older than 32.02 to test on and I am not sure what parameter options may or may not work on older models. If you want to try it out and see if the Parameter 8 setting works on that older model you can let me know how it works. One other user was getting parse errors on an older device, which the logging should be fixed to get more info. I may need to bump the command versions down to work with the old models, which I have done in my test code but I have not posted it yet.
I see numbered parameters 1-7 and a few that have no number, but no #8. But I thought I read farther up you were hiding those from older firmware so I assumed that was why.
Log below for one of my sensors, but both are the same. The pending parameter not saving correctly is motionClear. I changed them yesterday at the same time.
[dev:16](http://192.168.1.5/logs#dev16)2022-04-22 12:47:31.110 pm [debug](http://192.168.1.5/device/edit/16)null: updating state -- lastEventTime: 2022-04-22T12:47:24.623-05:00
[dev:16](http://192.168.1.5/logs#dev16)2022-04-22 12:47:30.919 pm [debug](http://192.168.1.5/device/edit/16)null: updating state -- lastEventTime: 2022-04-22T12:47:24.623-05:00
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:47:03.966 pm [debug](http://192.168.1.5/device/edit/164)den sensor: motionClear (#5) = 120
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:47:02.310 pm [debug](http://192.168.1.5/device/edit/164)den sensor: humidity set to 33.5% [NOT CHANGED]
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:47:02.308 pm [debug](http://192.168.1.5/device/edit/164)den sensor: Humidity Offset by -4.6 from 38.13 to 33.53
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:47:01.530 pm [debug](http://192.168.1.5/device/edit/164)den sensor: illuminance set to 100% [NOT CHANGED]
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:47:01.526 pm [debug](http://192.168.1.5/device/edit/164)den sensor: Light % Offset by 0.0 from 100.00 to 100.00
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:47:00.712 pm [debug](http://192.168.1.5/device/edit/164)den sensor: temperature set to 70.1°F [NOT CHANGED]
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:47:00.709 pm [debug](http://192.168.1.5/device/edit/164)den sensor: Temperature Offset by -0.7 from 70.83 to 70.13
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:46:59.972 pm [debug](http://192.168.1.5/device/edit/164)den sensor: Received Version Report - Model: ZSE40-700 | Firmware: 32.32
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:46:59.114 pm [info](http://192.168.1.5/device/edit/164)den sensor: battery level is 100%
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:46:58.823 pm [debug](http://192.168.1.5/device/edit/164)den sensor: Changing motionClear (#5) from 120 to 255
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:46:58.683 pm [debug](http://192.168.1.5/device/edit/164)den sensor: getConfigureCmds...
[dev:164](http://192.168.1.5/logs#dev164)2022-04-22 12:46:58.568 pm [debug](http://192.168.1.5/device/edit/164)den sensor: WakeUpNotification
Turn on debug logging, then press Refresh, and then wake it up. This will allow the driver to detect the settings and show the parameters. I should probably have it read the existing firmware if saved in the data at the bottom and use that since its a battery device and getting a refresh is a PITA.
Should be able to refresh the page after a minute and the parameters will show.
I suspect that the 255 is not the true upper range, it is 0xFF which is typically something reserved or not used. So I would try something a little lower like 250 or even 254 should work. I will test it on on mine later tonight and then fix the driver to be the true range so no one else runs into that.
The un-numbered ones are driver settings which do not tie to device parameters. I forgot I was able to confirm that #8 I think was added in 32.02 so anything lower than that it is hidden.
For anyone following this thread, I added a ZSE44 driver by request. Added to GitHub and in the same HPM package with the ZSE40. Mainly this fixes the issue with the Offset parameters two-fold. All the settings will take from -10.0 to 10.0 with this driver, and you can set it to finer precision of 0.1 with a free type box instead of a drop down.
I also included the enhanced info you get when changing settings, copied over from the ZSE40 driver.
Coming next I will finalize this driver (pending any bug reports) and release an update for both drivers with synced version numbers.
EDIT: Does anyone have any use for the associations? It could be used for Over Temp / Freeze alerts to go out to other devices. This is only an advantage if the hub was offline, and your devices are still online. Otherwise a rule on the hub could accomplish the same thing I think? Seems like a waste to implement all the settings for it unless people would really use it.