Will we have an edge lan driver to control wled?

I believe it is possible. I don’t know if auto-discovery could be supported as these bulbs don’t use the standard multicast port. I’d have to see if the Edge platform would support the port they use. If not then the IP addresses for each bulb would have to be configured by the user, which would be painful! And they’d all have to be static.

I don’t have one of these bulbs, so would have to get one first to test with.

Please find out how many other folks here would be interested in this: Post Requests for Edge Drivers Here (community-created)

@TAustin

Hello, thanks for the attention to reply!

I have a few yeelight products (first generation warm/cold white light, bedside lamp 2 and screenlight bar) and I can test them if I wanted to try developing.

As I understand it, the port they use is 55443.

About configuring manually, I don’t think it’s a problem, given the great gift of local control…

And about static IP, I think almost every router has this option these days. Here in the case practically everything is with static IP.

Is there somewhere I can get more support for this edge driver? I have tried to set it up but my led strips are not responding.

What is your settings?

Hello - Sure, @w35l3y or I can help you. Let us know what your settings are and what exactly do you see in the mobile app?

Do these help?

I from what I was reading this should be the setting.

Make sure to have:

  • API enabled in the wled settings
    • I am not finding this settings. I think this is always enabled.
  • hub ST and wled at the same network
  • unformatted and trimmed text in the Path preference
    • if you copied it, certify that you copied from somewhere that doesn’t accept formatted texts, like notepad. This is very important. Otherwise, formatting will also be copied and Path won’t work properly.

I’m having issues with the WLED driver as well. Trying to turn them on from the ST app does not work. Whatever it’s doing kills the WLED server as well, as the WLED app won’t turn on the LEDs after attempting to do it via the ST app. A WLED reboot resolves this.

The IP is accurate. I left the path at the default as per the instructions.

@TAustin

Sam issue here, can you please assist.

Hi there,

I just installed the edge driver and experiencing a few issues. I can turn on the light strip using smartthings but anytime I want to change the effect, I get a webserver error.

I was wondering what version of WLED was this driver developed for? I would like to install that version on my esp board to see if the drivers acts differently / better.

Many thanks!

I am getting the same error

Hey Guys,

I have recently started developing my own edge Driver for WLED. If youre having Problems with the other one you could try this one. Currently it only supports the basics: On/Off, Color, Brightness and refreshing. I am currently trying to get presets to work though. But until the “Scenes” Capability gets fully implementet by the Smarthings Team, the solution is probably going to be a bit janky.

If you’re Interested you can check out the driver on Github. I’ve added all instructions to use it and all current and planned features there.

2 Likes

Hi @BumBumGame,

I am interested in testing your driver because it has presets, which I use extensively. But something is not working in the discovery. It is not finfing any WLED devices. I was wondering if the discovery is run from the mobile app or from the hub itself.

The reason I am asking this question is because my hub and WLED devices are on a separate IoT VLAN on my network and my phone onto which the app is running is on another VLAN. mDNS does not cross network segments by default.

From the WLED app, I am able to add the devices one by one by typing in their IP address. So it is still usable without the auto-discovery magic of mDNS.

In the WLED driver I am currently using from @TAustin, there is the possiblity to create a WLED driver and configure the IP address manually. Unfortunately that version does not support presets which I would like to use.

Thanks!

I did further testing. I actually switched my phone to my IoT network, still no WLED discovered.

I now wonder if there might be some bad interaction between both WLED drivers I have installed simultaneously. Could someone advise on this as I’m not to keen on removing the other driver as I will loose all my existing devices and associated routines.

Thanks

Hi @KrankyFranky,

I was wondering if the discovery is run from the mobile app or from the hub itself.

The is run from the hub itself as far as I know. May I ask what WLED Firmware Version you are using? I’m asking because Aircookie added a new mDNS Servicetype which the driver is using as from 0.8.3.

Just to test if the Wleds mDNS is working at all you could connect to the same IoT Vlan as the Wled device with your Phone or a Laptop and try to connect to your Wled device using the mDNS adress in your Browser instead of the IP of the device.

In the WLED driver I am currently using from @TAustin, there is the possiblity to create a WLED driver and configure the IP address manually. Unfortunately that version does not support presets which I would like to use.

If we don’t get mDNS to work I might be able to create a second Version which can be added like @TAustin’s Driver and be configured manually. I cant promise that I will keep updating this Version though since keeping 2 Version up to date is making it pretty hard to keep the development history clean.

Have you ever worked with the Smarthhings CLI before? If yes I could guide you to get the logs of the mDNS discovery and maybe we can find an error there.

Best Regards,
BumBumGame

