SmartThings Edge Developer Beta | Known Issues and Bug Tracking

@Mariano_Colmenarejo Yes, that is what my code does

local function device_init(driver, device)"[" .. .. "] Initializing Harmony device")
  -- mark device as online so it can be controlled from the app
  if (device.preferences.deviceaddr ~= "192.168.1.n") then
    ipAddress = device.preferences.deviceaddr
    getHarmonyHubId(device,ipAddress) --this line works fine
    connect_ws_harmony(device) --this line does not
function connect_ws_harmony(device)"connecting over websockets ip: "..ipAddress.."HubId: "..hubId)
  hello_world_driver:call_with_delay(1, function ()
  end, 'WS START TIMER')

The hubId is printed in just the hubId is what was not available when i call to configure in my driver

Yes - that is the harmony hubid, retrieved by this line which calls a function, that does a http post

The code is here, if you wanted a look SampleDrivers/init.lua at main · lrmulli/SampleDrivers · GitHub

Thanks @Mariano_Colmenarejo

Adding an additional delay (using your syntax) inside the device_init method seems to have solved it

I replaced the commented line with the following

    device.thread:call_with_delay(5, function() connect_ws_harmony(device) end)

Thank you


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

1 Like

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, ...)
        local args = {...}
        local error_msg = string.format(
            "Error encountered while processing event for %s:\n",
        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
        error_msg  = error_msg .. value -- <-- NULL CHECK for value needed
  elseif self.fallback_handler ~= nil then
    self.fallback_handler(driver, device, ...)

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:

  - 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
        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
      minimum: 0
      maximum: 65535
      default: 0


1 Like

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