SmartThings Edge Developer Beta | Known Issues and Bug Tracking

I have no idea if this is possible and if it is the same type of problem, but as I commented in this thread when I got the errors with the restart of the hub, I think that if they put a delay for the start of the execution of the drivers after a restart of the hub, to give time for everything to be 100% operational, these problems could be solved

Well it worked, thank you

Not sure if it was the additional delay, or the syntax or the position that helped as I already tried my original code at 5s delay and that didn’t work

Thanks for the supports

1 Like

I also ended up doing this. You can’t connect within the first few seconds of driver init

2 Likes

4 posts were split to a new topic: [Custom capabilites] Issue with enum commands

A post was split to a new topic: [SmartThings Edge] Issue with the ColorTemperature default library

A post was split to a new topic: [SmartThings Edge] Issue with the device health (Zigbee)

6 posts were split to a new topic: [SmartThings Edge] Issue with default function to send Z-Wave configuration parameters

There is a null check that is missing in st/dispatcher.lua

function MessageDispatcher:dispatch(driver, device, ...)
  if self:can_handle(driver, device, ...) then
    local status, value = pcall(inner_dispatch, self, driver, device, ...)
    if not status then
      if self.error_handler ~= nil then
        self.error_handler(driver, device, ...)
      else
        local args = {...}
        local error_msg = string.format(
            "Error encountered while processing event for %s:\n",
            tostring(device)
        )
        for i, arg in ipairs(args) do
          local arg_str = string.format("    arg%d: %s\n", i, tostring(arg))
          error_msg = error_msg .. arg_str
        end
        error_msg  = error_msg .. value -- <-- NULL CHECK for value needed
        error(error_msg)
      end
    end
  elseif self.fallback_handler ~= nil then
    self.fallback_handler(driver, device, ...)
  end
end

I am currently seeing a crash due to this error_msg construction. There is no value in my error

Can you share the implementation that is causing this error, and also the related log, please?

I can’t since I moved on from it, but it was originally being triggered by parsing an invalid json string that had been truncated. I switched from dkjson to st.json and this error started occurring when I tried to decode a bad json string. I believe it can be duplicated by calling json.decode(truncatedJsonString)

@nayelyz Created a new edge bug thread here for the v43 rollout [ST Edge] v43 Http Socket Timeout

Hi @nayelyz
I don’t know the reason why in the preferences that are of type "enumeration" the text of the description field in the app is not shown:

preferences:
  - name: "restoreState"
    title: "restore state"
    description: "This parameter 16 determines if the device will return to state prior to the power failure after power is restored"
    required: false
    preferenceType: enumeration
    definition:
      options:
        0: "power off after power failure"
        1: "restore state"
      default: 1

In the numeric type preferences if it is displayed correctly

  - name: "autoOffTime"
    title: "Auto Off Time"
    description: "This parameter 4 determines 0- 65535 (0 s to 6553,5 s) Time period for auto off, in miliseconds"
    required: false
    preferenceType: number
    definition:
      minimum: 0
      maximum: 65535
      default: 0

Thanks

2 Likes

Hi, @Mariano_Colmenarejo. Thank you for sharing this info. I’ll report this issue to the team.

1 Like

Possible new issue I am seeing. On a few occasions last week, I saw drivers disappear from logcat. I was leaving it running to watch device logs. At some point, the logs stopped. I attempted to restart logcat for the hub, and the driver was no longer listed among the other edge drivers. This occurred with more than one driver. The drivers did not return after waiting for a few hours to ensure it was not intermittent. The driver was still functional (verified through automations and device control), but was not showing in logcat. I had to reinstall the driver to get it to show up again.

Thank you for sharing your experience. We haven’t been able to replicate it but we’ll keep monitoring it.
Also, the engineering team is now aware of it so they can check what could be causing it.

1 Like

A post was split to a new topic: Issue with mediaPreset capability

Moved to the correct forum. :slight_smile:

Issue with invites on CLI version 0.14 (testing under Windows.)

> smartthings edge:channels:invites
TypeError: Cannot read properties of undefined (reading 'flags')

the subcommand create works, but delete and revoke also fail with the same error.

On CLI V0.12 all commands work fine.

Yikes! Thanks for sharing this issue. I’ll add it to my previous report of the same error message but using “edge:drivers:installed”

I’m writing a driver for devices that do a UDP broadcast on a specific port to update listeners with their device state, so this is a need. I currently don’t see any other way to do this besides udp.setsockname. Would love to be corrected if there is indeed an alternative!