6 posts were split to a new topic: [ST Edge] Use Momentary capability in Dashboard View
Hey Andrew, unfortunately it’s basically impossible for us to detect that something like this has happened. In Lua variables always evaluate to nil unless previously assigned to and values in a table always evaluate to nil unless assigned to. So what you’d be accidentally doing there would be assigning the init field to nil which it implicitly already was. Then when the Driver library looks at this table it just sees that init is nil, which is a valid value because handlers are optional.
I would suggest using Luacheck to detect cases like this: GitHub - mpeterv/luacheck: A tool for linting and static analysis of Lua code.
Using that and unit tests it you should be able to catch just about any typo issues.
2 Likes
it would be awesome if this tool become a part of the pipeline.
as I am not planning to invest in lua skills anymore.
Overall, using a niche interpreted language for device drivers is an odd choice.
A post was split to a new topic: [Device UI] Capabilities show “checking status…” in the dashboard view
A post was split to a new topic: [ST Edge] Error packaging the driver with a different profile
2 posts were split to a new topic: [ST Edge] - Fatal error from socket.http
6 posts were split to a new topic: [ST Edge] IKEA and Sonoff devices go offline due to inactivity
2 posts were split to a new topic: [ST Edge] Issues with infoChanged lifecycle
Hi - did you ever get a resolution to this problem? I am seeing it repeatedly now in a LAN Driver that does a lot of HTTP and UDP socket communications. It causes the driver to restart, and it can happen multiple times sequentially.
Lua: runtime error: [string "cosock"]:296: cosock tried to call socket.select with no sockets and no timeout. this is a bug, please report it
For LAN drivers, I frequently see cases where, in a device add or init lifecycle handler, emit_events to update device attributes, or device:online() or device:offline() calls are ignored. The calls appear as expected in the log, and no errors are shown, but the device state doesn’t update.
I’m still waiting for the progress for this problem.
@erickv is working on this with engineers in ST.
1 Like
To follow up on offline/online commands: there seem to be problems with these on iOS. When I can get an offline command to do something, the device dashboard will show an ‘offline’ state string at the bottom of the card. But if I tap on the device to go into details view - all fields are still active and when I return to dashboard, the ‘offline’ message is gone.
Perhaps I could use some clarity on what is intended with this command. In other drivers, I have used it and when you set a device to offline, it gets the cloud with the slash across it on the dashboard, and everything is greyed out and disabled on the details screen. That is what I was expecting, but not what I’m seeing on iOS. I much prefer everything to be disabled on the details screen, because otherwise, I have to include code in all my command handlers to properly ignore input whenever the device is supposed to be offline.
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
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!
2 Likes
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.
2 Likes
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