Ah perfect. Found em. They were lost in all my otehr stuff I have running. I greatly appreciate your help!
I am thinking about getting a couple of these sensors, but am having trouble finding range and field of view information for the motion part of the sensor. Approximately how far out can this detect movement and what is its field of view in degrees?
Thanks!
Yes! Thanks!
Does that diagram have a legend revealing the significance of the three colors?
Someone can correct me if I’m wrong, but I believe the colors in the “side view” correlate to the colors in the “top view.” For example, the field of view is 110° when the subject is between 4 and 5 meters away from the sensor. If the subject is between 1-ish and 2-ish meters away from the sensor (black), then the field of view would be whatever the black degree amount is on the “top view” diagram (less than 110°).
2 Likes
Have Home Assistant config files been created for these sensors yet? Any help you can provide to get these running in my HA instance would be great. Thanks!
Config files for Home Assistant are on Inovelli’s github page. Here is a support article that shows how to set it up (not sure if you already saw this or not):
2 Likes
There is no key for the image but I think @lordpandemic is correct. The different colors are so you can correlate the different ranges from the side view and the top view.
1 Like
Is there anyone using this sensor with z-wave2mqtt? Wondering how you can get the motion active/inactive to “map” correctly (since it is sending a Home Security report). Sorry, not too familiar with z-wave2mqtt. Asking for a friend. 
1 Like
It also sends a basic report over association group 2 if you enable config param : 14
1 Like
That might be an option, but it looks like it will send a BasicSet (and not a BasicReport) for that association group. This may still be parsed as active / inactive in z-wave2mqtt though so it is worth a shot. Usually that group would send a BasicSet to a switch or bulb to turn it on / off.
Edit: Shoot, I tried it and while the Basic set is being received, I don’t see it being applied to an entity.
Here is the config I am using with Zwave2MQTT:
binary_sensor:
-platform: mqtt
name: "Bathroom Motion"
state_topic: "zwave/20/113/1/7"
device_class: motion
value_template: "{{ 'ON' if value_json.value == 'Motion Detected at Unknown Location' else 'OFF' }}"
I am using the following config options:
1 Like
I have the same issue using mine with either ST or HE. I can get no motion detection over 8 feet and often nothing greater than 2 ft! I sat a GE detector next to it that works at 40 ft…
But if mounted and installed properly you should get ~15-16ft
1 Like
Motion Sensing and signal strength -
I bought two of these as part of a 25 switch purchase (got a chunk of the ones I’ll need for the new house in one go when they were on sale). I have two comments, I think I’ll make two posts so we can keep threads separate more easily if there are replies.
Working mostly fine on a Hubitat Elevation (all updates applied) and using the latest Inovelli code from above.
Mostly this is about the motion and signal requirements.
At first I thought motion was pretty spotty. For most of this week I had one on my desk, sitting right here in front of me. Sometimes it spotted me coming in to sit at my desk, or getting up and leaving, other times not. (Default motion threshold of 8). Sometimes, I had to pick it up, cup my hand in front of it, and wave, for several seconds, before it would “see” the motion.
Changing motion thresholds didn’t really make it much better. All the way up to 10 and it … still missed me sometimes.
I believe I’ve decided this was (at least mostly) a signal strength problem - while my old battery eaters the Zooz 4-in-1 worked fine from here, the Inovelli 4-in-1 just was at the edge of communication maybe?
Having moved it into direct line of sight to the hub, I think it’s doing better. Any other thoughts? Has anyone else been able to compare a Zooz 4-in-1 with the Inovelli with respect to marginal signal strengths?
For what it’s worth, I’ve played with several devices while sitting at this exact desk and the Inovelli 4-in-1’s are the only one I’ve had any problems with in this regard.
(The signal problem is purely because I have so few places to put things in this rental house - wiring’s terrible, don’t want to make huge mods to the house nor buy a bunch of useless-once-I-move power thingies to use them without neutrals etc… In the new house (due in another month or two?) I’ll have switches everywhere that can repeat so I think I’ll be OK).
Termperate settings, and the interplay between them -
(Part two of the previous thread on motion sensing)
Working mostly fine on a Hubitat Elevation (all updates applied) and using the latest Inovelli code from above.
Referring to these three settings:
- Temperature Reporting Interval (“Interval”)
- Send Reports According to Threshold (“Send Reports”)
- Temperature Threshold (“Threshold”)
If Interval to anything less than 60 seconds it seems to ignore that setting though it says the range is 0 to “big”, and instead reports once per 60 seconds.
I understand this impacts battery life, but still it should either tell us the range is “60 to big” or let us pick a shorter period than 60 seconds.
Also does this behavior change when plugged into USB power? I tried the device on USB, but forgot to test the “faster than 60 second reporting” while on it. If I get time I’ll try that again.
The interplay between Send Reports and Threshold leaves what I think is one option unavailable.
If I set the Interval at, say, 1 hour, then regardless of Send Reports setting it won’t wake up and send a temp any more often than 1 hour, regardless of the change in temperature inside that hour. This is what my testing showed, but that the way it’s supposed to be?
I can set Send Reports to No (or Yes, I get it backwards, whatever) which then modifies the above behavior to then, on that once-per-hour report, only actually send the Temperature if it’s $threshold$ different from the previous temp. This is fine.
But the option I have not found how to do is to send a report when the temperature changes by Threshold without regard to any time threshold.
I can get close by setting the Interval very short, but again I can only go down to 1 minute.
Maybe I’m asking too much of a battery powered sensor, but it felt to me the Zooz would wake up and send the temp as soon as it varied by the threshold from the old temp. All the settings were a bit different, but it did seem that’s what it did. And their batteries are both dead now so I can’t confirm, which … maybe that’s exactly why the batteries only lasted a few months. 
So at this time, I have them set to 5 minute reporting periods, and left off (or on) the Send Report option so they report every time. In one day of this the battery still reports 100% - but the battery reporting on all these sorts of devices is atrocious (not saying there aren’t reasons for that, but still, it’s atrocious) so I have zero idea if that’s even vaguely accurate or not.
There should be some sort of testing done to see how much battery (current, whatever) is used up per 10000 reports. Or 1000, whatever. Then we can do our own math as to approximate impact of changes to reporting periods. Would it be perfect? No. Would it be useful at least as a vague guideline or as a comparison between two sets of settings? Yes.
So, in summary:
- Is there an option to have it report any time the temp changes by threshold, regardless of any “reporting period” setting?
- Is there any better guidance than widely varying anecdotal evidence on the difference in current draw/battery life between various reporting settings?
For 2, it seems that someone who has access to a dozen of these could just set a few up with a short reporting time, and a few with a medium reporting time and a few with long ones and just … compare average battery after a week or a month or whatever it takes to have them all show a drop in battery percentage? Or maybe someone has a “kill-o-watt” that works on USB and is accurate enough to do direct measurements?
I don’t suppose there is an updated manual with the correct config parameters in it? I’ve submitted the correct description for parameter 110 to Chris Jackson’s Z-Wave database so it will be pulled into OpenHAB. If there is an updated manual I’d upload that as well.