I now wonder if there might be some bad interaction between both WLED drivers I have installed simultaneously. Could someone advise on this as I’m not to keen on removing the other driver as I will loose all my existing devices and associated routines.

I wouldn’t say that its a bad interaction between the WLED but maybe my Driver has a problem with handeling more than one. Theres currently only one availalbe to me therfore I couldn’t test the drivers behavior with mutiple devices.

Update: Sorry I missunterstood what you meant. I thought you meant the mDNS implementation on the Wled devices. Unfortunately I don’t know if this can happen between 2 drivers.

The is run from the hub itself as far as I know. May I ask what WLED Firmware Version you are using? I’m asking because Aircookie added a new mDNS Servicetype which the driver is using as from 0.8.3.

All my WLED are running 0.13.3 the latest official version.

Just to test if the Wleds mDNS is working at all you could connect to the same IoT Vlan as the Wled device with your Phone or a Laptop and try to connect to your Wled device using the mDNS adress in your Browser instead of the IP of the device.

I will try this, although I am pretty sure it is working.

If we don’t get mDNS to work I might be able to create a second Version which can be added like @TAustin’s Driver and be configured manually. I cant promise that I will keep updating this Version though since keeping 2 Version up to date is making it pretty hard to keep the development history clean.

Thank you, but has you said, it would make things more complicated. Let me try to dig into this first, and find the cause.

Have you ever worked with the Smarthhings CLI before? If yes I could guide you to get the logs of the mDNS discovery and maybe we can find an error there.

Not yet but I am willing to try this. I’m busy for the next few days so it might take me a couple days to come back with something.

Thanks!

Ok, I finally got the CLI installed and it allowed me to figure out why no WLED devices were discovered… I had enrolled to the channel but forgot to install the driver (bang head on desk :expressionless: ). So, that is solved now. discovery seems to work but I found some problems afterwards.

WLED devices are discovered but they are not working in the app. Just to mention, because I think it is part of the problem, I have 7 WLED devices on my network. When I go in the app, and enter in a device, it tells me that the configuration is not completed yet (I don’t have the exact message because I’m running the app in French, so just translating here).

I managed to capture the log during the initial dicovery ond it seems to be looping afterwards.

2023-03-04T22:03:43.765199803+00:00 TRACE WLED W2812BStrip  Setup driver wled-rgb with lifecycle handlers:
DeviceLifecycleDispatcher: wled-rgb
  default_handlers:
    init:
    removed:
    infoChanged:
    added:
    driverSwitched:
  child_dispatchers:

2023-03-04T22:03:43.768678719+00:00 TRACE WLED W2812BStrip  Setup driver wled-rgb with Capability handlers:
CapabilityCommandDispatcher: wled-rgb
  default_handlers:
    switch:
      on
      off
    mode:
      setMode
    colorControl:
      setColor
    refresh:
      refresh
    switchLevel:
      setLevel
  child_dispatchers:

2023-03-04T22:03:43.836144386+00:00 TRACE WLED W2812BStrip  Received event with handler environment_info
2023-03-04T22:03:43.840814969+00:00 TRACE WLED W2812BStrip  Found DeviceLifecycleDispatcher handler in wled-rgb
2023-03-04T22:03:43.844518594+00:00 INFO WLED W2812BStrip  Begin init lifecycle...
2023-03-04T22:03:43.867342928+00:00 TRACE WLED W2812BStrip  Found DeviceLifecycleDispatcher handler in wled-rgb
2023-03-04T22:03:43.867940553+00:00 INFO WLED W2812BStrip  Begin init lifecycle...
2023-03-04T22:03:43.892618803+00:00 TRACE WLED W2812BStrip  Found DeviceLifecycleDispatcher handler in wled-rgb
2023-03-04T22:03:43.894735386+00:00 INFO WLED W2812BStrip  Begin init lifecycle...
2023-03-04T22:03:43.917818553+00:00 TRACE WLED W2812BStrip  Found DeviceLifecycleDispatcher handler in wled-rgb
2023-03-04T22:03:43.918421803+00:00 INFO WLED W2812BStrip  Begin init lifecycle...
2023-03-04T22:03:43.946237844+00:00 TRACE WLED W2812BStrip  Found DeviceLifecycleDispatcher handler in wled-rgb
2023-03-04T22:03:43.946804886+00:00 INFO WLED W2812BStrip  Begin init lifecycle...
2023-03-04T22:03:43.973141969+00:00 TRACE WLED W2812BStrip  Received event with handler environment_info
2023-03-04T22:03:43.973722094+00:00 DEBUG WLED W2812BStrip  Z-Wave hub node ID environment changed.
2023-03-04T22:03:43.974644053+00:00 TRACE WLED W2812BStrip  Found DeviceLifecycleDispatcher handler in wled-rgb
2023-03-04T22:03:43.977113511+00:00 INFO WLED W2812BStrip  Begin init lifecycle...
2023-03-04T22:03:44.001366511+00:00 TRACE WLED W2812BStrip  Found DeviceLifecycleDispatcher handler in wled-rgb
2023-03-04T22:03:44.001942886+00:00 INFO WLED W2812BStrip  Begin init lifecycle...
2023-03-04T22:03:44.028152428+00:00 FATAL WLED W2812BStrip  Lua: runtime error: [string "cosock/socket/internals.lua"]:106: recvr waker already set, sockets can only block one thread per waker kind
stack traceback:
	[C]: in function 'assert'
	[string "cosock/socket/internals.lua"]:106: in method 'setwaker'
	[string "cosock.lua"]:279: in field 'run'
	[string "st/driver.lua"]:764: in method 'run'
	[string "init.lua"]:39: in main chunk
