# Hub Firmware Beta 0.41.X

**URL:** <https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786>\
**Category:** Hub Firmware Beta\
**Created:** [January 12, 2022, 7:52pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786 "2022-01-12T19:52:08Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![alissa.dornbos](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/alissa.dornbos/32/144050_2.png) [@alissa.dornbos](https://community.smartthings.com/u/alissa.dornbos)\
**Post date:** [January 12, 2022, 7:52pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/1 "2022-01-12T19:52:08Z")

</div>

## Hub Firmware 0.41.X Beta

Hey everyone!

We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.41.x will begin rolling out in batches starting on Jan 13th; we will send out an email when we start updating Hubs. We will be paying close attention to any issues encountered by users so your hub may not get updated right away. The hub will be offline for about a minute during the update. See below for more specific details about the update.

If you haven’t seen our recent announcement announcing the beta release of SmartThings Edge - a new architecture for Hubs that use Device Drivers and Rules to execute Hub Connected devices with lower latency, higher reliability, and… _local execution_ . [Please check out that announcement here.](https://community.smartthings.com/t/announcement-smartthings-edge-for-devices-and-automations/229555)

**Version**

- 0.41.x

## **Hub Target**

- Samsung SmartThings Hub 2015 (Hub v2)
- Samsung SmartThings Hub 2018 (Hub v3)

## **Release Date**

- **Release Date: 13 January 2022 ~ 14 January 2022**  
Note that this release will be spread over the listed days, so you may not see your Hub update on the first day of the release period. We will post on this thread once all users should have received the update.

## **Release Notes**

### **General**

- Reduce CPU and Memory consumption in various components

### **Edge Drivers**

- Bugfix for stale tcp socket connects timing out and killing the driver process
- Bugfix for Edge Driver backed Zigbee devices with the Power Meter capability reporting power levels that were off by a factor of 1000 (incorrect conversions between Watts and Kilowatts)
- Add AnalogInput Zigbee cluster to the library
- Allow usage of the `"visibility"` field for edge driver events.
- Fix colorTemperature rounding inconsistencies
- Add Particulate Matter 1 constants for Z-Wave Multilevel Sensor Command Class

**NOTE**

Anyone who participated in the previous beta (0.40.x) is automatically signed up for this one.

If you’d like to participate in the beta, but haven’t taken the survey yet: [Sign Up Here](https://goo.gl/Gw4cEK)

If you’d like to opt-out, update your preferences via the [Account Settings](https://smartthings.centercode.com/user/general.html) menu item in [Centercode](https://smartthings.centercode.com/)

---

<div class="post-metadata">

**Author:** ![Mariano\_Colmenarejo](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/mariano_colmenarejo/32/220132_2.png) [@Mariano\_Colmenarejo](https://community.smartthings.com/u/Mariano_Colmenarejo)\
**Post date:** [January 12, 2022, 8:09pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/2 "2022-01-12T20:09:18Z")

</div>

> [@alissa.dornbos](#):
>
> Allow usage of the `"visibility"` field for edge driver events.

Will there be information on how to use this option?  
I’m looking for it in the documentation and I don’t see anything

---

<div class="post-metadata">

**Author:** ![TAustin](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/taustin/32/45058_2.png) [@TAustin](https://community.smartthings.com/u/TAustin)\
**Post date:** [January 13, 2022, 6:05am UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/3 "2022-01-13T06:05:36Z")

</div>

I see nothing regarding the cosock problems causing random fatal errors and crashed driver updates. I’ve had 000.041.00006 for a week or so and I’m still seeing these issues. Drivers sometimes hang when updating and the hub either has to be rebooted or the driver deleted and reinstalled.

Or is that what you are referring to with this bullet:?

> [@alissa.dornbos](#):
>
> Bugfix for stale tcp socket connects timing out and killing the driver process

---

<div class="post-metadata">

**Author:** ![carter.swedal](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/carter.swedal/32/128696_2.png) [@carter.swedal](https://community.smartthings.com/u/carter.swedal)\
**Post date:** [January 14, 2022, 3:37pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/4 "2022-01-14T15:37:04Z")

</div>

> I see nothing regarding the cosock problems causing random fatal errors and crashed driver updates.

Are you referring to the issue you mentioned [here](https://community.smartthings.com/t/st-edge-driver-lifecycle-inquiries/230733/33)?

> Bugfix for stale tcp socket connects timing out and killing the driver process

This release note is referring to a bug we found while investigating a different [issue](https://community.smartthings.com/t/st-edge-fatal-error-from-socket-http/233260) that you brought to our attention. This should be fully mitigated now.

---

<div class="post-metadata">

**Author:** ![TAustin](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/taustin/32/45058_2.png) [@TAustin](https://community.smartthings.com/u/TAustin)\
**Post date:** [January 14, 2022, 5:39pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/5 "2022-01-14T17:39:07Z")

</div>

> [@carter.swedal](#):
>
> Are you referring to the issue you mentioned [here](https://community.smartthings.com/t/st-edge-driver-lifecycle-inquiries/230733/33)?

Yes. I see this problem quite regularly.

> [@carter.swedal](#):
>
> This should be fully mitigated now.

I [reported to Nayely](https://community.smartthings.com/t/st-edge-fatal-error-from-socket-http/233260/12) that this is not the quite case, although I see this problem rarely.

---

<div class="post-metadata">

**Author:** ![iquix](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/iquix/32/136495_2.png) [@iquix](https://community.smartthings.com/u/iquix)\
**Post date:** [January 18, 2022, 1:32am UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/6 "2022-01-18T01:32:57Z")

</div>

Will **cosock** error in **“zigbee”** Edge driver be fixed too?

> [@SmartThings Edge Developer Beta | Known Issues and Bug Tracking](https://community.smartthings.com/t/smartthings-edge-developer-beta-known-issues-and-bug-tracking/230389/27):
>
> I have a issue The Edge driver that I’ve been using for almost about a month, suddenly stopped working, so I tried removing the device and pairing the device again, but I got following Error message while pairing. In the error message, it says “this is a bug, please report it”, so I’m reporting the error here. 2021-09-22T04:07:42.754700397+00:00 TRACE Tuya Window Shade Setup driver tuya-window-shade with lifecycle handlers: DeviceLifecycleDispatcher: tuya-window-shade default\_handlers: added: doConfigure: infoChanged: removed: driverSwitched: init: child\_dispatchers: 2021-09-22T04:07:42.760208189+00:00 TRACE Tuya Window Shade Setup driver tuya-window-shade with Capability handlers: CapabilityCommandDispatcher: tuya-window-shade default\_handlers: swit…

@erickv mentioned that this will be fixed in version 0.41, but it’s not listed in release notes.

> [@SmartThings Edge Developer Beta | Known Issues and Bug Tracking](https://community.smartthings.com/t/smartthings-edge-developer-beta-known-issues-and-bug-tracking/230389/64):
>
> Hey guys, just a quick update… the fix will be pushed in the 0.41 firmware version.

Is this same problem with the release note about stale tcp socket?

> [@alissa.dornbos](#):
>
> Bugfix for stale tcp socket connects timing out and killing the driver process

---

<div class="post-metadata">

**Author:** ![erickv](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/erickv/32/230792_2.png) [@erickv](https://community.smartthings.com/u/erickv)\
**Post date:** [January 18, 2022, 3:37am UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/7 "2022-01-18T03:37:26Z")

</div>

I believe @nayelyz or @andresg will be able to confirm if this issue got addressed as we got informed back then.

---

<div class="post-metadata">

**Author:** ![TAustin](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/taustin/32/45058_2.png) [@TAustin](https://community.smartthings.com/u/TAustin)\
**Post date:** [January 19, 2022, 9:31pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/8 "2022-01-19T21:31:39Z")

</div>

I can confirm that it has not. Two biggest problems with the platform at the moment for me are:

1. Hung driver re-installs
2. When driver does proceed with re-install it, driver starts, does some initialization (which includes creating a server socket and doing some http calls), then crashes with the infamous cosock error. Then tries to restart again, then cosock error, etc. ad infinitum

> FATAL Shelly Device Driver V1 Lua: runtime error: [string “cosock.lua”]:296: cosock tried to call socket.select with no sockets and no timeout. this is a bug, please report it

---

<div class="post-metadata">

**Author:** ![TAustin](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/taustin/32/45058_2.png) [@TAustin](https://community.smartthings.com/u/TAustin)\
**Post date:** [January 20, 2022, 5:21am UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/9 "2022-01-20T05:21:48Z")

</div>

Since I’m in complainer-mode, I’ll add a few more issues not addressed in this firmware update, but that have been reported before:

1. Erroneous timer warning messages:

> WARN Shelly Device Driver V1 failed to cancel dropped timer, timer has leaked Invalid timer ID

This was acknowledged as a bug by Patrick Barrett when he was still here in [this topic post](https://community.smartthings.com/t/st-edge-call-with-delay-error-messages/232959/2)

1. List display types still show values in random order in the mobile app (at least in iOS)

2. Occasional cases where dashboard states aren’t showing the correct value. The details screen always does. Sometimes it fixes itself, but other times state values seem to get ‘stuck’ on the dashboard.

3. Random cases where capability attribute emits are dropped or ignored; i.e. the device attribute doesn’t get updated

4. Handling of closed connections: if the sender of a TCP (HTTP) message immediately closes the connection after sending to the hub (which some devices do to conserve battery or simply because they are poorly written), when the driver does a **getpeername** in the channel handler immediately after accepting the connection, it can get an error and the driver is unable to know who sent the message (even though the driver can proceed and receive the message itself). This may not be a bug per-se, but there needs to be something done to preserve the IP:port of the sender so that the driver (server) knows who the message is from. There isn’t always going to be self-identifying information in the HTTP headers or endpoint. Again, this is something I had discussed with Patrick but I know he didn’t got around to addressing it.

5. Unknown if fixed: during custom capability initialization it was sometimes necessary to reboot the hub to fix an ‘unknown capability’ error. The workaround recommended was to use the 'build\_cap\_from\_json" method. Not clear if we should continue to do that or it is safe to switch back to the other (simpler) way?

On the plus side there have been some improvements, and I especially appreciate the fixing of the duplicate lifecycle calls to the driver when preference settings were changed. (That was a killer!)

---

<div class="post-metadata">

**Author:** ![nayelyz](https://avatars.discourse-cdn.com/v4/letter/n/59ef9b/32.png) [@nayelyz](https://community.smartthings.com/u/nayelyz)\
**Post date:** [January 20, 2022, 4:56pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/10 "2022-01-20T16:56:12Z")

</div>

> [@TAustin](#):
>
> 1. List display types still show values in random order in the mobile app (at least in iOS)
> 2. Occasional cases where dashboard states aren’t showing the correct value. The details screen always does. Sometimes it fixes itself, but other times state values seem to get ‘stuck’ on the dashboard.

1. By “List display types”, do you mean in a custom capability, correct?
2. Does this happen only with custom capabilities? Your description made me think of an issue reported that is related to the alternatives in the dashboard view. When we define certain alternatives in `dashboard.states` and assign a different value to the attribute, the status is not “updated” in this view.

_Note: This kind of issues are not related to the Hub’s firmware update, if you like, we can discuss them in a new thread_

> [@TAustin](#):
>
> Unknown if fixed: during custom capability initialization it was sometimes necessary to reboot the hub to fix an ‘unknown capability’ error. The workaround recommended was to use the 'build\_cap\_from\_json" method. Not clear if we should continue to do that or it is safe to switch back to the other (simpler) way?

About this issue, the `build_cap_from_json` is no longer necessary, I’ve been working with custom capabilities and you only need to make reference to them like:

```auto
local issueWRange = capabilities["commonsmall09402.issueWRange"]

```

No reboot and no extra files (capability definition or presentation) needed.

---

<div class="post-metadata">

**Author:** ![TAustin](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/taustin/32/45058_2.png) [@TAustin](https://community.smartthings.com/u/TAustin)\
**Post date:** [January 20, 2022, 5:58pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/11 "2022-01-20T17:58:08Z")

</div>

> [@nayelyz](#):
>
> By “List display types”, do you mean in a custom capability, correct?

Yes. I have a theory that I haven’t yet tested that perhaps not having a defined VID in the metadata may be causing this. I have other custom capabilities that do show correct order but they have a VID.

> [@nayelyz](#):
>
> `build_cap_from_json` is no longer necessary,

Great news! This will definitely simplify code a bit 👍🏼 Thank you.

---

<div class="post-metadata">

**Author:** ![philh30](https://avatars.discourse-cdn.com/v4/letter/p/41988e/32.png) [@philh30](https://community.smartthings.com/u/philh30)\
**Post date:** [January 21, 2022, 5:18pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/12 "2022-01-21T17:18:06Z")

</div>

> [@TAustin](#):
>
> I have a theory that I haven’t yet tested that perhaps not having a defined VID in the metadata may be causing this. I have other custom capabilities that do show correct order but they have a VID.

I haven’t found that VID matters. I see the random list order no matter what. I don’t think it’s actually random though - I think the keys are being reduced to a value and then sorted. I’ve managed to get list items in the right order by setting keys to numerical strings (“100”,“101”,…).

---

<div class="post-metadata">

**Author:** ![alissa.dornbos](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/alissa.dornbos/32/144050_2.png) [@alissa.dornbos](https://community.smartthings.com/u/alissa.dornbos)\
**Post date:** [January 25, 2022, 3:48pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/13 "2022-01-25T15:48:03Z")

</div>

Hello we are planning another Beta release for 41, see below… thanks!

# Release Notes: Hub Firmware 0.41.7

## Hub Target

- Samsung SmartThings Hub 2015 (Hub v2)
- Samsung SmartThings Hub 2018 (Hub v3)

## Release Date

- **Release Date:** 25 January 2021

## Release Notes

### Edge Drivers

- Fixed a bug where updating a crashing driver could sometimes lead to a driver becoming stuck in an unrecoverable loop
- Fix an issue with Zigbee-backed edge drivers sometimes failing to configure in a rejoin situation (e.g. after factory reset)

---

<div class="post-metadata">

**Author:** ![Mariano\_Colmenarejo](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/mariano_colmenarejo/32/220132_2.png) [@Mariano\_Colmenarejo](https://community.smartthings.com/u/Mariano_Colmenarejo)\
**Post date:** [January 25, 2022, 4:47pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/14 "2022-01-25T16:47:21Z")

</div>

> [@alissa.dornbos](#):
>
> Hello we are planning another Beta release for 41, see below… thanks!

When will the edge libraries of firmware 041.x be available?

[APIv0 Hub Release 40.X](https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/releases/tag/apiv0_40)

---

<div class="post-metadata">

**Author:** ![Zach\_Varberg](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/zach_varberg/32/62514_2.png) [@Zach\_Varberg](https://community.smartthings.com/u/Zach_Varberg)\
**Post date:** [January 26, 2022, 7:23pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/15 "2022-01-26T19:23:19Z")

</div>

> [@Mariano\_Colmenarejo](#):
>
> When will the edge libraries of firmware 041.x be available?

Sorry about the slow release, I was waiting to make sure everything was finalized. I’ve made the release of the lua libraries for [0.41.X](https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/releases/tag/apiv0_41).

---

<div class="post-metadata">

**Author:** ![alissa.dornbos](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/alissa.dornbos/32/144050_2.png) [@alissa.dornbos](https://community.smartthings.com/u/alissa.dornbos)\
**Post date:** [January 28, 2022, 6:28pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/16 "2022-01-28T18:28:48Z")

</div>

Hello again community.

We are releasing another minor version of 41.8, before the upcoming full production release. Thank you for your continued support.

## Hub Target 0.41.8

- Samsung SmartThings Hub 2015 (Hub v2)
- Samsung SmartThings Hub 2018 (Hub v3)

## Release Date

- **Release Date:** 28 January 2021

## Release Notes

- Various fixes and improvements

---

<div class="post-metadata">

**Author:** ![Mariano\_Colmenarejo](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/mariano_colmenarejo/32/220132_2.png) [@Mariano\_Colmenarejo](https://community.smartthings.com/u/Mariano_Colmenarejo)\
**Post date:** [January 28, 2022, 10:04pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/17 "2022-01-28T22:04:29Z")

</div>

> [@Zach\_Varberg](#):
>
> Sorry about the slow release, I was waiting to make sure everything was finalized. I’ve made the release of the lua libraries for [0.41.X](https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/releases/tag/apiv0_41).

I have seen that in the illuminance defaults of v 041.x there is still no default reporting interval configuration.

I don’t know if they are really in the Hub, but I have the drivers since v040.x with the reports configuration manually in the installation, because if I don’t do it, the illuminance capability doesn’t work.

I do not want to remove it, if it is still necessary because it is not in the defult libraries that you have published from firmware 041.x

Thanks

```auto
-- Copyright 2021 SmartThings
--
-- Licensed under the Apache License, Version 2.0 (the "License");
-- you may not use this file except in compliance with the License.
-- You may obtain a copy of the License at
--
-- http://www.apache.org/licenses/LICENSE-2.0
--
-- Unless required by applicable law or agreed to in writing, software
-- distributed under the License is distributed on an "AS IS" BASIS,
-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-- See the License for the specific language governing permissions and
-- limitations under the License.
local zcl_clusters = require "st.zigbee.zcl.clusters"
local capabilities = require "st.capabilities"

--- @class st.zigbee.defaults.illuminanceMeasurement
--- @field public zigbee_handlers table
--- @field public attribute_configurations table
--- @field public capability_handlers table
local illuminance_measurement_defaults = {}

--- Default handler for illuminance attribute on the illuminance measurement cluster
---
--- This converts the Uint16 value to IlluminanceMeasurement.illuminance in lux
--- Based on formula described in ZCL reference - MeasuredValue = 10,000 x log10 Illuminance + 1
---
--- @param driver Driver The current driver running containing necessary context for execution
--- @param device st.zigbee.Device The device this message was received from containing identifying information
--- @param value st.zigbee.data_types.Uint16 the value of the illuminance attribute on the illuminance measurement cluster
--- @param zb_rx st.zigbee.ZigbeeMessageRx the full message this report came in
function illuminance_measurement_defaults.illuminance_attr_handler(driver, device, value, zb_rx)
  local lux_value = math.floor(math.pow(10, (value.value - 1) / 10000))
  device:emit_event_for_endpoint(zb_rx.address_header.src_endpoint.value, capabilities.illuminanceMeasurement.illuminance(lux_value))
end

illuminance_measurement_defaults.zigbee_handlers = {
  global = {},
  cluster = {},
  attr = {
    [zcl_clusters.IlluminanceMeasurement] = {
      [zcl_clusters.IlluminanceMeasurement.attributes.MeasuredValue] = illuminance_measurement_defaults.illuminance_attr_handler,
    }
  }
}

illuminance_measurement_defaults.capability_handlers = {}

return illuminance_measurement_defaults

```

---

<div class="post-metadata">

**Author:** ![RBoy](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/rboy/32/62677_2.png) [@RBoy](https://community.smartthings.com/u/RBoy)\
**Post date:** [January 28, 2022, 11:36pm UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/18 "2022-01-28T23:36:44Z")

</div>

You may need to add this to `illuminanceMeasurement_defaults.lua` after line 47:

```auto
local illuminance_measurement_configuration = {
  cluster = zcl_clusters.IlluminanceMeasurement.ID,
  attribute = zcl_clusters.IlluminanceMeasurement.attributes.MeasuredValue.ID,
  minimum_interval = 30,
  maximum_interval = 300,
  data_type = zcl_clusters.IlluminanceMeasurement.attributes.MeasuredValue.base_type
}

illuminance_measurement_defaults.default_illuminance_measurement_configuration = illuminance_measurement_configuration

illuminance_measurement_defaults.attribute_configurations = {
  illuminance_measurement_configuration
}

```

If I’m right, this should automatically be trigger the _configure\_reporting_ when the default capabilities/handlers are set.

@Zach_Varberg any thoughts?

---

<div class="post-metadata">

**Author:** ![Mariano\_Colmenarejo](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/mariano_colmenarejo/32/220132_2.png) [@Mariano\_Colmenarejo](https://community.smartthings.com/u/Mariano_Colmenarejo)\
**Post date:** [January 29, 2022, 10:54am UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/19 "2022-01-29T10:54:13Z")

</div>

@Zach_Varberg,

I have gone to use the defaults of the capability occupancy and there is a syntax error in the function of emit the event, the **&** operator seems to have some nostalgia for groovy 😉

```auto
--- Default handler for occupancy attribute on the occupancy sensing cluster
---
--- This converts the Bitmap8 value of the occupancy attribute to OccupancySensor.occupancy occupied if bit 1 is set
--- unoccupied otherwise
---
--- @param driver ZigbeeDriver The current driver running containing necessary context for execution
--- @param device st.zigbee.Device The device this message was received from containing identifying information
--- @param value st.zigbee.data_types.Bitmap8 the value of the occupancy attribute on the OccupancySensing cluster
--- @param zb_rx st.zigbee.ZigbeeMessageRx the full message this report came in
function occupancy_sensor_defaults.occupancy_attr_handler(driver, device, value, zb_rx)
  local attr = capabilities.occupancySensor.occupancy
  device:emit_event_for_endpoint(zb_rx.address_header.src_endpoint.value, ((value.value & 0x01) ~= 0) and attr.occupied() or attr.unoccupied())
end

```

---

<div class="post-metadata">

**Author:** ![orangebucket](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/orangebucket/32/81590_2.png) [@orangebucket](https://community.smartthings.com/u/orangebucket)\
**Post date:** [January 29, 2022, 11:18am UTC](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786/20 "2022-01-29T11:18:11Z")

</div>

> [@Mariano\_Colmenarejo](#):
>
> I have gone to use the defaults of the capability occupancy and there is a syntax error in the function of emit the event, the **&** operator seems to have some nostalgia for groovy 😉

What am I missing? & is the ‘bitwise and’ operator in Lua 5.3+.

[Next page](https://community.smartthings.com/t/hub-firmware-beta-0-41-x/237786.md?page=2)
