Wled: ioBroker Adapter

[Aircoookie]

Hi again, @DutchmanNL!

I would also choose the HTTP API option. UDP broadcast is not as reliable and won't provide feedback on whether the command was successful to ioBroker, but is very fast. MQTT is not bad as well, but it requires user configuration of WLED settings (adding the broker IP), and keeping the connection, which might make things more unstable, so HTTP is probably the way to go.

About JSON, I was planning to add an API for it anyways (it is useful for the new segment feature I plan on adding soon-ish), but I might need a little time to implement it properly. https://github.com/bblanchon/ArduinoJson seems like the go-to library for this job!
What values would be useful to you to have in the initial JSON response?

On a side note, have you heard of mDNS/Bonjour/Zeroconf? I don't know the capabilities of ioBroker, but it is supported by WLED and allows for automatic device discovery (my Android app uses it, for example). Of course, just having the user enter the IP address is an option as well.

Looking forward to working on this together :)

[DutchmanNL]

thank you !

Yeah look for the integration part I am thinking on 2 ways, one would be a dedicated adapter for WLED and the other way an integration to the existing multicast adapter I am currently working on.
The benefit of UDP is the package size and little overhead on the network. About reliability, yea as far I see in practice is very stable and sometime (1 of > 100) requests fails. But here we build and error loop to handle the situation by ensuring send commands are acknowledged and if not the message is send again.

For the JSON, yea that's the way to go we did the same with temperature settings looks very well.
Need to think about the values, give me some investigation time for that.

Bonjour is an interesting part, thank you pointing it out!
Currently we do not have an bonjour "listener" adapter as far I know, we are able to emulate a device with Yahka adapter which enables adoption of state from ioBroker into apple HomeKit.

@andiling

[DutchmanNL]

Hi,

I had a closer look to the structure and how we could proceed.

In basic I would like to handle it by broadcast that would make adoption very easy!

My basic idea :

• I would like to have all actions controllable by API as an state object within iObroker
• this includes all post request which can be handled by http APU
• WLED announces itself by UDP which allows iObroker to automatically adopt the device and required states

Issues I see, or parts we need to discuss :

• having all states is great, but I will need the current values.
• we could send all values by JSON within an UDP broadcast package.
• if that's not possible we could use the UDP announcement of change to trigger an http get receiving all values

Sending would run the same, a state change in iObroker would trigger an UDP broadcast (or for time being http post action).

For this it's important to have feedback, so sending a command should be committed by an OK or NOK, NOK would trigger resending the command again.
This can be handled by an timeout loop or by comparing the new received UDP message with the current data.

So basic question would be :

1) would it be possible to have all possible switch values exposed as JSON ?
2) would it be possible to send it by UDP package
3) if not, is it an idea to let the UDP package trigger a http get to receive the JSON

If 3 is the option, we need to discuss the layout of JSON to have all relevant information for the post request in one message.

Happy to hear from you, this will be awesome!
I already managed to have an "quick and dirty" implementation which allows me to control all lights based on my IIT sensor (temperature, doorbell and all this kind of funny stuff).

Btw, one additional question : what do you think about making separation of led stripes possible within WLED ?
The library is able to handle separation if that could be done by web interface (or states/http post) it would be great.
Thinking about having like 6 5m stripes in 1 room but than separating them to have individual control capabilities

[Aircoookie]

Hi,

yes, having a JSON state object for us to modify seems like a great idea!
I am thinking something along these lines:

{
  "info": {
    "name": "Sample WLED light",
    "ver": "0.9.0",
    "rgbw": false,
    "ledc": 150
  },
  "leds": {
    "on": true,
    "bri": 128,
    "nl": {
      "on": true,
      "dur": 60,
      "fade": false,
      "tbri": 0
    },
    "segs": [
      {
        "startpx":0,
        "len":150,
        "cols": [
          "#00FFCC00",
          "#00000000",
          "#000000FF"
        ],
        "fx": 65,
        "sx": 128,
        "ix": 75,
        "pal": 20
      }
    ]
  },
  "udpn": {
    "send": false,
    "recv": true
  }
}

Of course we can add more values should we need them! You might realize that I often abbreviate stuff, I'm sorry about that, but it indeed increases the responsiveness of the module a lot, so it would be nice if we could keep it that way.
The WLED device could respond either with the complete object, or something along the lines of {"success":true}. You of course also don't have to send the entire object every time, {"leds":{"bri":128}} will work just fine as well if only the brightness needs to be updated, for example

