LAN Edge device is not created in hub after successful discovery

shebert · October 16, 2024, 3:48pm

Hi!

A few years ago, I developed an EDGE driver to control my security system from the LAN. It has been working well all this time. Recently, I made some changes to the code to improve certain aspects. However, the code related to the discovery or creation of the device was not modified.

I decided to retest the integration and reinstall it in my hub. It didn’t go as planned.

When I tried to remove the device or uninstall the driver using smartthings/cli, I received the following axios error: Error: Request failed with status code 500: unsuccessful-http-call status=500.

So I used the web interface (Samsung account) to manually remove the device and the driver, also unsubscribing the channel.

Since then, when I try to reintegrate the device into SmartThings, it is not created. I can integrate the driver and perform the discovery, but no devices are being added, and the added or init events are no longer triggered. Here’s an example of the commands.

The discovery is called and seems to be working well, and driver:try_create_device() returns a success (1).

2024-10-16T12:26:52.189018753Z TRACE Interlogix NetworX NX-595E  Setup driver interlogix-networx-nx-595e with lifecycle handlers:
DeviceLifecycleDispatcher: interlogix-networx-nx-595e
  default_handlers:
    driverSwitched:
    init:
    removed:
    added:
  child_dispatchers:

2024-10-16T12:26:52.194871169Z TRACE Interlogix NetworX NX-595E  Setup driver interlogix-networx-nx-595e with Capability handlers:
CapabilityCommandDispatcher: interlogix-networx-nx-595e
  default_handlers:
    chime:
      chime
      off
    doorControl:
      open
      close
    refresh:
      refresh
      disarm
      armStay
      armAway
  child_dispatchers:

2024-10-16T12:26:52.217690419Z INFO Interlogix NetworX NX-595E  Created dispatcher [SecretDataDispatcher]interlogix-networx-nx-595e that had no handlers
2024-10-16T12:26:52.279856044Z TRACE Interlogix NetworX NX-595E  Setup driver interlogix-networx-nx-595e with Secret Data handlers:
SecretDataDispatcher: interlogix-networx-nx-595e
  default_handlers:
  child_dispatchers:

2024-10-16T12:26:52.294795836Z INFO Interlogix NetworX NX-595E  interlogix-networx-nx-595e driver started...
2024-10-16T12:26:52.304221045Z TRACE Interlogix NetworX NX-595E  Received event with handler driver_lifecycle
2024-10-16T12:26:52.308756128Z INFO Interlogix NetworX NX-595E  received driver startupState: {"hub_zigbee_id":"xxxx","hub_node_id":1,"hub_ipv4":"xxxx"}
2024-10-16T12:26:52.326046670Z TRACE Interlogix NetworX NX-595E  Received event with handler discovery
2024-10-16T12:26:52.356400711Z INFO Interlogix NetworX NX-595E  Starting Interlogix NetworX NX-595E Discovery
2024-10-16T12:26:52.364834878Z INFO Interlogix NetworX NX-595E  Metadata: {device_network_id="C0A8020A:0253", label="Security system", manufacturer="Simon Hebert", model="Interlogix NetworX NX-595E", profile="interlogix-networx-nx-595e.v1", type="LAN", vendor_provided_label="Alarm system"}
2024-10-16T12:26:52.376074128Z INFO Interlogix NetworX NX-595E  try_create_device success: 1
2024-10-16T12:26:52.380592211Z DEBUG Interlogix NetworX NX-595E  discovery device thread event handled
2024-10-16T12:27:49.793086468Z TRACE Interlogix NetworX NX-595E  Received event with handler discovery
2024-10-16T12:27:49.863791135Z TRACE Interlogix NetworX NX-595E  Received event with handler driver_lifecycle

Does anyone have any ideas or could help identify the issue?

I’ve tried removing everything, recreating everything, restarting the hub, and researching the topic, but nothing works.

Thank you!

Andreas_Roedl · October 16, 2024, 4:31pm

How does the driver communicate with the device? HTTP(S)-Requests? If yes, luasocket/luasec?

shebert · October 16, 2024, 5:18pm

The LAN device is a web REST API interface. Nothing has changed in this aspect since the beginning though.

cosock/socket.http is used for requests.

local cosock = require "cosock"
local http = cosock.asyncify "socket.http"

Thanks

Andreas_Roedl · October 16, 2024, 5:28pm

Do a lot of log.info() in and around your requests, especially the very first.

Start the logcat and keep it running for longer (5 minutes).

I think there’s a problem with the sockets, timing, timeouts that affects other drivers as well.

See this comment, the issues on GitHub and the code that could fix it:

github.com/SmartThingsCommunity/SmartThingsEdgeDrivers

Lunchbox (Aqara FP2 and Philips Hue): handle wantread from luasocket/luasec

opened 12:04AM - 30 Sep 24 UTC

