SmartThings Edge Developer Beta | Known Issues and Bug Tracking

3 posts were merged into an existing topic: Send a fixed command

I was hitting that error at one point and traced it to a device init function that was opening an HTTP socket while the socket from the prior init run was still open. Checking for the open socket and either closing it or reusing it resolved the error in my case.

1 Like

@iquix @TAustin

Fortunately, our team has been able to identify the issue and they keep progressing on the resolution of it.

So, as soon as I get more info, I’ll let you know guys!


Not sure I follow you: are you using socket.http? Aren’t http sockets auto-opened and closed or were you creating/using your own TCP sockets? In any case, I absolutely have to be able to have multiple sockets open concurrently (HTTP, TCP, UDP, etc). You can’t control how the platform swaps your execution in and out, so this definitely has to be fixed.

I encountered that error while building off of the server in the lightbulb-lan-esp8266 example. Calling hub_server.start a second time seemed to be what tripped it, unless I first killed the previous instance. I’m just a monkey pulling levers right now when it comes to LAN integrations, so not sure if this applies to what you’re trying to do.

1 Like

Hey guys, just a quick update… the fix will be pushed in the 0.41 firmware version.


A post was split to a new topic: [ST Edge] Issues with Temperature capabilities on Z-Wave devices

A post was split to a new topic: [ST Edge] Issues with the call_with_delay function

Eric - will this error be addressed as well in the firmware update?:

runtime error: [string "socket"]:205: received data on non-existent socket: tcp_send_ready

Can you say when this firmware update will be pushed out?


When a Hub reboots or turns off, the value of the variables of each device in the driver, stored in permanent memory, they are recovered when the Hub comes back online.
However, the timers stop, I don’t know if they are canceled, but when the hub is back online Timers are not executed and must be initialized again.

Is this the default behavior or is it a bug?


1 Like

Let me verify with the engineering team. I’ll be back in a moment.

Yes, it is normal behavior. If the Hub is restarted, all the timers will be destroyed.


I don’t know if it’s really necessary, but I’ve gotten into the habit in my drivers of when I know the info_changed lifecycle is called because of a driver restart, I cancel all my timers, as well as shut down anything else that may be left hanging, like open sockets and such. Hopefully when the proper driver restart lifecycle gets implemented I’ll be able to move that ‘shutdown’ type of code over to that handler.

1 Like

Lifecycle infoChanged is called for various reasons, even cyclically every 1 hour.
How do you recognize if infoCanged is called due to a reboot hub?

The problem is when you don’t want a timer to stop with the restart or reboot the hub, for example so that a thermostat continues to work where it was when it is back online.

Obviously, all device states are stored in permanent memory and are automatically retrieved.

But, sometimes when initializing the driver we initialize values for custom capabilities and some variables so that it begins to work as we want and perhaps we should differentiate if it is initialized by a new installation, driver change (life cycle, handler driver_switched) or by hub reboot

It’s just a temporary measure until driverSwitched is implemented, but when I see an info_changed come in that doesn’t have any of my preferences that have changed, or any other standard attribute that hasn’t changed, I assume it’s a driver restart. That may be dangerous, I know, but seems to be accurate the majority of the time.

Once the driverSwitched lifecycle is implemented, you’d probably have to somehow save the state of your timers, if that’s possible. (I wonder if you can find out what’s left on a timer?..) But yes, I usually have unique code based on if the device has just been created vs. (re) initialized.

I am using theSwitched lifecycle driver to execute the device configuration when switching to a driver that needs a specific report configuration to work and the device could have custom configurations in the previous driver, for example a temperature sensor that is paired to a thermostat needs to make sure it is set to maximum accuracy.

A post was split to a new topic: [ST Edge] Integrating Z-Wave sensor device

See the post I just made in the Lifecycle topic. I think we all misunderstood the driverSwitched lifecycle: it looks like it’s only for when devices get moved from one driver to another, not when a driver gets an update.

A post was split to a new topic: [ST Edge] Issues with the channel invitation web UI

A post was split to a new topic: [ST Edge] Issues with the driver “Z-Wave Button”

Do you plan on adding a Live Logging feature that end users can see without having to setup the CLI?

You’re asking users to submit their hub logs when they report a problem, but users can’t provide anything to community developers which makes troubleshooting extremely difficult…