UDP is certainly possible, we just have to stay within the 1450 chars one packet allows. We shouldn't run into that issue too soon though, since my little example above is less than 600 bytes, even in pretty-printed form. Still, I'll also make the JSON API available via HTTP at [deviceip]/jsonapi as well.

"WLED announcing itself via UDP" is something we have to test. I generally try to avoid having the module send any packets without prior requests, because it can lead to small stutters in fast animations.

You probably wondered what the "segs" array is about in the JSON... well it is for the new segment feature i'm planning! It is similar to your separation idea, just that still a single strip is used with different effects running on different parts of it. "Hardware" separation is a little difficult, because multiple pins need to be driven, so multiple NeoPixelBus objects would be required and it'd be less stable, but worth giving a try sometime in the future.

[DutchmanNL]

sorry for the long Delay i will come back the Details later this week.

Just as a Small. question for now : the JSON Looks cool, how are you processing with the Separation idea ?

[Aircoookie]

Awesome! Don't worry, I'll still need some time as well for the JSON API. Segment support will be even further in the future.

There's another user who requested driving two strips with mirrored output. That's really easy to implement, so I will provide an option for doing so really shortly.

[DutchmanNL]

There's another user who requested driving two strips with mirrored output. That's really easy to implement, so I will provide an option for doing so really shortly.

cool ! If you need any assistence with the JSON Part please give me a shout. i know a Person who is quite familiar with it if you need a helping Hand

[Aircoookie]

JSON API is now added! (although HTTP only, I still have to add it via UDP as well as create a doc)

If you want to check it out, install the latest master!

• [IP]/json returns everything
• [IP]/json/state returns state object (every value updatable)
• [IP]/json/info returns device info (no value updatable)
• [IP]/json/palettes and [IP]/json/effects return palette and effect name lists.

To update the state object, just send a POST request to [IP]/json or [IP]/json/state with the values you want to change (for example {"bri":255,"seg":[{"col":[[0,255,200]]}]} for maximum brightness teal)

[debsahu]

This is great, adding to Home Assistant will be working much easier. I saw you were working on JSON API, is it available for MQTT interface as well?

[meelow]

+1 for mqtt interface ;-)

Debashish Sahu [e-mail] schrieb am Mi. 6. März 2019 um
21:49:

This is great, adding to Home Assistant will be working much easier. I saw
you were working on JSON API, is it available for MQTT interface as well?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Aircoookie/WLED/issues/102#issuecomment-470270766,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGzSbbkRRWyVWn-uHDeD-R7COycAzKJPks5vUCnJgaJpZM4aiEl0
.

[Aircoookie]

Yes, I will make it available via MQTT and via UDP :)

[DutchmanNL]

If you want to check it out, install the latest master!

great, I tried to build the master branch but looks like we have an issue here :

Warning! Library{'requirements': '1.2.0', 'name': 'EspAsyncWebServer'}has not been found in PlatformIO Registry. You can ignore this message, if{'requirements': '1.2.0', 'name': 'EspAsyncWebServer'}is a built-in library (included in framework, SDK). E.g., SPI, Wire, etc.

WLED/wled00/wled00.ino:42:31: fatal error: ESPAsyncWebServer.h: No such file or directory

[DutchmanNL]

was able to fix this issue by changing the name of dependency from

[email protected]

to

Esp Async [email protected]

still compile fails :

*** [.pioenvs/nodemcuv2/src/wled00.ino.cpp.o] Error 1

/Users/rafal/Programming/WLED/wled00/wled00.ino:369:31: warning: right operand of comma operator has no effect [-Wunused-value]
IPAddress realtimeIP = (0,0,0,0);
^
/Users/rafal/Programming/WLED/wled00/wled00.ino:561:19: error: new declaration 'bool reconnectHue()'
}
^

/Users/xxx/xxx/WLED/wled00/wled00.ino:555:6: error: ambiguates old declaration 'void reconnectHue()'
DEBUG_PRINT("State time: "); DEBUG_PRINTLN(wifiStateChangedTime);

[DutchmanNL]

This is great, adding to Home Assistant will be working much easier. I saw you were working on JSON API, is it available for MQTT interface as well?

i woud suggest than to create an issue for HA ?
I cannot focus on both systems but basically what we do here (and no NOT MQTT!) is feasible for any automation system

[DutchmanNL]

JSON API is now added! (although HTTP only, I still have to add it via UDP as well as create a doc)

