Thanks for this. I got it working in under an hour. I tried to get BKhobbys Kube LED Strip wroking but couldn’t get it going with openhab v2. Wled is fantastic all around, and the binding made it simple enough for a novice like me
I just uploaded a newer version of the binding as I got reports of ‘mass reconnecting’ with the binding that this was based from (espmighthub) and the code is 90% the same. Only thing to change was the way the binding connects to the mqtt broker, rest is the same. So if you get the logs showing the MQTT is connecting over and over, then try the newer version and report if it still happens.
I’ve configured the Binding with .things file but when I change a state of an item, there is some kind of loop and it’s spamming the log file. I had to restart openhab to stop it
I am using the openhab-supplied internal mqtt broker (i think it’s called moquette?) in general.
It is recommended you do NOT use the built in broker as it has known issues mentioned on the forum. Use mosquito where 90% or more is using it, tests and updates are done and you will have far less issues as that binding/broker is not updated and has issues.
Also if you still have issues post some of the log so if there is an issue it can be looked at.
I have not had any issues with the internal broker so far, it’s working well!
Anyhow, may I suggest the binding could make use of the systemwide configured broker - may it be internal or mosquitto (instead of installing the paho package additionally).
I’ll follow the development, but right now do not want to change my MQTT setup.
The wled project looks like most development is towards the http api and mqtt is being left behind. I have raised some bugs on GitHub and wait to see if they get addressed or not in next release and if mqtt gets feature parity on all new features. Since home assistant is not using the mqtt api all the testing and drive is not there so it may mean a binding is better off going towards the http api.
Until this is known I won’t be doing much coding in the binding only to keep it running. It is pretty close to being ready for a push review and I have been working towards that as I have time.
Edit:
In case anyone is wondering what that means, I would use the binding as it is probably only five hours work to modify the binding over to http from mqtt and your rules and config won’t even know that it has been changed if you have setup with textual config. It would also be possible to give the option to use either method by flicking a switch in the bindings setup. Both api’s use JSON just delivered in a different way.
IMHO using mqtt is better as it is event based and does not need to poll. Also any interruptions in the network will not cause data to be lost in the case of a wifi network getting interference from a microwave oven.
Installing an older version most likely
Just caused another restart. I did change the way it connects it the last build but those changes are getting all positive feedback on the espmilighthub binding which shares the same code.
My guess is the issue is caused by openhab needing to restart multiple times for the cache to be created. This happens for all jar files inhave used in the addons folder, they don’t work first go until a few restarts with version 2.5.x unlike earlier openhab versions. I have not had that happen with that error.
If it does continue to happen then check the log file for your broker. I have often found more detailed information in the brokers separate log
File it may be as simple as a typo on your password.
i was trying to increase and decrease the brightness.
When using the slider everything works fine, but when im trying to use a rule to do this im getting this error:
2020-04-22 09:41:25.051 [ome.event.ItemCommandEvent] - Item 'WLed_Arbe_Schreibtisch_Colour' received command INCREASE
==> /var/log/openhab2/openhab.log <==
2020-04-22 09:41:25.058 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.wled.internal.WLedHandler@87bb6c': For input string: "INCREASE"
java.lang.NumberFormatException: For input string: "INCREASE"
at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043) ~[?:1.8.0_232]
at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110) ~[?:1.8.0_232]
at java.lang.Double.parseDouble(Double.java:538) ~[?:1.8.0_232]
at org.openhab.binding.wled.internal.WLedHandler.handleCommand(WLedHandler.java:83) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_232]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_232]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy1399.handleCommand(Unknown Source) [?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_232]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_232]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
Part of the rule:
if (receivedEvent.getEvent() > "0") {
WLed_Arbe_Schreibtisch_Colour.sendCommand(INCREASE)
}
Nothing, the binding does not handle increase and decrease commands, I would have to look at how easy it is to add support as the binding then has to track the brightness which it may already be doing. Not in front of the code right now.
The binding does track the brightness already so it is probably 20 minutes to add the feature. It could be done so that the increase/decrease command adjust the brightness by:
a) A fixed amount like 5% each time the command is called is simply added on.
b) A config allows any amount to be specified. User can then choose but it a fixed amount.
c) An algorithm is used each time the command is called so that more steps are down the dimmest levels of light and towards the upper end the steps jump more. LOG. steps used as stepping down from 100% TO 95% may barely get seen, yet a change from 5% to 10% is a big jump in light usually.
d) Suggestions? How do other bindings handle this?
I’ve looked more into it and would agree, changing the WLED binding to use http JSON api would probably make the most sense looking at the activity on WLED development.
Has anyone tried the newer firmware released today? They added more functionality to http api in this release at ip/url for effect settings according to PR descriptions.
Hi, I switched my MQTT Broker to mosquitto and work with your Binding now. It’s very conveniant.
I installed the WLED 0.10.0 and so far everything works the same. What exactly are you looking for in the http api? I can have a look. The xml response seems to be exactly the same. Also the mqtt looks the same to me so far. It looks like the JSON got some additional features.
If I may make suggestions for your binding:
Brightness Channel (sometimes I just want to change brightness and it is a bit awkward through the colorpicker)
White channel for RGBW LEDs
Live Override (new feature in WLED 0.10.0) ON/OFF
Adding automatically the Effects and Palettes in the Selection Widget without having to define in the sitemap (see the Squeezebox Binding favorites)
