Are there differences in sensors between red and blue mmwave?

[signbit]

Hello,

I am running a mixed network of Red and Blue switches and I have just received a Red and a Blue mmwave switch and installed them. They seem to work fine out of the box for auto-on and off, although the one in my office is also triggered by the cat so I need to figure out how to tune it.

I am using zwavejsui and zigbee2mqtt containers connected to homeassistant via websockets and mqtt respectively.

VZM32-SN reports firmware 1.0.0 and VZW32-SN reports firmware 2.0.0.

I am surprised that they expose different sensors. The zigbee version seems richer, with occupancy and illuminance while the zwave version only exposes motion sensor?

I wanted to create custom automations because I want the light to turn on only if the ambient light level in the room is below a certain threshold. Am I missing a firmware upgrade on the zwave version?

Thank you for any advice!

[SViel]

@signbit

zwave version only exposes motion sensor

Could there be a driver issue? In Hubitat, my Red Series VZW32-SN reports both motion and illuminance.

I do understand however that the blue series version can expose more zones that, likely due to protocol limitations, the red series currently does not.

[signbit]

Sorry, I must have looked in a different place; yes, both blue and red expose Illuminance.

Blue exposes “occupancy” and Red exposes “motion sensor” - which is confusing. But maybe that’s home assistant’s interpretation? In both cases the entity is “binary_sensor”. For red is “binary_sensor.$name_$area_motion_detection” while for blue it is “binary_sensor.$name_$area_occupancy”. Is there a canonical one that should be used?

[rohan]

That’s just a naming issue. There’s no actual difference in how the sensor is detecting occupancy.

[signbit]

That’s just a naming issue. There’s no actual difference in how the sensor is detecting occupancy.

That indeed seems to be the case; here’s a couple of snippets from MQTT messages posted by zwavejsui:

zwave/pool_bathroom/overhead_dimmer/112/0/116/255 {“id”:“75-112-0-116-255”,“nodeId”:75,“toUpdate”:false,“commandClass”:112,“commandClassName”:“Configuration”,“endpoint”:0,“property”:116,“propertyName”:“mmWave Person in the Reporting Area 1 (Read Only)”,“propertyKey”:255,“type”:“number”,“readable”:true,“writeable”:false,“label”:“mmWave Person in the Reporting Area 1 (Read Only)”,“default”:0,“stateless”:false,“commandClassVersion”:4,“mi
n”:0,“max”:1,“list”:true,“allowManualEntry”:false,“states”:[{“text”:“Empty”,“value”:0},{“text”:“Occupied”,“value”:1}],“value”:0,“lastUpdate”:1770518232043,“nodeName”:“overhead_dimmer”,“nodeLocation”:“pool_bathroom”} zwave/pool_bathroom/overhead_dimmer/112/0/116/65280 {“id”:“75-112-0-116-65280”,“nodeId”:75,“toUpdate”:false,“commandClass”:112,“commandClassName”:“Configuration”,“endpoint”:0,“property”:116,“propertyName”:“mmWave Person in the Reporting Area 2 (Read Only)”,“propertyKey”:65280,“type”:“number”,“readable”:true,“writeable”:false,“label”:“mmWave Person in the Reporting Area 2 (Read Only)”,“default”:0,“stateless”:false,“commandClassVersion”
:4,“min”:0,“max”:1,“list”:true,“allowManualEntry”:false,“states”:[{“text”:“Empty”,“value”:0},{“text”:“Occupied”,“value”:1}],“value”:0,“lastUpdate”
:1770518232045,“nodeName”:“overhead_dimmer”,“nodeLocation”:“pool_bathroom”}

[signbit]

But this brings another question - shouldn’t there be four sensors exposed, one for each area? Or is “per-area” info just for debug purposes?

[rohan]

Not sure on the implementation on the red series. I don’t believe Inovelli has figured out a good way to expose all of the same controls within the Z-Wave spec. This isn’t an issue on the Zigbee switches since they can create a custom cluster with custom commands (which they did). Those are currently only mapped in Zigbee2MQTT and other hubs do not have control of multiple areas.