If you want to check it out, install the latest master!

• [IP]/json returns everything
• [IP]/json/state returns state object (every value updatable)
• [IP]/json/info returns device info (no value updatable)
• [IP]/json/palettes and [IP]/json/effects return palette and effect name lists.

Works like a charm good job !

To update the state object, just send a POST request to [IP]/json or [IP]/json/state with the values you want to change (for example {"bri":255,"seg":[{"col":[[0,255,200]]}]} for maximum brightness teal)

i have to try this one. Basically I like the way of implementation basically I can always just send the complete JSON and the device will handle the rest that nice.
I will work on the adapter during the next week I got no everything I need to start working on it :)

[Aircoookie]

Nice! I hope it will also stay stable for you. It gets tight really quickly on the ESP8266 heap-memory-wise, we are at a point where only the latest esp core will even work well. Need to look into optimizing the code so more heap is available

[Aircoookie]

Also, just pushed the PIO fix :)

[DutchmanNL]

Also, just pushed the PIO fix :)

and it works like a charm thank you !

[DennisH1978]

Hello there... Is this a New Adapter for controlling ws2812b Stripes? I read the whole Thread but I am not Sure if this Adapter is for ws2812b and if it is availble... Could you please tell me? Thx 😀

[Aircoookie]

Hi @DennisH1978!
Yes, my software WLED can display various colors and effects on ws2812b strips. It is standalone but offers integration capability with other services via MQTT or JSON. There is already a Homeassistant autodiscovery integration, but no native adapter for ioBroker yet.

[DutchmanNL]

Hey @Aircoookie

How can we proceed on that ? I basically have an multicast adapter ready which offers an generic API for communication on multicast.
It expect a JSON in specific format to automatically create the states and return values.

We currently have an binary available which communicates on that principle with Vansware SmartHome plugs.
The adapter and binary are in beta-test tase.

The API is capable to :

• Handle initialization command
  
  
  
  • when an message is received an not state present, the adapter will request a complete overview of all states
  
  
  • sends feedback if all Data is handled
  
  
• create state structure with devices / channels and states
• each state can have a role, writable yes/false, min and max value configured
• on writable states each change is send by udp multicast to the partner
• if no "success" comes back the change will be send again with a maximum of 5 times to timeout

[Beliar-666]

Hey Guys, any news about the Adapter?

[DutchmanNL]

@Aircoookie any idea based on my previous suggestion ?

[Beliar-666]

no news here?

[Aircoookie]

So sorry for ignoring this for half a year! This thread totally fell under the table somehow...
@DutchmanNL sounds very good! If you are still up for implementing this, send me the JSON format you need for discovery, I should be able to add it as multicast!

[DutchmanNL]

@andiling can you assist please

[gallipower]

Sounds great!
I have 6 wleds from 10 to 160 WS8212 working and controlled via wled-app. Awsome Work!

But also running all the rest of my home via iobroker and it would be great if an easy integration in iobroker via adapter is possible!

I attemted to run it via mqtt but i failed to bring it up running.

So, if i could provide help in testing the adapter please let me know!
(Further communication better in German because of my weak english!)

[DutchmanNL]

stay tuned, integration will be ready within. the next 2 days alpha already in dev-test :D

[Aircoookie]

@DutchmanNL awesome, good work!
By the way, I've created a new discussion topic on the brand new WLED forum for the integration!
https://wled.discourse.group/t/iobroker-integration/33

[DutchmanNL]

https://github.com/iobroker-community-adapters/ioBroker.wled

beta ready, happy testing ! 👯‍♂

[lorenz24]

Hi just one information.
I think the name of the field "seg.o.col.sx" should be speed and not ID of the effect.

Thanks you for creating this adapter for iobroker.

[copperfield74]

@DutchmanNL Thanks very much for the adapter. But I get A LOT of warnings within IOBroker. They say:
(998) State attribute definition missing for + lor
(998) State attribute definition missing for + lip
(998) State attribute definition missing for + lm
Is there a fix for this or did I misconfigure something?

Thanks in advance.

[Aircoookie]

@copperfield74 those are some newly added attributes to the JSON api. It's annoying that a warning is thrown for that. @DutchmanNL can fix it by including these attributes, but once I add more in a future version the issue would re-appear...

[DutchmanNL]

fixed in 0.5.2, the warning is to indicate the developer about an issue will be moved to sentry in an later version and excluded from client logggin