Traceback:
stack traceback:
	[C]: in function 'assert'
	[string "cosock/socket/internals.lua"]:106: in method 'setwaker'
	[string "cosock.lua"]:279: in field 'run'
	[string "st/driver.lua"]:764: in method 'run'
	[string "init.lua"]:39: in main chunk

There’s this FATAL error at the end. I looks to me like some concurrency issue. I’m not a driver developper so that’s just a guess.

Next thing I did was to delete 6 out of the 7 discovered devices in order to let one of the devices finish its configuration and it worked.

I captured the log of that part

2023-03-04T22:06:55.083985453+00:00 TRACE WLED W2812BStrip  Setup driver wled-rgb with lifecycle handlers:
DeviceLifecycleDispatcher: wled-rgb
  default_handlers:
    init:
    driverSwitched:
    removed:
    added:
    infoChanged:
  child_dispatchers:

2023-03-04T22:06:55.088545786+00:00 TRACE WLED W2812BStrip  Setup driver wled-rgb with Capability handlers:
CapabilityCommandDispatcher: wled-rgb
  default_handlers:
    mode:
      setMode
    switchLevel:
      setLevel
    switch:
      on
      off
    colorControl:
      setColor
    refresh:
      refresh
  child_dispatchers:

2023-03-04T22:06:55.132999995+00:00 TRACE WLED W2812BStrip  Received event with handler environment_info
2023-03-04T22:06:55.138942120+00:00 TRACE WLED W2812BStrip  Found DeviceLifecycleDispatcher handler in wled-rgb
2023-03-04T22:06:55.140854745+00:00 INFO WLED W2812BStrip  Begin init lifecycle...
2023-03-04T22:06:55.164340536+00:00 TRACE WLED W2812BStrip  Received event with handler environment_info
2023-03-04T22:06:55.164918203+00:00 DEBUG WLED W2812BStrip  Z-Wave hub node ID environment changed.
2023-03-04T22:06:55.270475161+00:00 DEBUG WLED W2812BStrip  Multicast response received from 192.168.4.225
2023-03-04T22:06:55.356723453+00:00 DEBUG WLED W2812BStrip  PTR record: _wled._tcp.local / wled1._wled._tcp.local
2023-03-04T22:06:55.357409536+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.91
2023-03-04T22:06:55.364579578+00:00 DEBUG WLED W2812BStrip  PTR record: _wled._tcp.local / wled4._wled._tcp.local
2023-03-04T22:06:55.365161703+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.94
2023-03-04T22:06:55.371606078+00:00 DEBUG WLED W2812BStrip  PTR record: _wled._tcp.local / wled2._wled._tcp.local
2023-03-04T22:06:55.372160453+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.92
2023-03-04T22:06:55.530080370+00:00 DEBUG WLED W2812BStrip  PTR record: _wled._tcp.local / wled-97._wled._tcp.local
2023-03-04T22:06:55.530688578+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.97
2023-03-04T22:06:55.536796661+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.98
2023-03-04T22:06:55.539440328+00:00 DEBUG WLED W2812BStrip  PTR record: _wled._tcp.local / wled-17._wled._tcp.local
2023-03-04T22:06:55.626758578+00:00 DEBUG WLED W2812BStrip  PTR record: _wled._tcp.local / wled7._wled._tcp.local
2023-03-04T22:06:55.627312495+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.86
2023-03-04T22:06:55.636274911+00:00 DEBUG WLED W2812BStrip  PTR record: _wled._tcp.local / wled-6._wled._tcp.local
2023-03-04T22:06:55.636858495+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.96
2023-03-04T22:06:55.673785745+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.87
2023-03-04T22:06:55.674380870+00:00 DEBUG WLED W2812BStrip  PTR record: _wled._tcp.local / wled-16._wled._tcp.local
2023-03-04T22:06:55.681276453+00:00 INFO WLED W2812BStrip  Got ip for: [wled-16._wled._tcp.local] :192.168.4.87
2023-03-04T22:06:56.315960828+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"level","capability_id":"switchLevel","component_id":"main","state":{"value":78}}
2023-03-04T22:06:56.319932578+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"switch","capability_id":"switch","component_id":"main","state":{"value":"off"}}
2023-03-04T22:06:56.329780994+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"saturation","capability_id":"colorControl","component_id":"main","state":{"value":0}}
2023-03-04T22:06:56.338639578+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"hue","capability_id":"colorControl","component_id":"main","state":{"value":0}}
2023-03-04T22:06:56.348744453+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"supportedModes","capability_id":"mode","component_id":"main","state":{"value":["Blanc"]}}
2023-03-04T22:06:56.357758619+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"mode","capability_id":"mode","component_id":"main","state":{"value":"Blanc"}}
2023-03-04T22:06:56.495055411+00:00 DEBUG WLED W2812BStrip  Multicast response received from 192.168.4.225
2023-03-04T22:06:56.773391453+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.87
2023-03-04T22:06:57.015310869+00:00 DEBUG WLED W2812BStrip  Multicast response received from 192.168.4.225
2023-03-04T22:06:57.178953328+00:00 DEBUG WLED W2812BStrip  Unicast response received from 192.168.4.87
2023-03-04T22:06:57.185189661+00:00 INFO WLED W2812BStrip  Got ip for: [wled-16._wled._tcp.local] :192.168.4.87
2023-03-04T22:06:57.853442577+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"level","capability_id":"switchLevel","component_id":"main","state":{"value":78}}
2023-03-04T22:06:57.875821744+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"switch","capability_id":"switch","component_id":"main","state":{"value":"off"}}
2023-03-04T22:06:57.887147244+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"saturation","capability_id":"colorControl","component_id":"main","state":{"value":0}}
2023-03-04T22:06:57.896977494+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"hue","capability_id":"colorControl","component_id":"main","state":{"value":0}}
2023-03-04T22:06:57.907553119+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"supportedModes","capability_id":"mode","component_id":"main","state":{"value":["Blanc"]}}
2023-03-04T22:06:57.919458702+00:00 INFO WLED W2812BStrip  <Device: 7c08c98a-1300-4a2f-9052-f1c0f602daae (wled-16._wled._tcp.local)> emitting event: {"attribute_id":"mode","capability_id":"mode","component_id":"main","state":{"value":"Blanc"}}
2023-03-04T22:06:57.934217161+00:00 INFO WLED W2812BStrip  End init lifecycle...
2023-03-04T22:06:57.934782036+00:00 DEBUG WLED W2812BStrip  wled-16._wled._tcp.local device thread event handled