ldeora

The wantread message indicates that the socket is not ready to read data yet and… the operation should be retried later. This happens when you're trying to read data from a socket, but the data isn't available at that moment. This is a proposal for a fix for the Aqara FP2 issue #1648 . Add a new function in rest.lua to check if the socket is ready for reading ``` local function wait_for_read(socket, timeout) -- Use socket.select to check if the socket is ready for reading local ready_sockets, _, _ = socket.select({socket}, nil, timeout) return #ready_sockets > 0 -- Returns true if the socket is ready to read end ``` And use it here: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/7821a5d168d89fb449391a584a3566c605389265/drivers/SmartThings/philips-hue/src/lunchbox/rest.lua#L106-L108 https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/7821a5d168d89fb449391a584a3566c605389265/drivers/Aqara/aqara-presence-sensor/src/lunchbox/rest.lua#L104-L106 ``` if wait_for_read(sock, 1) then next_recv, next_err, partial = sock:receive(pat) else -- No data is ready, sleep for a bit socket.sleep(0.1) end ``` Additionally handle wantread here by waiting and trying again: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/7821a5d168d89fb449391a584a3566c605389265/drivers/SmartThings/philips-hue/src/lunchbox/rest.lua#L109-L120 https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/7821a5d168d89fb449391a584a3566c605389265/drivers/Aqara/aqara-presence-sensor/src/lunchbox/rest.lua#L107-L118 ``` if next_err ~= nil then if string.lower(next_err) == "closed" then if partial ~= nil and #partial >= 1 then full_response:append_body(partial) next_chunk_bytes = 0 else return nil, next_err end elseif string.lower(next_err) == "wantread" then -- Wait and try again if socket is not ready yet socket.sleep(0.1) else return nil, ("unexpected error reading chunked transfer: " .. next_err) end end ``` Sorry for the formatting...

github.com/SmartThingsCommunity/SmartThingsEdgeDrivers

Aqara FP2: adding device doesn't work anymore

opened 01:04PM - 25 Sep 24 UTC

ldeora

Edit: there's the problem: ``` 2024-09-27T22:47:45.440063966Z ERROR Aqara Pr…esence Sensor get_credential : ip = 192.168.1.121, failed to get token, error = wantread 2024-09-27T22:47:45.445295882Z WARN Aqara Presence Sensor credential is nil 2024-09-27T22:47:45.450356841Z ERROR Aqara Presence Sensor failed to get credential. dni= 54:EF:44:5C:4C:98, ip= 192.168.1.121 ``` Can't add the device anymore! Removed the device, deleted the driver, added driver, tried to add the device. Tried it with main, beta, and PR channel to make sure. It worked about a month ago. Since then, changes were made to *discovery.lua*, *init.lua*, *device_manager.lua*... Can someone please check if adding the device still works? Device firmware: 1.2.7_0011.0080 Hub firmware: 000.053.00019 ST app (Android): 1.8.18.21 Device works with the Aqara Home app. This is the complete log and it looks like the driver lifecycle ends? ``` 2024-09-25T10:34:03.597153457Z TRACE Aqara Presence Sensor Setup driver aqara-fp2 with lifecycle handlers: DeviceLifecycleDispatcher: aqara-fp2 default_handlers: infoChanged: added: init: removed: driverSwitched: child_dispatchers: 2024-09-25T10:34:03.609944082Z TRACE Aqara Presence Sensor Setup driver aqara-fp2 with Capability handlers: CapabilityCommandDispatcher: aqara-fp2 default_handlers: refresh: refresh multipleZonePresence: createZone deleteZone updateZoneName child_dispatchers: 2024-09-25T10:34:03.616156957Z INFO Aqara Presence Sensor Created dispatcher [SecretDataDispatcher]aqara-fp2 that had no handlers 2024-09-25T10:34:03.628525582Z TRACE Aqara Presence Sensor Setup driver aqara-fp2 with Secret Data handlers: SecretDataDispatcher: aqara-fp2 default_handlers: child_dispatchers: 2024-09-25T10:34:03.686260707Z TRACE Aqara Presence Sensor Received event with handler driver_lifecycle 2024-09-25T10:34:03.707111916Z INFO Aqara Presence Sensor received driver startupState: {"hub_zigbee_id":"KG2XAAILh00=","hub_node_id":1,"hub_ipv4":"192.168.1.116"} 2024-09-25T10:34:03.712373791Z TRACE Aqara Presence Sensor Received event with handler discovery 2024-09-25T10:34:03.718594541Z INFO Aqara Presence Sensor discovery_mdns.find_device_ips 2024-09-25T10:34:04.889382333Z INFO Aqara Presence Sensor found_name = _Aqara-FP2._tcp 2024-09-25T10:34:04.941494333Z INFO Aqara Presence Sensor ip = 192.168.1.109 2024-09-25T10:34:04.959243583Z INFO Aqara Presence Sensor found_name = _Aqara-FP2._tcp 2024-09-25T10:34:04.972437916Z INFO Aqara Presence Sensor ip = 192.168.1.109 2024-09-25T10:34:05.017133958Z TRACE Aqara Presence Sensor unknown dni= 54:EF:44:5C:4C:98, ip= 192.168.1.109 2024-09-25T10:34:05.041282958Z TRACE Aqara Presence Sensor try_add_device : dni= 54:EF:44:5C:4C:98, ip= 192.168.1.109 2024-09-25T10:34:05.075223208Z INFO Aqara Presence Sensor 54:EF:44:5C:4C:98 Creating TCP socket for REST Connection 2024-09-25T10:34:05.097121666Z INFO Aqara Presence Sensor 54:EF:44:5C:4C:98 Setting TCP socket timeout for REST Connection 2024-09-25T10:34:05.118858583Z INFO Aqara Presence Sensor 54:EF:44:5C:4C:98 Connecting TCP socket for REST Connection 2024-09-25T10:34:05.394824874Z INFO Aqara Presence Sensor 54:EF:44:5C:4C:98 Set Keepalive for TCP socket for REST Connection 2024-09-25T10:34:05.408426249Z INFO Aqara Presence Sensor 54:EF:44:5C:4C:98 Creating SSL wrapper for for REST Connection 2024-09-25T10:34:05.423615083Z INFO Aqara Presence Sensor 54:EF:44:5C:4C:98 Performing SSL handshake for for REST Connection 2024-09-25T10:34:07.962791666Z INFO Aqara Presence Sensor 54:EF:44:5C:4C:98 Successfully created TCP connection 2024-09-25T10:35:02.506882839Z TRACE Aqara Presence Sensor Received event with handler discovery 2024-09-25T10:35:02.574833131Z TRACE Aqara Presence Sensor Received event with handler driver_lifecycle ```

github.com/SmartThingsCommunity/SmartThingsEdgeDrivers

alternative source for aqara fp2

SmartThingsCommunity:main ← FreeMasen:fix/retry-source

opened 05:29PM - 30 Sep 24 UTC

FreeMasen

+46 -1

Check all that apply # Type of Change - [ ] WWST Certification Request … - If this is your first time contributing code: - [ ] I have reviewed the README.md file - [ ] I have reviewed the CODE_OF_CONDUCT.md file - [ ] I have signed the CLA - [ ] I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com - [ ] Bug fix - [ ] New feature - [ ] Refactor # Checklist - [ ] I have performed a self-review of my code - [ ] I have commented my code in hard-to-understand areas - [ ] I have verified my changes by testing with a device or have communicated a plan for testing - [ ] I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior # Description of Change # Summary of Completed Tests

orangebucket · October 16, 2024, 7:05pm

That looks odd to me, in that securitySystem capability commands without default handlers are listed as if they are part of the default handler for the refresh capability.

I haven’t seen the driver start up sequence for a while though so maybe looking odd is perfectly correct.

shebert · October 17, 2024, 1:45pm

Thank you for your response.

What bothers me a bit is that this code (sockets) isn’t executed until the device is initialized, and added/init hasn’t been called yet when the discovery ends because the device isn’t added to the hub.

Since my code hasn’t been modified in this regard, I think this issue comes from the SmartThings platform configuration because, despite all the debugging I’ve done, it doesn’t point to the code. The removal of an old Edge/LAN device that caused 500 errors with smartthings/cli makes me suspect this.

shebert · October 17, 2024, 1:52pm

You’re right that the capability commands are very strange and don’t represent what’s declared in the code and in the profile file, I hadn’t noticed that. This points even more to a SmartThings platform configuration issue.

I simply recompiled/reinstalled the same driver code last night, and the problem mysteriously disappeared since then. I had done that many times the previous day without success. I also changed the device_network_id once again, but I had tried that before as well.

I think the old driver or the previous device was still ‘stuck’ somewhere. Now it’s working, at least for the moment.

Thank you all for your quick and helpful responses!

Topic		Replies	Views
SmartThings Edge Developer Beta \| Known Issues and Bug Tracking Support edge-device	139	12767	December 12, 2022
Try_create_device: though device may be "added", not always "init"ed Writing Edge Drivers	29	2398	March 27, 2024
Debug \| Creating Drivers for LAN Devices with SmartThings Edge Writing Edge Drivers esp8266	16	2233	February 6, 2023
Hub does not support edge drivers? Writing Edge Drivers	176	10880	January 16, 2025
SmartThings CLI: LAN Driver Logs Disappeared (Hub Discovery Not Triggering) Developer Programs	62	2937	April 23, 2024

LAN Edge device is not created in hub after successful discovery

Related topics