Once that was done, the device was functionnal in the app. I’m now able to turn on/off and most importantly, I can now see the presets. (In the previous captured log, there is only one preset on that perticular device called “Blanc”.

So, next step I’ll try to add a second device to see if it gets configured correctly. I’ll post back once it’s done.

Hope that can help figure out what’s wrong.
thanks!

I’m back,

So once again, I ran the discovery. It discovered my 6 other WLED devices that I had removed previously. And once again the initialization of the devices would not complete to a usable state. I applied the same procedure as before, delete 5 of the devices and keep only one. That made this remaining WLED usable in the app.

I pushed my testing futher, with regards to the presets which I would really like to be able to use natively in ST. Unfortunately, for some reason, I cannot set the “mode” in a routine or in a scene. The field is greyed out in both setup pages. All the other settings are available except this one.

I remember reading something about this in the forums, that this might be a bug that would need to be fixed by SmartThings but I don’t remember precisely if it’s the same issue present here.

First of all thx for the testing you did so far.

The driver can currently not detect if the state of a device has been changed outside of smartthings. I also had some Problems with the driver not initation right sometimes I’ll be looking into that soon. You could try manually refreshing the state by swiping down on the page on which you control the device. Doing that should also pull the device State if none has been pulled yet.

I pushed my testing futher, with regards to the presets which I would really like to be able to use natively in ST. Unfortunately, for some reason, I cannot set the “mode” in a routine or in a scene. The field is greyed out in both setup pages. All the other settings are available except this one.

Thanks for noticing. I didn’t test that part yet. It’s probably because the capability I used for it is still an experimental feature. I might test some other capabilites next week to see if I find one that works.
I might open a new Post to see if someone else has an Idea or knows if this can be done with custom Capabilities. But at least we know that it will work sometime in the future :sweat_smile: